August 19, 200817 yr Is it normal, that I can write to unRAID with about 35-40MB/sec over the network from a WinXP, but only can read 25-30MB/sec from it to the same machine? Isn't read, that should be faster than writing? (I am not using parity drive at he moment)
August 19, 200817 yr Make sure you choose a file that won't fit in memory or you will be measuring something other than disk performance. Bill
August 19, 200817 yr Author I am testing with DVD images (ISO) at ~4.5GB. RAM on unRAID 1GB RAM on WinXP 3GB
August 20, 200817 yr Just had a thought... Have you looked at this thread for possible settings for readahead adjustment? http://lime-technology.com/forum/index.php?topic=965.0
August 20, 200817 yr Author Yes, sure. It doesn't make big differences. But back to the question: Am I right, that reading should be deinitely faster, than writing even in case, there is no parity drive?
August 20, 200817 yr I would think there would be no speed advantage to writing, but perhaps no disadvantage either. It is possible that w/o parity there is something in the networking setups that cause issues with data going to windows that isn't there coming from windows. Regardless, your write speeds will go down with parity so you'll be back in the land of normal in no time. Bill
August 20, 200817 yr Yes, sure. It doesn't make big differences. But back to the question: Am I right, that reading should be deinitely faster, than writing even in case, there is no parity drive? Typically, yes. but without a parity drive it might be close to the same speed. Are you reading a "user share" or from /disk1, /disk2, etc? (Reading through user shares is slower than reading from the disk directly in my experience.) What we don't know is if the networking is the bottleneck, or something in your server. What version unRAID are you using? (Some versions has issues with some Realtec network card drivers) Is there a router and/or hub/switch in between your PC and the server? What brand/model? Are you using cat5e, or cat6 cabling? Did you put the ends on the cables yourself? or are they factory constructed cables? (A mis-wired, or defective cable could slow down throughput in one direction) If you log in as "root" and type "ethtool eth0" what is the output? Are you running full duplex at 1000Mb/s? If you type "ifconfig" when logged in what is the output? Do you see any errors? any overruns?, any dropped packets? What happens on on the WinXP PC when you bring up a dos command window and type "ipconfig" What does its output look like? Joe L.
August 20, 200817 yr I would expect the two speeds to be comparable. There could also be buffering from the buffer cache thereby giving you the effect of a faster write speed. I.E. data gets streamed at a high throughput, but is written at around drive speed. Eventually these two should catch up. I know when I rsync a file, the first few moments are bursting at 25Mb/s, but then it shifts down to 12MB/s as the buffer cache gets flushed and parity updated. Also when you read the unRAID file, it is being written to a local disk on your workstation. There could be impediments there.
August 20, 200817 yr I see similar behaviour to the OP when reading from my parity'd server vs writing to my cache drive (which bypasses parity). It is entirely possible that the differences you are seeing are due to unRAID-driver overheads. In particular, given how reading and writing work under unRAID, it could be that there are two different pieces of code for writing with and without parity, but that only one piece of code is used for reading.
August 21, 200817 yr Could be because of RAM buffer cache. When you write, data is streaming to the system and stored in RAM. At some point linux starts flushing RAM to disk. From the Windows XP point of view, the write is complete after all the data has been written to the server, but the server is still busy writing the received data to disk. This effect will be greater as the amount of RAM in your system is increased.
August 22, 200817 yr Author Could be because of RAM buffer cache. When you write, data is streaming to the system and stored in RAM. At some point linux starts flushing RAM to disk. From the Windows XP point of view, the write is complete after all the data has been written to the server, but the server is still busy writing the received data to disk. This effect will be greater as the amount of RAM in your system is increased. Thanks for the explanation Tom. However I think something is not correctly setup in my system. I am experiencing the same, or even less speed when I am copying files without network, between disks. When I copy something from one disk to an other (from /mnt/disk1 to /mnt/disk2) using midnight commander, it is only reaching about 20-22MB/ sec. Am I right, that it should be definitely faster?
August 22, 200817 yr Author What version unRAID are you using? (Some versions has issues with some Realtec network card drivers) Is there a router and/or hub/switch in between your PC and the server? What brand/model? Are you using cat5e, or cat6 cabling? Did you put the ends on the cables yourself? or are they factory constructed cables? (A mis-wired, or defective cable could slow down throughput in one direction) If you log in as "root" and type "ethtool eth0" what is the output? Are you running full duplex at 1000Mb/s? If you type "ifconfig" when logged in what is the output? Do you see any errors? any overruns?, any dropped packets? What happens on on the WinXP PC when you bring up a dos command window and type "ipconfig" What does its output look like? Joe L., Thanks for the help, to answer your questions: unRAID version: unRAID 4.3.3 Server Plus Cabling: cat5e, ends made by myself, as the wall connectors as well. "ethtool eth0" output: Tower login: root Linux 2.6.24.4-unRAID. root@Tower:~# ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) Link detected: yes root@Tower:~# ifconfig output: root@Tower:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:1D:7D:0D:9F:87 inet addr:192.168.0.3 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2961970 errors:0 dropped:0 overruns:0 frame:0 TX packets:14298525 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1286271517 (1.1 GiB) TX bytes:3456170169 (3.2 GiB) Interrupt:17 Base address:0xc000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:560 (560.0 b) TX bytes:560 (560.0 b) root@Tower:~# Windows ipconfig output: Windows IP Configuration Ethernet adapter VMware Network Adapter VMnet8: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 192.168.148.1 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : Ethernet adapter VMware Network Adapter VMnet1: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 192.168.241.1 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 192.168.0.1 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.0.254 Ethernet adapter Local Area Connection 2: Media State . . . . . . . . . . . : Media disconnected
Archived
This topic is now archived and is closed to further replies.