Could you please indicate your copying transfer rate between two disks, using mc from a telnet shell (accessing the disks by /mnt/disk*)?

 

It would be a great feedback, if somebody, who has no parity disk could indicate the rate without parity disk as well.

With the same config, same drives, under WinXP, the transfer rate between 2 drivers is between 60-70MB/s, while under unRAID it is about 22MB/s (without parity drives) is that huge difference normal?

 

I tested with two different motherboards... 

Well not what your doing, but from my Vista PC to the unraid server, with parity disc, i am ending the transfert of my first To and the average is 26.3Mo/s

I wanted to help, but I have a parity drive, as do almost all unRAID users.  Running without parity tends to be a temporary thing, usually for an initial load of the array, or for a temporary speed boost.  But those with a cache drive could test their mc transfer speed for you, by copying from a data drive to the cache drive.

 

Your 22MB/s seems way too slow, as most get a read rate from unRAID to another machine of 25MB/s to 35MB/s, and that's across the network.

 

I did forget to respond earlier, but I saw nothing unusual in your syslog.  The Maxtor is an older drive, linking at SATA150 speeds, but that should only be a very small performance hit.  You might try transfers with mc in both directions between the drives, then capture and examine (or post) the syslog, and see if disk errors are occurring.  You might also obtain a SMART report (see here) for each drive, to make sure they are OK.  Too many remapped sectors could be affecting performance.

Thank you, RobJ, I will do.

 

It the meantime, something which I am thinking about:

Can the CPU and/ or memory be the bottleneck? It is only an E1200 Celeron and 1GB at the moment. Initially I thought it should be enough, but I am not that confident now. (The processor and the RAM size were different on the Windows machine, only the mobo and the disks were the same)

 

RobJ, I am not sure if you read my other thread about speeding. At the same time, I can copy at 50MB/s transfer rate (peak) to the disks over the network. So something is wrong about the reads (reading through the network is slow as well).

 

I attached the syslog as of today. I see not any event logged as from yesterday evening when booted up.

The E1200 could be a bottleneck, the memory is not.  1.6GHz is slow, but not horribly slow.  Most of us have fairly pedestrian CPUs.  I have a 2.4GHz that I underclocked to ~2GHz.

 

 

Bill

The E1200 could be a bottleneck, the memory is not.  1.6GHz is slow, but not horribly slow.  Most of us have fairly pedestrian CPUs.  I have a 2.4GHz that I underclocked to ~2GHz.

 

 

Bill

 

Okay, than I try to boot up unraid with the same config as WinXP. There is an E8200 and 3 gigz RAM in the same type of board, that I have under unRAID with E1200.

 

But I thought over again, if I can write with 50MB/s through the network, than the CPU shouldn't be the problem as reading shouldn't be more CPU consuming, than writing. 

True - but the earlier point made is still valid: you are chasing a meaningless metric.  You won't run without parity for long and your actual write speeds will drop to under the 22MB/sec rate anyway.

 

If you want to continue debugging the test you are doing, I would double check all of my assumptions.  Something may not be correct in the test you performed.  BTW, what file size are you using?

 

 

Bill

I attached the syslog as of today. I see not any event logged as from yesterday evening when booted up.

 

You are right, absolutely no issues in either the setup of the drives or in operation, as of 5:49pm.  Their configuration appears to be optimal, and the performance numbers that are visible are good.

 

RobJ, I am not sure if you read my other thread about speeding. At the same time, I can copy at 50MB/s transfer rate (peak) to the disks over the network. So something is wrong about the reads (reading through the network is slow as well).

 

I did see it, but had nothing important to add.  The reads and writes should have been near identical, especially since the network was the bottleneck, not the disk I/O.  As Tom said, the only other issue might be the differences in caching on either end.  You aren't running Vista without SP1 are you?  See this.

 

It the meantime, something which I am thinking about:

Can the CPU and/ or memory be the bottleneck? It is only an E1200 Celeron and 1GB at the moment. Initially I thought it should be enough, but I am not that confident now. (The processor and the RAM size were different on the Windows machine, only the mobo and the disks were the same)

 

Both are fine.  Today's processors are idling over 99% of the time, except when running CPU-intensive operations.  Almost every thing in unRAID is I/O bound, not CPU bound.  You probably would not see any difference with a much slower CPU, especially without parity calcs to do.  When you add the parity drive, a faster CPU might make a few milli-seconds of difference.  A faster bus would be more important.

 

