March 23, 20179 yr 59 minutes ago, Zippi said: I'm sorry, i just wanted to learn.... Hi, Zippi. OK by me--I (think I) understood. [Between time-difference/job/machine-at-home, you had a narrow time window ...] And, since you want to learn, as do I, and probably more than a few of the folk still following this thread do also, I'm going to follow up with another test request in a few minutes ... --UhClem
March 23, 20179 yr Zippi, when you have the opportunity, I'd appreciate it if you could perform the following test: (With the SSD & 3 Reds connected back to those 4 (multiplied) ports, and a fresh boot-up of unRAID system) (and with your current directory in /boot where you would have the dskt script) dmesg > DM_before.txt for i in 1 2 3 4 ; do ./dskt O 50 a b c d > dskt_out_$i.txt & done wait dmesg | tail -99 > DM_after.txt (Be sure to replace the a b c d with the correct 4 drive letters for SSD & 3 Reds now.) Then, please paste into a reply post, the output from cat dskt_*.txt and attach to that post the two files DM_before.txt & DM_after.txt Thanks a lot. --UhClem
March 23, 20179 yr 3 minutes ago, UhClem said: (and with your current directory in /boot where you would have the dskt script) @Zippi, he means type cd /boot before you start typing the rest of the commands. Sorry if you already knew, but wanted to catch it if you didn't. The two text files he wants you to attach will be in the root of your USB.
March 23, 20179 yr 1 hour ago, jonathanm said: he means type cd /boot before you start typing the rest of the commands. Thank you very much! (You just might have saved/avoided an additional time[-differenced] window.) (Why the hell didn't he just say what he means then? Oh, wait, that's me!) Edited March 23, 20179 yr by UhClem
March 23, 20179 yr Author When i do this it return "no such file or directory": for i in 1 2 3 4 ; do ./dskt O 50 a b c d > dskt_out_$i.txt & done It generated dskt_out_1( and 2 3 4 ) .txt with 0 byte. DM_before e DM_after are OK Zippi. Edited March 23, 20179 yr by Zippi
March 23, 20179 yr 7 minutes ago, Zippi said: When i do this it return "no such file or directory" Did you copy the dskt.txt to the root of your USB? Did you type mv /boot/dskt.txt /boot/dskt Did you check the actual drive letters for the 4 drives? I doubt they are actually a b c d.
March 23, 20179 yr 1 hour ago, UhClem said: (Why the hell didn't he just say what he means then? Oh, wait, that's me!) Heh, you did. It's just the translation from geek to layperson was missing.
March 23, 20179 yr Author Just now, jonathanm said: Yes - Did you copy the dskt.txt to the root of your USB? No - Did you type mv /boot/dskt.txt /boot/dskt Yes - Did you check the actual drive letters for the 4 drives? I doubt they are actually a b c d. I retry.....
March 23, 20179 yr 2 minutes ago, Zippi said: Yes - Did you check the actual drive letters for the 4 drives? I doubt they are actually a b c d. So in the unraid main gui the 3 WD Reds and the SSD are actually (sda), (sdb), (sdc), and (sdd)?
March 23, 20179 yr Author I did: 1. mv /boot/dskt.txt /boot/dskt 2. cd /boot 3. dmesg > DM_before.txt 4. for i in 1 2 3 4 ; do ./dskt O 50 a b c d > dskt_out_$i.txt & done output: [1] 17061 [2] 17062 -bash: /dskt: No such file or directory [3] 17063 [4] 17064 [1] exit 127 /dskt O 50 c d e f > dskt_out_$i.txt Zippi. Edited March 23, 20179 yr by Zippi
March 23, 20179 yr Author 5 minutes ago, jonathanm said: So in the unraid main gui the 3 WD Reds and the SSD are actually (sda), (sdb), (sdc), and (sdd)? NO, sdc sdd sde sdf
March 23, 20179 yr 1 hour ago, UhClem said: for i in 1 2 3 4 ; do ./dskt O 50 a b c d > dskt_out_$i.txt & done 1 hour ago, UhClem said: (Be sure to replace the a b c d with the correct 4 drive letters for SSD & 3 Reds now.) 4 minutes ago, Zippi said: NO, sdc sdd sde sdf So, the line should be: for i in 1 2 3 4 ; do ./dskt O 50 c d e f > dskt_out_$i.txt & done
March 23, 20179 yr Author But what is all this? Zippi. DM_before.txt DM_after.txt dskt_out_1.txt dskt_out_2.txt dskt_out_3.txt dskt_out_4.txt
March 23, 20179 yr 1 hour ago, Zippi said: But what is all this? Before I answer, just one final verification. Did the DM_before.txt file (that you attached) get created before the "for ... done" was executed, and was the DM_after.txt file created after that "for ... done" was executed? What I mean is : Was the entire 4-line test sequence performed, in its entirety, with the (final, and successful) "for ... done" line as line #2 ?? (The results do not have their full meaning unless they were generated as intended.) Thanks --UhClem Just a stranger in a (not so) strange land. Edited March 23, 20179 yr by UhClem
March 23, 20179 yr Author 8 minutes ago, UhClem said: Before I answer, just one final verification. Did the DM_before.txt file (that you attached) get created before the "for ... done" was executed, and was the DM_after.txt file created after that "for ... done" was executed? Thanks --UhClem Just a stranger in a (not so) strange land. I think so but i can't swear because i went in the usb-root after the end of all your lines..... Possibly tomorrow i can try again..... Edited March 23, 20179 yr by Zippi
March 23, 20179 yr 1 hour ago, Zippi said: I think so but ... Well, let's be sure ... type cd /boot ls -lt [dD]*_*.txt and is DM_after.txt at the top & DM_before.txt at the bottom? And the 4 dskt_out* in between (their order among each other doesn't matter)? Edited March 23, 20179 yr by UhClem
March 23, 20179 yr Author i was already in /boot.... and is DM_after.txt at the top & DM_before.txt at the bottom? And the 4 dskt_out* in between (their order among each other doesn't matter)? Yes, correct! Zippi. Edited March 23, 20179 yr by Zippi
March 23, 20179 yr 6 hours ago, Zippi said: Yes, correct! Beautiful! The original test was a quick "stress test"; this last one was more of a quick "torture test". The system might have winced a little during the test, but it did come away smiling. The test result itself (dskt_out_*.txt) looks pretty damn good; my only quibble would be the uneven (albeit, consistent) apportionment of bandwidth to the 4 devices (ie, 15 60 37 13 [vs (e.g.) 30 32 29 34]) during each run[**]. The 4 concurrent runs were nicely consistent with each other. And, the total combined bandwidth was about 505 MiB/s, which, in decimal terms [unRAID community's "preference"] is about 530 MB/s ... on that single 6Gbps connection (9235<=>9705). The consistency of the 4 runs with each other strongly suggests that they were running (essentially precisely) concurrently. If one had finished "late" (or started "early"), it would have had a different/unique result. The fact that DM_after.txt showed no (added) kernel messages indicates that, while the 9235/9705 may have been under duress, they never "cried uncle" [Zippi gets to learn some American slang :)] I can now edit my earlier post with the skeptical misgivings about potential reliability problems. And also suggest that fireball3 reconsider his blacklisting of the card. [**] This should be of no concern to you, Zippi, because the test's methodology does not exactly mimic unRAID's behavior during Parity Checks & Rebuilds ... [I'm having trouble with a Geek=>Layperson on this ...Just trust me and ignore my "quibble"]. -- UhClem Nephew: "Uncle Gus, that ferryboat race was the biggest gamble in the world." Gus (WC Fields): "That was nothing, son. I remember when Lady Godiva put everything she had on a horse." Edited March 24, 20179 yr by UhClem humor?
March 25, 20179 yr On 23.3.2017 at 11:20 PM, UhClem said: 530 MB/s ... on that single 6Gbps connection Do you think a fully populated card will pull ~1060 MB/s? This woulb be beyond the PCIe 2.0 spec.
March 25, 20179 yr 17 minutes ago, Fireball3 said: Do you think a fully populated card will pull ~1060 MB/s? This woulb be beyond the PCIe 2.0 spec. No, that was with a single port (one of four) in use, in this case the one connected to the port multiplier. I tested a 4 port 9230 and max usable bandwidth is about 800MB/s, so I would expect that one to have similar speeds, i.e., about 100MB/s with all 8 ports in use and about 200MB/s with only the 4 actual 9230 ports (having a single device on the multiplied port).
March 25, 20179 yr 5 minutes ago, johnnie.black said: about 100MB/s with all 8 ports This is why I "blacklisted" the card. Fully loaded it's choking.
March 25, 20179 yr 3 hours ago, Fireball3 said: 3 hours ago, johnnie.black said: about 100MB/s with all 8 ports This is why I "blacklisted" the card. Fully loaded it's choking. Sure, but you've "overfilled its plate" (below). That is why I advised Zippi to put (& keep) his cache drive on one of the multiplied ports, and leave another one either empty or as the place for an optical or backup drive. With 3 array drives on the 3 "native" 9235 ports, and 3 more array drives on "multiplied" ports, you have a more respectable ~135 MB/s "choke point". And. let it not go unnoticed that by relocating the cache drive, and maybe an additional non-array drive, we free up one, or two, (likely) full-speed ports for array usage. (Like a bass-ackward "doggie bag".) Still, the PEX-40071 is not a good value [@ $90-100]. But if you only have x2 lanes available, and need 5-6 additional array slots (plus, maybe, a 2-slot doggie bag), it ain't bad [enough for the blacklist]. --UhClem Edited March 25, 20179 yr by UhClem
March 31, 20179 yr Thanks you guys for all the valuable information, I purchased the same card when doing my build, but do not have any drives going to it yet. Reason for buying this card over the other suggested cards was price. $48.00 usd open box item that was listed as a plug and play item at the time. My goals is to use 4 of the 8 ports for 4 WD red array drives. What I do not understand is the varied differences from the first test which averaged 136MB/s across the HDDs, but then the second test shows sdc = 15.16 MiB/sec sdd = 60.61 MiB/sec sde = 37.64 MiB/sec sdf = 13.25 MiB/sec So is the first test, what the individual drive is capable of of through the card? and is the second test, Under maximum load what the card receives as bandwidth allocation? Edit: The test result itself (dskt_out_*.txt) looks pretty damn good; my only quibble would be the uneven (albeit, consistent) apportionment of bandwidth to the 4 devices (ie, 15 60 37 13 [vs (e.g.) 30 32 29 34]) during each run[**]. The 4 concurrent runs were nicely consistent with each other. And, the total combined bandwidth was about 505 MiB/s, which, in decimal terms [unRAID community's "preference"] is about 530 MB/s ... on that single 6Gbps connection (9235<=>9705). The consistency of the 4 runs with each other strongly suggests that they were running (essentially precisely) concurrently. If one had finished "late" (or started "early"), it would have had a different/unique result. The fact that DM_after.txt showed no (added) kernel messages indicates that, while the 9235/9705 may have been under duress, they never "cried uncle" [Zippi gets to learn some American slang :)] Edited March 31, 20179 yr by shanelovell Copy and pasting
Archived
This topic is now archived and is closed to further replies.