... you should also have a solution for the slow write speed issue.  If that solution is a 64bit version then it needs to be released at the same time.

 

That may not be practicable.  The current solution is to reduce available memory to 4GB - in fact, there is evidence to suggest that some have been okay with 8GB.

 

Edit: Memory sizes corrected!

... you should also have a solution for the slow write speed issue.  If that solution is a 64bit version then it needs to be released at the same time.

 

That may not be practicable.  The current solution is to reduce available memory to 4MB - in fact, there is evidence to suggest that some have been okay with 8MB.

 

 

note: 4GB and 8GB respectively.

For most basic purposes, 1GB is enough to run unRAID.  I believe some members are still running with 512MB.

... you should also have a solution for the slow write speed issue.  If that solution is a 64bit version then it needs to be released at the same time.

 

That may not be practicable.  The current solution is to reduce available memory to 4MB - in fact, there is evidence to suggest that some have been okay with 8MB.

4MB would be a bit low.

That may not be practicable.  The current solution is to reduce available memory to 4MB - in fact, there is evidence to suggest that some have been okay with 8MB.

 

 

note: 4GB and 8GB respectively.

 

Oooops.  My first computer had 128bytes of RAM, even the first PDP-11 I worked on, professionally, only had 32kB - these big numbers confuse me!

 

So, who remembers having to build overlay structures so that large programs would run in small RAM?

I believe some members are still running with 512MB.

My older server only has 512MB, it works just fine.  It is in 4 128MB strips.  For its original purpose of holding my media collection, it has been working perfectly for nearly 8 years.  (it is currently running 4.7 unRAID and originally ran unRAID version 1.050930, the Sept-30-2005 release. )

 

Joe L.

Not practical to upgrade memory without upgrading the entire MB,and since it is a "mostly" IDE based server, not as easy to swap in a new MB with 12 IDE ports.

That may not be practicable.  The current solution is to reduce available memory to 4MB - in fact, there is evidence to suggest that some have been okay with 8MB.

 

 

note: 4GB and 8GB respectively.

 

Oooops.  My first computer had 128bytes of RAM, even the first PDP-11 I worked on, professionally, only had 32kB - these big numbers confuse me!

You and I are showing our age. My first personal "electronic" computer had NO memory.  It was analog.

My first personal "electronic" computer had NO memory.  It was analog.

Ah, I only ever used an analog computer at University - I remember it drew pretty patterns.

 

At the time my final year thesis related to cursive script programming (ie, simulated handwriting), but using a digital computer (Computer Automation 'naked mini 16'?).

Oooops.  My first computer had 128bytes of RAM, even the first PDP-11 I worked on, professionally, only had 32kB - these big numbers confuse me!

You and I are showing our age. My first personal "electronic" computer had NO memory.  It was analog.

The first computer I did anything practical with had 8k of memory. I built several laboratory data collection systems with those.

Just release it as is. It sucks that there is a failure on any mobo, but that one mentioned is a Supermicro board (I actually get a perverse pleasure that it is a snooty Supermicro board!) And it will likely be fixed fairly quickly. No reason to delay for the 99 percent that are unaffected.

Just release it as is. It sucks that there is a failure on any mobo ...

 

The ultimate decision lies entirely with Tom and, I suspect, if the only problem was to do with the performance on a small set of mobos, it would already be out.  I believe that there are a couple of other issues which Tom would like to address.

IMHO, I would like to see the 5.0 release immediately. I have one of the affected motherboards. Release now so everyone has a new basis and a new starting point. Add the 64-bit kernel later, trying to add this is so late in the release cycle will add even more time. Feature creep will never stop. Fix the slow write issue later. Just add it to the known issues for this release. I'm confident it will get fixed upstream at some point.

 

Fixing it now adds even more time. I think the perception of releasing now is much more important than anything else, it is hurting the brand that it is taking so long to release 5.0. I have held off deploying several unraid systems for friends simply because of the RC/beta status.

 

There used to be a term used for code release, "GA." It means "generally accepted." I think 5.0rc12a is generally accepted at this point. Thanks for you hard work.

I have one of the affected motherboards.

 

Really?  You are experiencing slow writes on your X9SCM-iiF?  If so, you are the first one I've heard of.

I have one of the affected motherboards.

 

Really?  You are experiencing slow writes on your X9SCM-iiF?  If so, you are the first one I've heard of.

 

Also the first report I've seen of an issue with the -iiF board.    Disappointing to say the least -- but as long as the "4GB fix" resolves it, I tend to agree it's in the "no big deal" categoary.

 

Enjoyed the "old timer" posts -- kinda remind me of my Altair, IMSAI, and a few other builds I did from that era 

... I remember soldering all the sockets for a nice new 8KB memory board I bought -- building it myself saved ~ $250, so it "only" cost $1200 !!    And just a few years later I was thrilled to get a HUGE hard drive -- a 26MB 14" unit that I got a whopping 10% discount on ... so it only cost $4500 

 

 

I have one of the affected motherboards.

 