A good point by Bill, make sure you are testing transfer speeds with gigabyte sized files.  Samba is slow, so if you are copying large quantities of small files, the per-file overhead will drag your overall speed down.

I am using WinXP SP3.

The test files I am using are always .iso images with ~4.7GB.

Unfortunately there is no real big difference if I change the copy directions. Still the same.

 

If I try to test with dd if=/mnt/disk1/something.iso of=/dev/null, it is peak at around 33-35MB/s, after the setra tweak, which seems low as well, comparing to the results of others...

 

 

You can also try the hdparm speed test, here: Check Harddrive Speed

 

Also see this for the hdparm -I option, and run it for each drive.  Look in the Capabilities section for the DMA and PIO values, and make sure the asterisk precedes the highest or next to highest UDMA value.  Hopefully, you will see something like this: ...  udma5  *udma6, or even *udma7.

 

And you should then check the SMART reports (smartctl -a -d ata ...) for each drive.  Feel free to post any of the hdparm or SMART reports here.  In the FAQ entry, the /boot/ part of /boot/smartctl is only necessary for previous versions, assuming you had copied smartctl to the flash drive.  With recent versions of unRAID, it is included with unRAID, so no preceding path is necessary.

As I had time, this morning I start to run all the test what RobJ suggested.

 

Now, I have these 5 disks installed, based on hdparm info, all is running in udma6 mode. Hdparm speed test are the following:

WDC_WD10EACS

Timing cached reads:  2250 MB in  2.00 seconds = 1125.11 MB/sec

Timing buffered disk reads:  274 MB in  3.00 seconds =  91.23 MB/sec

WDC_WD10EACS

Timing cached reads:  2202 MB in  2.00 seconds = 1100.77 MB/sec

Timing buffered disk reads:  278 MB in  3.01 seconds =  92.36 MB/sec

SAMSUNG_HD501LJ

Timing cached reads:  2206 MB in  2.00 seconds = 1103.56 MB/sec

Timing buffered disk reads:  238 MB in  3.02 seconds =  78.68 MB/sec

WDC_WD4000YS

Timing cached reads:  2190 MB in  2.00 seconds = 1095.13 MB/sec

Timing buffered disk reads:  168 MB in  3.01 seconds =  55.80 MB/sec

WDC_WD4000YS

Timing cached reads:  2208 MB in  2.00 seconds = 1103.99 MB/sec

Timing buffered disk reads:  168 MB in  3.01 seconds =  55.81 MB/sec

 

Shows not much problem to me.

 

Than something which I always feel, only can happen to me (as my case with samsung spin down):

Started to copy an .iso with mc from disk1 to disk2, as usual, and I can't beleive to my eyes. 60MB/s peak. Tested on more .iso's, reproduceable. Perfect. But nothing was changed during the night, nothing special has happaned.

 

But I had a bad feeling, that after a reboot, it will slow down again, an unfortunately I was right. After a reboot, I am at 22MB/s again.

 

Anybody with any clue, that how is that possible?

ReBoot, immediately check disk 1 to disk 2, immediately run hdparm test on disk 1 & disk2, immediately check disk 1 to disk 2....  then repeat using disk 1 and disk 3.... my suspicion is that whatever is slowing you down is "reset" by the hdparm test....

 

 

Thank you for the tip, jimwhite!

 

That was my first thought as well, so I did all the hdparm activity after the rebooted, fresh unraid, but id didn't helped.

Is there any chance, that unraid is initiating some FS test or smart diag, anything, which takes a long time, even a day, which is limiting performance during that?

That is a good idea, but the parity check is the only process that unRAID would start on its own, if it thought, rightly or wrongly, that it wasn't properly shut down previously.  But you would know if it was running, just by checking the Web management page, make sure you refresh that page.  And it would also show up in the syslog.

I am testing without parity drive, so it can't be parity sync.

 

I wiped out 2 of my WD drivers. Make a fresh install and the symphtom is the same in two different config.

Also tried with powerful CPU, same. Now, I don't know what to look after.

 

IS it for sure, that reiserfs not doing anything on its own? Some block redistribution (but what it would redistribute without data), tail packing, or anything, which is resierfs specific?