UhClem

Members
  • Content count

    217
  • Joined

  • Last visited

Community Reputation

1 Neutral

About UhClem

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed
  • Location
    NH, US
  1. Listen up, everybody ... Port Multiplication is a can of huge bucket!! of worms. Ever since the pioneering SiI3132 (and its 31xx brethren) [as PM-aware controller] and the SiI 3726 (& 4726/5744) [as Port Multpliers], not a single one of the "me too" followers has come within a mile of correctly implementing even 20% of the [/S]ATA/AHCI Specification for Port Multiplication. Yes, a specific controller chip will actually behave correctly in combination with a specific PM chip (usually with the necessary assistance of a vendor-supplied driver [like a private nurse as the only one who can communicate with the brain-damaged patient]) (or because the two are from the same manufacturer who precisely designed them to inter-operate correctly with each other [but each, independently, is provably brain-damaged]). As an example of that last point, I refer you to the nearby thread on the PEX-40071, which does the PM thing with a Marvell 9235 & a Marvell 9705 (the PM). It actually behaved/performed admirably. But when I tried to connect a SiI3726 (which my gut tells me does a thorough job of meeting the Spec) to a Marvell 9230 (a 9235 with a shoeshine), the results were a total disaster ... even though I can (sort of) get a Marvell 9120 to dance with that same 3726; they dance fine, but they need help getting out on the floor [Don't ask ... just stay away!] Now you know how many shakers of salt you need when you see "port multiplier" used in a bullet list of features for a controller or enclosure ... Caveat Emptor. --UhClem "Hey, mister, is this a game of chance?" ... "Not the way I play it."
  2. 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
  3. 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."
  4. 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)?
  5. 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.
  6. 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!)
  7. 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
  8. 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
  9. Good! The drive on sde, and the port itself, are fine. (Maybe just a little slow at the very very beginning. Or maybe not even that. It could be that that drive is a little slow in going from the "active/idle" state to the "active/active" state. Not to worry. But, if I (or you) were curious, reversing the numbers in the "for ..." line would tell the story. Thanks--now, there is a permanent place for this information. (We will leave the ID of the 5th port location for the next guy.) Yes, the actual downloaded file (dskt.txt) was moved, and renamed, when: >>> change that to mv /boot/dskt.txt /dskt I think you should keep "dskt" (it is tiny), but the question is "Where?" Guys, help me & Zippi out here ... [Again, I don't use unRAID]; what is the (non-volatile) equivalent of /usr/bin (or, maybe better [if it is in $PATH], $HOME/bin)? --UhClem
  10. There might be a problem with the sde drive (or even the port it's connected to). Run the following: for i in 0 1 3 5 10 20 do /dskt O $i e [that is a capital-O] done and please report the results.
  11. No we were just pushing it to its limits, so you could know how best to use it. You can definitely ignore those warnings. (They were [harmless] mistakes by unRAIDs logger.) No clear reason to change the card. You can even use the other 2 ports for other (than unRAID) drives--like a DVD/BluRay drive, or a backup drive thru an eSata adapter on the case rear. Or, if you really expand your unRAID array (beyond 9 drives total), you can put an additional unRAID data drives on those 2 ports. It just means that Parity Checks, and Array Rebuilds, will run ~15-25% slower. One last question (but no more tests) which 4 physical Sata ports were we just using? The four closest to the rear of the case, or the front of the case? thanks --UhClem "If you push something hard enough, it will fall over." Fud's First Law
  12. I agree, but (most probably) not pertinent to the goals of the testing.
  13. Thanks. The first set are the speeds for the drives, tested individually. That is, with no contention (with other drives) for the controller (and its x2 [pcie v2] limit of ~750 MiB/s, or, and most important in this case, no contention for the single Sata port (which all 4 are multiplied off of) (and its 6Gbps [~550 MiB/s] limit). Those numbers serve as reference points for further testing ... The second set are the speeds for the drives, tested concurrently; all competing for the resource(s). In this example, the total bandwidth provided (by the 9705 port multiplier) was only ~480 MiB/s [vs 550], hence exposing it as the constraining component. That may turn out to be typical overhead for Port Multipliers, in general. (When I subject a SiI3726 port multiplier [10+ years older; only Sata II] to a similar test, it provides a maximum of ~240 MiB/s. There is some specific significance of all of this, for you Zippi. You should probably only put 2 of your unRAID array data drives on the multiplied ports, along with the SSD. The other 3 (native) ports can each have an array data drive. Your parity drive(s) should go on mobo ports, as can additional data drives. What do you think, johnnie.black? (You've played in this sandbox, right?) --UhClem
  14. Thanks, jonathanm. (I'm not an unRAID user.)
  15. Proceed with the download, install, and testing of dskt. Thank you.
Copyright © 2005-2017 Lime Technology, Inc. unRAIDĀ® is a registered trademark of Lime Technology, Inc.