February 25, 200818 yr I just setup an unraid server this weekend with the following configuration. Intel BOXDP35DPM LGA 775 Intel P35 ATX Intel Motherboard Intel Celeron 440 Conroe-L 2.0GHz 512KB L2 Cache LGA 775 35W Single-Core Processor 3 Western Digital Caviar GP WD10EACS 1TB 5400 to 7200 RPM SATA-300 Hard Drives SAPPHIRE 100184L-512HM Radeon X1300 512MB (128MB onboard) 64-bit DDR PCI Express x16 Video Card PC Power & Cooling Silencer 610 EPS12V EPS12V 610W Continuous @ 40°C Power Supply 2 Patriot 512MB 240-Pin DDR2 SDRAM DDR2 800 (PC2 6400) Desktop Memory Model PSD251280081 LIAN LI PC-A16B Black Aluminum ATX Mid Tower Computer Case Athena Power BP-SATA3051B 3 x 5.25" Bays to 5 x 3.5" HD (SATA) Backplane Right now, I'm using the basic version of the OS, and everything seems to be working. I plan on buying Pro when I run out of space on these 3 drives. Network tranfers are fast, but they aren't as fast as I think they could be. I use a program called Online Eye, that does a great job of monitoring the actual megabit speed of network activity. I have a gigabit switch, with Cat 6 cabling, and my pc and the unraid box both have gigabit nics. I see spikes up to 270 megabits\sec. During transfers from my pc to the unraid. But every 10 seconds or so it goes to 0 in the middle of a transfer. It starts back up again, and Windows never misses a beat, and the over all speed is still a lot faster than my old NAS box, which never got over 90 megabits\sec even though it was supposed to have gigabit, but the transfer speed was a lot more consistant. I think unraid is better overall, but this is still an irritating problem.
February 25, 200818 yr i am not sure, but this may be the same behavior that has been mentioned in various other threads, and is related to the fact that parity has to be calculated at regular intervals...so what you see is supposedly expected behavior. i am still populating my 15-disk array with data, and since i have parity turned off until i copied all 8TB i currently have to my unRAID, i don't seem to be seeing the data-transfer drop that you are seeing...this would be consistent with my guess above. please , somebody, correct me if i am wrong.
February 25, 200818 yr I think your explanation is right. Unraid says "wait" periodically as the calculation portion is slower than the data transfer. Not a problem. It would be interesting to see if those with faster procs see delays of smaller durations, though when look at overall average throughput, I know it doesn't matter much. Bill
February 25, 200818 yr I'm pretty sure I tracked this behavior to the network traffic being stopped while the pdflush processes wrote data to the physical disks. It had a higher priority lock on the CPU at that time than either Samba, the MD driver, or the network driver. (I did not know which one was blocked, but one was, that's for sure). This is after the parity has been calculated and after the data has been written to the disk cache buffers. It is when those buffers are being written to the physical disks that network traffic is stopped. I described an experiment I did in this thread: http://lime-technology.com/forum/index.php?topic=1119.msg7955#msg7955 I temporarily used the "renice" program to make the pdflush priority slightly lower. In my experiment it smoothed out the network spikes you saw. Unfortunately, each pdflush process writes its set of blocks and then exits. A new pdflush process is then re-spawned as needed and at the original priority. My guess is that if pdflush was always set to a priority of "1" they would allow network traffic to continue while the disks were being written. Of course, this setting of priority for pdflush is deep inside the Linux kernel and has nothing to do with unRaid as it is common across all implementations of Linux. Certainly, the writing of a physical disk should not block network IO while the physical operation is performed. It should simply obey normal time-slice scheduling, relinquishing the CPU every once in a while so it can deal with other tasks (like network IO ) Joe L.
February 25, 200818 yr Author Interesting. I think that is what's happening. I set my pc monitor and my unraid box, so that I could see them both at the same time. Sure enough, when the transfer goes to 0, is when I see the hard drive activity light twinkle.
February 26, 200818 yr I understand Tom... it was an experiment. I do believe the existing exclusive lock on the CPU while waiting for the disks to be physically written is more extreme than necessary. The only time all network I/O should be stopped is if the entire disk buffer cache had reached its high-water-mark and was in danger of running out of memory. Otherwise, normal network activity to write to disks should fill the disks buffer blocks, and pdflush write them in the background Joe L.
Archived
This topic is now archived and is closed to further replies.