Really?  You are experiencing slow writes on your X9SCM-iiF?  If so, you are the first one I've heard of.

 

Also the first report I've seen of an issue with the -iiF board.    Disappointing to say the least -- but as long as the "4GB fix" resolves it, I tend to agree it's in the "no big deal" categoary.

 

Enjoyed the "old timer" posts -- kinda remind me of my Altair, IMSAI, and a few other builds I did from that era 

... I remember soldering all the sockets for a nice new 8KB memory board I bought -- building it myself saved ~ $250, so it "only" cost $1200 !!    And just a few years later I was thrilled to get a HUGE hard drive -- a 26MB 14" unit that I got a whopping 10% discount on ... so it only cost $4500 

 

 

Isn't the iiF board the same as the F-O in every respect except for having two of the Intel 82574L network controllers? If that's the case then I can't see why it wouldn't also have the problem.

He never said he only had one board....  you are all amusing it is board listed in his signature, which it may well be.... but perhaps we should confirm this before getting carried away...

Isn't the iiF board the same as the F-O in every respect except for having two of the Intel 82574L network controllers? If that's the case then I can't see why it wouldn't also have the problem.

 

Indeed - I agree.  I bought my iiF, fully expecting to be affected by the slowdown and have been pleasantly surprised to find that I seem to have good performance.

 

The SCL board isn't very different either, but Tom has been unable to reproduce the slowdown on that.

 

The fact remains that the only reports I have seen of slowdown on Supermicro boards has involved the X9SCM(-F), so if there is a confirmed occurrence with another board, it is new data to add to our attempts to characterise the problem.

He never said he only had one board....  you are all amusing it is board listed in his signature, which it may well be.... but perhaps we should confirm this before getting carried away...

 

Fair point!

Of course, IF the board in question is a -iiF then there's the interesting dichotomy that PeterB doesn't have the problem; but Argonaut does 

 

... of course just because they're both -iiF boards doesn't mean they're the same versions;  have the same BIOS;  are using the same settings;  etc.

 

Of course, IF the board in question is a -iiF then there's the interesting dichotomy that PeterB doesn't have the problem; but Argonaut does

 

There are several X9SCM(-F) users who do not appear to experience the problem - the precise situation needed to produce the poor performance is not yet identified.

Of course, IF the board in question is a -iiF then there's the interesting dichotomy that PeterB doesn't have the problem; but Argonaut does

 

There are several X9SCM(-F) users who do not appear to experience the problem - the precise situation needed to produce the poor performance is not yet identified.

 

When I was running a Core i3-2120 in my X9SCM-F-O I never had the problem. When I upgraded to a Xeon E3-1230 v2 I started having the slow write speeds.

Of course, IF the board in question is a -iiF then there's the interesting dichotomy that PeterB doesn't have the problem; but Argonaut does

 

There are several X9SCM(-F) users who do not appear to experience the problem - the precise situation needed to produce the poor performance is not yet identified.

 

When I was running a Core i3-2120 in my X9SCM-F-O I never had the problem. When I upgraded to a Xeon E3-1230 v2 I started having the slow write speeds.

 

 

That's the most interesting news I've read. How much memory?

Did the limiting of ram to 4GB help alleviate the slow write issue?

8GB, then upgraded to 16GB when I upgraded to the Xeon. Never tried limiting RAM to 4GB because setting vm.highmem_is_dirtyable=1 fixed it for me.

I wish that we had a tabulation of everyone's experience with this.  I have a suspicion that the critical factor is 16GB of ram, not 8GB, possibly and/or an MV8.

I wish that we had a tabulation of everyone's experience with this.  I have a suspicion that the critical factor is 16GB of ram, not 8GB, possibly and/or an MV8.

 

I do have an MV8 as well as a M1015 on my unraid array. I have a ZFS pool hooked up with an M1015 I was thinking about swapping it to unraid and putting the MV8 on it. I could shut down a VM and assign 16GB to unraid see if it happens with two M1015s.

Okay so the last post was in March from Limetech that this will hopefully be the final RC. Now we are almost in June and no updates at this point as to when the final version 5.0 will happen.

 

I have already begun looking at Synology devices at this point because this upgrade timing has now officially gone into the "Years" bracket for time frame since final 4.7 came around.

 

I do NOT like beta versions of software and quite honestly cannot fathom how a business such as Limetech is even surviving at this point with all of the other more modern and flexible options out there today. It makes me wonder if by the time version 5.0 is final, that basically it too will be completely out of date with current NAS products on the market today.

 

I think Tom that we are all at the point of diminishing returns...Past the point of holding tight, hanging on, being patient, etc...

 

How about a real time time frame at this point as to your future intentions of Unraid?

 

Sorry to sound harsh here but I am at my break-away point now and I think that others too can feel my pain. I have been completely supportive of this product from day one - but don't you think that now it is time to sh** or get off the pot! My perception at this point is that Unraid may finally go final and then basically go-away forever due to it becoming obsolete!

 

Best Regards...