With 4.4 beta 2, is there any reason to actually upgrade my system?

 

Right now I'm running a Celeron 440 + 1GB of RAM. I'd happily upgrade to a dual core and load it up with more RAM, but will I actually... see a difference?

 

I'm not running any scripts; I'm not doing anything unique. 11 disks, 1 cache, 1 parity drive. Ranges from 400GB-1TB drives, 250GB cache drive.

 

So, should I invest the... hell, 60 bucks total, and upgrade my hardware?

With 4.4 beta 2, is there any reason to actually upgrade my system?

 

Right now I'm running a Celeron 440 + 1GB of RAM. I'd happily upgrade to a dual core and load it up with more RAM, but will I actually... see a difference?

 

I'm not running any scripts; I'm not doing anything unique. 11 disks, 1 cache, 1 parity drive. Ranges from 400GB-1TB drives, 250GB cache drive.

 

So, should I invest the... hell, 60 bucks total, and upgrade my hardware?

 

If you are looking for any better performance on disk operations, doing a processor upgrade is not going to help.  If you have huge user shares you can exceed memory and crash your system.  Unless this is happening or close to happening, more memory is not going to be beneficial either.

 

If you are looking to expand the use of your unRAID server, and would want to run VMware or other processor / memory intensive programs in the near future, than an upgrade would be helpful.  But if that is the case, you might consider more than a $60 upgrade.

 

If it were me, and all was working fine, I'd likely just leave it alone until such time as you have needs that lead you to a faster processor or more memory.

Wouldn't be better the performance in case of more RAM? I mean: wouldn't UNRAID use it more efficiently as a cache in case of transferring large (eg. ISO images @4.7GB) files?

You're right.  If you are running applications that would benefit from a larger cache, adding more memory would help you.  I just don't happen to be in that situation myself.

 

Some users have figured out a way to keep the directory entries in caches to avoid drive spinups by running very frequent cron jobs to keep the cache from getting flushed.  If you increased your memory there would be more available for this type of thing.  But a hundred MEG would hold a VERY large number of such directory entries, and you;ve got 500M MORE than unRAID really requires.  Again, it comes down to your specific situation as to whether more memory would really help.

Whilst bjb999 is spot on correct if you are planning to do the directory caching thing more RAM is better. The current kernel does not do what it supposed to based on a strict intepretation of the feature descriptopn meaning the more you go over the amount of RAM you need the less chance you reclaim dentry memory resulting in less drives spinning up. In a perfect work bjp999's math would be right but this now you need to go overboard to make it as reliable as you would expect.

 

Also RAM helps with pausing movies and coming back to them . Frequently stop a movie go to bed and watch it again the next day without a signle drive spinning up.

 

Cost vs gain IMHO 4GB is a must.

I was not meaning dentry caching, but just copying large files.

Please correct me if I am wrong, but if there is let's say 4GB RAM and you are copying over a 3GB file to UNRAID, than it fits into the cache, so you won't be slowing down to the actual write speed of the disks. Is this right?

So out of the box, basically "no", there's no grand reason to upgrade. If I was doing more complication applications or writing cron jobs, then yes, it might be worth it.

 

With the price of hardware being so damn low, I just wanted to make sure I wasn't needlessly handicapping myself.

I was not meaning dentry caching, but just copying large files.

Please correct me if I am wrong, but if there is let's say 4GB RAM and you are copying over a 3GB file to UNRAID, than it fits into the cache, so you won't be slowing down to the actual write speed of the disks. Is this right?

Unfortunately, no... I suspect that the reiserfs page flush daemon and the networking IO driver both use a common "lock" so as soon as you start writing to the disks, network IO is slowed, I think even if you have more ram to write to.

 

Joe L.

Unfortunately, no... I suspect that the reiserfs page flush daemon and the networking IO driver both use a common "lock" so as soon as you start writing to the disks, network IO is slowed, I think even if you have more ram to write to.

 

That's sounds bad.

Currently I also have 1GB RAM, and I always "felt", than when I started to copy over a large file to UNRAID, the transfer rate is faster until it reach ~1GB, than it is slowing down.

 

I think, I should test it more precisely...

I dunno, I have 4GB of RAM in my unRAID system and seem to benefit from it. While transferring ISO's (Usually 700MB, but sometimes DVDs) write speeds seem to be much higher than directly to a parity protected disk. 700MB ISO's always seem to transfer over in only a few seconds. Maybe I'm completely wrong, but it sure seems as though I'm writing to RAM. However, I must add that I've never done any form of formal benchmarking on the server.

Unfortunately, no... I suspect that the reiserfs page flush daemon and the networking IO driver both use a common "lock" so as soon as you start writing to the disks, network IO is slowed, I think even if you have more ram to write to.

 

That's sounds bad.

Currently I also have 1GB RAM, and I always "felt", than when I started to copy over a large file to UNRAID, the transfer rate is faster until it reach ~1GB, than it is slowing down.

 

I think, I should test it more precisely...

This is one case where I would love to be mistaken...  If so, I'll add some more RAM too, although most of my writing to my server is ISO images of between 4 and 6 Gig, but it looks like unRAID will support more RAM.    My experience was that even when there was still memory to be written to, as soon as the pdflush process started to write to the disks, the network I/O slowed.  Normally, i would think it would start to write and the network I/O would be throttled if it could not keep up with the writing to the disks, when the buffer cache filled.

 

I know I almost never max out my server, since I often rip the dvd in my laptop, and it is a wireless link to the LAN. 

 

Joe L.

(I'm not in any big rush... I just add movies to my server as I purchase new movies for my collection, so I almost never have more than a few at a time to deal with)

I have benchmarked file transfers and monitored their progress at all points in the transfer and there seems to be no "go fast at the beginning, then slow down" behavior.

 

As one datapoint, the Windows estimate for transfer completion seems to be spot on even at the beginning.

 

 

Bill

I have benchmarked file transfers and monitored their progress at all points in the transfer and there seems to be no "go fast at the beginning, then slow down" behavior.

 

As one datapoint, the Windows estimate for transfer completion seems to be spot on even at the beginning.

 

I can second that. Tested this morning with the same result. My earlier felt was wrong. Therefore more RAM not make any difference in case of file transfer rate.

 

Joe L., your were right.

Is there any chance to change this behaviour?

With regards to RAM. Theres a simple rule of thumb to help new users understand a bit easier. Linux will use all the RAM available where possible. That simple statement means that you will get better real life performance in most areas but not all areas.

 

OK so it wont be always show stopping, but with 8GB of RAM almost the same price as a 1TB HDD its a sound investment.