May 12, 201016 yr I have the DS-520G, but I have small low speed drives in it. 2 x 250's, 1 300 SATA I, 2 x 320's. Parity check speed is around 55,000kb/s. I have not benchmarked the parity write speed of the unit over the network. Directly on the machine with DD I get 34Mb/s on a 2.5" drive outside of the array. 35MB down to 20MB/s on a parity protected drive. But this is on the machine itself, not over the network. 5MB/s is too slow. I'll try it tonight with Teracopy and see what I get.
May 13, 201016 yr Awesome! Just to be clear, I got ~10MB/s on the machine itself between the 2 Greens. It's still too slow... just sayin'. I believe something is misconfigured somewhere, just don't know what yet. Even if I was stuck with that performance forever (I _will_ fix this, if fixable), I'm still happy. At $250.00, with 3 port multiplier ports, This thing was a steal. I'd say its worth ~400/500. I'm having a blast with this thing, and really dig unRaid and unMenu! I believe this is the type of box Limetech should be selling. The port multiplier ports are key. I'd like to see Tom do a box like this but with mini-sas (infiniband?)ports and allow daisy chaining. Put only 4 drives per chassis, as I believe thats how those work. I'd pay $700 for a box like that with unRaid on it and $500 for each "dumb" box hanging off it.
May 13, 201016 yr Awesome! Just to be clear, I got ~10MB/s on the machine itself between the 2 Greens. It's still too slow... just sayin'. Try purko's tunings. I get ~20MB/s on two old 7200 320GB maxtor drives. 4096000000 bytes (4.1 GB) copied, 207.165 s, 19.8 MB/s write complete, syncing reading from: /mnt/disk1/test.dd 4096000000 bytes (4.1 GB) copied, 50.6043 s, 80.9 MB/s root@unraid /mnt/disk1 #hdparm -tT /dev/sda /dev/sdb /dev/sda: Timing cached reads: 962 MB in 2.00 seconds = 480.86 MB/sec Timing buffered disk reads: 236 MB in 3.01 seconds = 78.44 MB/sec /dev/sdb: Timing cached reads: 996 MB in 2.00 seconds = 497.73 MB/sec Timing buffered disk reads: 228 MB in 3.00 seconds = 75.90 MB/sec root@unraid /mnt/disk1 #grep 'model name' /proc/cpuinfo model name : Intel® Celeron® M processor 1.00GHz root@unraid /mnt/disk1 #grep 'MemTotal' /proc/meminfo MemTotal: 1033484 kB How much ram do you have in your machine?
May 13, 201016 yr root@unraid:~# hdparm -tT /dev/sda /dev/sdb /dev/sda: Timing cached reads: 316 MB in 2.01 seconds = 157.22 MB/sec Timing buffered disk reads: 134 MB in 3.03 seconds = 44.22 MB/sec /dev/sdb: Timing cached reads: 306 MB in 2.02 seconds = 151.49 MB/sec Timing buffered disk reads: 170 MB in 3.01 seconds = 56.48 MB/sec root@unraid:~# grep 'MemTotal' /proc/meminfo MemTotal: 1026460 kB root@unraid:~# grep 'model name' /proc/cpuinfo model name : Intel® Celeron® M processor 1.00GHz As far as the Purko tweaks, I will check them again. I followed it like a recipe before (at least I thought so). I appreciate the help!
May 13, 201016 yr See attached syslog as harvested from unMenu. I know my time/date is wrong. I'm using ntp. Right now thats the least of my worries I appreciate the consultation Doctor! unraid_syslog.txt
May 13, 201016 yr See attached syslog as harvested from unMenu. I know my time/date is wrong. I'm using ntp. Right now thats the least of my worries I appreciate the consultation Doctor! Oct 22 19:03:51 unraid kernel: md: import disk0: [8,0] (sda) WDC WD2001FASS-0 WD-WMAUR0172889 offset: 63 size: 1953514552 Oct 22 19:03:51 unraid kernel: md: import disk1: [8,16] (sdb) WDC WD20EARS-00S WD-WCAVY2725803 offset: 63 size: 1953514552 You do have the offset jumper on the WD20EARS drive right?
June 11, 201016 yr Oct 22 19:03:51 unraid kernel: md: import disk0: [8,0] (sda) WDC WD2001FASS-0 WD-WMAUR0172889 offset: 63 size: 1953514552 Oct 22 19:03:51 unraid kernel: md: import disk1: [8,16] (sdb) WDC WD20EARS-00S WD-WCAVY2725803 offset: 63 size: 1953514552 You do have the offset jumper on the WD20EARS drive right? Well this still persists, and I have spare cyles so I am revisiting it. I physically checked them all, and they are correct. Your reply above implies that those lines in my log mean they aren't. What should it say there instead? How can the jumpers be in place and it still be wrong? Thanks for any help!
June 11, 201016 yr The jumpers change how the sectors are accessed internally to the drives. To the outside, the sector is 63 (as unRAID requires). To the drive, internally, the sector is 64. You have nothing to be concerned with.
June 11, 201016 yr Oct 22 19:03:51 unraid kernel: md: import disk0: [8,0] (sda) WDC WD2001FASS-0 WD-WMAUR0172889 offset: 63 size: 1953514552 Oct 22 19:03:51 unraid kernel: md: import disk1: [8,16] (sdb) WDC WD20EARS-00S WD-WCAVY2725803 offset: 63 size: 1953514552 You do have the offset jumper on the WD20EARS drive right? Well this still persists, and I have spare cyles so I am revisiting it. I physically checked them all, and they are correct. Your reply above implies that those lines in my log mean they aren't. What should it say there instead? How can the jumpers be in place and it still be wrong? Thanks for any help! Both are correct. To unRAID, the starting sector is 63. It MUST be for unRAID to recognize the partition as its own. The log entry will NEVER say anything about the jumper, or sector 64. That is being hidden from the OS as it all occurs on the disk. With the jumper installed, that number 63 is translated to 64 in the hard disk. It can then access sector 63 and sector 64 that follows more efficiently. Externally, it still looks like it used to... that is needed by the OS. Internally, it sifts all the sectors up by 1. Externally each sector is 512 bytes. Internally, they are 4096 bytes. The problem with efficiency without the jumper was that to read sector 63 and 64 required the disk to read two different sectors. Sector 63 was in one of the 4096 byte sectors, and sector 64 was in the next. The disk had to revolve once between reading them. This dramatically reduced performance. By pretending that sector 64 was actually sector 63 (by adding the jumper that adds one to all sectors) it only takes one read to get sectors 64, 65, 66, 67, 68, 69, 70, and 71. Joe L.
June 11, 201016 yr Author Logical disk I/O at the OS level is done by clusters, not sectors. Clusters are 4K (although it is configurable). When you read 1 cluster, if it is split over two 4K sectors, then you have ineffeciency. Setting the jumper makes each 4K cluster align to one 4K sector.
Archived
This topic is now archived and is closed to further replies.