July 8, 200916 yr I am new to unRaid and have a "problem"...I have a wired Gigabit network and can pull data from the server at around 60MB/sec but when sending data TO the server it sits at around 12MB/sec...is this normal for write speeds to be that much slower than read speeds? SATA ports on motherboard are SATA I and I have 2 HDDs (1 is parity) connected to those... I am using beta 6 (newest)...and if there isn't a clear answer is there a way to troubleshoot network speed to/from the server? What should I check first?
July 8, 200916 yr Write speeds will be slower than read speeds. When you read from your server only one I/0 function is taking place. When you write to your server 4 I/0 functions are taking place. You have to read from the parity & the data drive. 2 I/0 You then have to calculate parity. You then have to write to the parity drive & the data drive. 2 more I/0 Total of 4 I/0 (read write) functions. This will definitely slow down the write compared to the read. I can't speak for other people but when I tried 4.5b6 my write speeds decreased from version 4.4.2. I went back to version 4.4.2 because of the write speed increase. I am only on a 100meg network & I could see the difference. I hope this helped to answer your question. Phil <<Edit>> P.S. What operating system are you running on the machine you are accessing the unRAID server from? This makes a big difference on the write speed also.
July 8, 200916 yr There is also a new FAQ entry, "How fast is unRAID?", which may help to provide some perspective. It is new enough that it may need revision, but the numbers are in the ballpark at least. I am using beta 6 (newest)...and if there isn't a clear answer is there a way to troubleshoot network speed to/from the server? There is a recent thread about the use of IOZONE to measure performance.
July 8, 200916 yr I am new to unRaid and have a "problem"...I have a wired Gigabit network and can pull data from the server at around 60MB/sec but when sending data TO the server it sits at around 12MB/sec...is this normal for write speeds to be that much slower than read speeds? SATA ports on motherboard are SATA I and I have 2 HDDs (1 is parity) connected to those... I am using beta 6 (newest)...and if there isn't a clear answer is there a way to troubleshoot network speed to/from the server? What should I check first? Your speeds are very normal, and in fact, your "read" speed from the server is actually a bit faster than most. (perhaps you were re-reading the same file as recently read, and it was still in cached memory) As described, to write to an unraid disk requires 4 I/O operations, and two of those are to the same sectors just read, so the disk platter MUST spin around one revolution before the write can occur after the read. 7200 RPM disks help here... They will be faster only because the two sectors (one on the parity disk, one on the data disk) can be accessed a second time faster. If you put a "green" 5400 RPM drive, it will slow all writes to the array vs. a 7200 RPM drive that spins faster. Joe L.
July 9, 200916 yr If you put a "green" 5400 RPM drive, it will slow all writes to the array vs. a 7200 RPM drive that spins faster. A green 5400 RPM parity drive can slow all writes to the array. A green 5400 data disk will affect write performance only to that single disk. But several people use the 5400 RPM parity drives with a cache disk and have no complaints. I personally have a 7200 RPM parity disk, a 7200 RPM cache disk, but most of the rest are 5400 RPM.
July 9, 200916 yr One point that might be interesting to some... While we know that we must wait for a given disk to rotate its platters a full revolution between reading the data on a sector and writing it, we've been assuming that the data is ready to be written by the time a full revolution has occurred. If that is not true for some reason, then the disk must make yet another full revolution before being written to. It is therefore possible for a disk to spin too fast, and for it to need two revolutions to write a sector just read. When it goes to write, the sector could have already passed under the disk head a first time, and it needs to wait one more revolution. I early days of disk formatting, we used to specify interleave factor for the sectors, so logically adjacent sectors were not physically adjacent on the disk, to allow for the time it took to process the data being read/written. This is similar, but with two or more disks involved and the specific need for at least one revolution of a disk. Joe L.
July 9, 200916 yr WeeboTech reported a substantial increase in write performance moving from a WD 1T GP (5400 RPM) drive to a Seagate 1.5T (7200 RPM) parity drive. Perhaps he would comment.
July 9, 200916 yr If you put a "green" 5400 RPM drive, it will slow all writes to the array vs. a 7200 RPM drive that spins faster. A green 5400 RPM parity drive can slow all writes to the array. A green 5400 data disk will affect write performance only to that single disk. But several people use the 5400 RPM parity drives with a cache disk and have no complaints. I personally have a 7200 RPM parity disk, a 7200 RPM cache disk, but most of the rest are 5400 RPM. Agreed! WeeboTech reported a substantial increase in write performance moving from a WD 1T GP (5400 RPM) drive to a Seagate 1.5T (7200 RPM) parity drive. Perhaps he would comment. I have my setup with 1.5TB parity 7200RPM 32MB cache 1TB small files drive, 7200RPM 32MB cache 1TB Torrent drive, 7200RPM 32MB cache 1TB WD Green Drives 5400RPM 16MB cache. WD10EACS (movies, avi's) I believe the WD10EADS have a 32MB cache and different platter structure. I've read reports where they are faster. For my media storage the WD 1TB EACS drives are fine. When I upgraded to the 1.5TB parity drives, every write operation to the protected array got faster. When I upgraded the most used drives to the 1TB 7200RPM 32MB cache drive those operations became much faster. My system is busy with seeding hundreds of files, Even with 8GB of ram, The change in the 3 drives was dramatic for my system.
Archived
This topic is now archived and is closed to further replies.