Jump to content

UhClem

Members
  • Content Count

    245
  • Joined

  • Last visited

Community Reputation

3 Neutral

About UhClem

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed
  • Location
    NH, US

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. "Was that nine chips, or only eight? In all this excitement ..." -- Dirty Harry 😀
  2. Check locally for the Adaptec ASR-71605. PCIe 3.0 x8 6G SAS/SATA 16-port. Supported by Unraid. Handles throughput of at minimum 4500 MB/s (8 x 560 SSDs), and very likely ~6000. Found one on ebay.de for ~60eu. Link
  3. Sort of ... it shouldn't be used for one of the six array drives, since that would further divide the 650-700. But, it could/should be used for the cache drive; then it could only (slightly) impact mover operations, and only if TurboWrite was enabled. The (2-port?) add-in card would connect array drives 5 and 6. A "full-spec" PCIe x1 Gen2 card (e.g. ASM1061-based) , giving ~350 MB/sec, would not lower the "ceiling" of ~160 (for 4) on the mobo SATA. The only improvement would be that the cache SSD could operate at full (SataIII [~550]) speed, but that is moot, since, as your cache, it is inherently limited by your 1GbE network (on input) and your array (on output). Very little bang for the extra bucks, since you'd need a PCIe >=x2 card to handle >2 drives, and not lower the "ceiling". Here's a neat idea, if you really want to eliminate the speed bottleneck: (Assuming that your x16 slot is available,) Get a UNRAID-friendly LSI-based card (typically PCIe x8, at >= Gen2), and connect the built-in 4-bay Sata backplane to it. Note that the thick cable/connector (left of Sata-5), which connects that backplane to the mobo, is actually a Mini-SAS 8087. And can instead be connected to (one of the connections on) an add-in LSI card. That completely eliminates the bottleneck for SATA 1-4. "But, wait, there's more ..." Then you put a standard SAS-to-SATA breakout cable into the now-empty mobo connector and use 3 (of the 4) SATAs for drives 5 and 6, and your cache SSD. That gives you full SataIII for the SSD (FWIW) and you've still got SATA-5 and the eSata, plus "breakout #4", to play with for whatever. "But, wait ...." If you get a 4i4e card, you can (later) add 4+ more drives externally, and still no bottleneck! (Pretty neat, huh?) [Important, LSI card must have low-profile bracket.] I don't use UNRAID, so I can't be certain about the re-config issue. Once you've cleared that, I strongly encourage you to start with what you've already got. Not only will it give you time to think it all through, and find exactly the pieces that will serve you best, but it will give you an opportunity to assess your N40L's performance with current version of UNRAID. Then you can extrapolate from that initial CPU/throughput ratio to be sure that the CPU won't become a new/unexpected bottleneck if/when the throughput increases from 650 to 1000 (2-port card) or 1300+ (LSI).
  4. No limitation! -- for at least another decade (Since you mentioned that you'd be running 6 newer (ie, faster) array drives,) The SATA controller in the N40L (and 36L + 54L) has a maximum (combined) throughput limitation of ~650 MB/sec. With 4 array drives on the built-in SATAs (and 2 on the add-in), that would limit your "parallel" operations (parity-check, rebuild, Turbo-write) to 160 MB/sec, but many/most newer drives are capable of 200-250 MB/sec max (130-150 min). To maximize your array performance, you'd want to be very selective in your choice of add-in SATA card. The one you linked is based on the SiI3132, which is a notable under-performer (80MB/sec max for each of 2 drives [150-170 total])--scratch that one. Better would be any Asmedia ASM1061-based 2-port card; 170MB/sec each of 2 drives. At least that would preserve the 160 limitation imposed by the built-in. [Note: these configs don't utilize the N40L's eSata, so it would stay available for a backup/import-export external drive.]
  5. Congratulations! (And, what do you mean "almost"? [such a bargain, too.])
  6. How about this: [from your 800k syslog] lines 759-763 Mar 11 07:50:54 Tower kernel: ahci 0000:04:00.0: SSS flag set, parallel bus scan disabled Mar 11 07:50:54 Tower kernel: ahci 0000:04:00.0: AHCI 0001.0200 32 slots 2 ports 6 Gbps 0x3 impl SATA mode Mar 11 07:50:54 Tower kernel: ahci 0000:04:00.0: flags: 64bit ncq sntf stag led clo pmp pio slum part ccc sxs Mar 11 07:50:54 Tower kernel: scsi host7: ahci Mar 11 07:50:54 Tower kernel: scsi host8: ahci Then searching for 0000:04:00 leads to: [line 373] Mar 11 07:50:54 Tower kernel: pci 0000:04:00.0: [1b21:0612] type 00 class 0x010601 And [1b21:0612] is the Vendor ID (Asmedia) : Device ID (ASM1062) pair for that controller. "A rose by any other name ... is still a rose."
  7. Ultra320 SCSI is 320 MB/sec ... 12 drives ... even w/ 2 ports running is ~50 MB/sec per drive [if it can really share its bandwidth reasonably] --"Patience is a virtue."
  8. Maybe ... maybe not. Consider that the 9211-8i (and its LSI SAS2008-based brethren) appear to have an ultimate bottleneck of their internal CPU/memory/firmware which precludes them achieving the maximum (real-world/measurable) PCIe Gen2 x8 throughput of 3200 MB/s. Your tests, on the H310, show 2560 (8x320) MB/s. Whereas the 9207-8 (and its SAS2308 brethren) do have the "muscle-power" to achieve, and exceed, full Gen2x8 throughput (3200); you measured, on a Gen3x8, 4200 (8x525) MB/s--and that is limited, not by the 2308, but by maxing out the Sata3 (real-world) speed of ~525 [I suspect that SAS-12Gb SSDs would do better, no?***] So, for 9211 vs 9207, using Gen2, it comes down to a cost/benefit decision (plus, an appropriate degree of future-proof factor; re-use following a mobo upgrade). *** [Edit] Actually, NO -- it looks like 12G SAS connectivity was not offered until the 93xx series.
  9. Wouldn't the max throughput be (slightly) limited by the PCIe Gen2 of the R710? [ie, to ~400 MB/s each for 8xSata3-SSDs]
  10. Bad way to test for bandwidth limits/bottlenecks. ===== Fud's First Law: "If you push something hard enough, it will fall over."
  11. [my mistake] Yes, all those "generic" references to the Sonnet Allegro Pro card clouded my thinking. [Note: the one hyper-link to the Pro card (on first page) now 404's--shame on Sonnet--they should have "preserved" the link, redirecting it to its new "home", under their LegacyProducts, and suggested the new "Pro".] I totally agree with you regarding the need for documented specificity before taking action on a reference/suggestion for a functioning solution. And, NO, I'm not using any of these cards--just a passing interest in atypical "solutions". [I was aware of this thread, but never actually dug into it--then I was trying to find out more about the Pericom Semiconductor PI7C9X2G608GP switch for this UnRAID thread ... and here we are. I don't know what chips are used on the Allegro Pro 3.0 card, but the 3.1 card uses the Pericom PI7C9x2G308GP (can see it in the picture @ the Amzn lnk) [4<==>2x2]. I'm real curious to know which chip is used for the (2) USB controller chips. If anyone does get one to try, please do post a relevant snippet from either the kernel meggages or from lspci. tnx [Edit] Just found it--the 3.1 Pro uses 2 Asmedia ASM1142 Sorry for the confusion/distraction. Good luck to all on your quest.
  12. Amazon link Something interesting about the Sonnet card: it uses a PCIe switch chip to split a PCIe_V2 x4 connection into two x2's each going to one of two USB controller chips. Apparently, each of those USB chips has two "sub-devices" each of which can be passed (as desired here). Compare that to the Startech card, which also has a PCIe switch chip (from the same company), but its switch splits a PCIe_V2 x4 connection into four x1's, each going to its own USB chip. Yet, this one causes grief. In addition to working as you all desire, the Sonnet card has the advantage of higher maximum single-port throughput, since its (2) x2 chips can share their two-lane bandwidth on-demand/as-needed to its two "sub-devices". Whereas, the Startech, even if it worked for you, would limit each "sub-device" to an x1 lane of throughput. [I realize that connectivity (vs bandwidth) is more the goal here, but ... just saying ...] --UhClem "How can you be in two places at once, when you're not anywhere at all."
  13. Benson is correct. (I "guessed" wrong, based on assumptions about the on-screen messge. [The term "PM" triggered "port multiplier" when there aren't any; there are 4 ASM106x controller chips.] Also, I didn't realize the OP only had 2 drives connected--I thought the others were "missing" and grasped for a reason.)
  14. From the above screen shot, I would guess that your controller card has a single (2-port) ASM1062 Sata-controller chip, and each of those 2 ports is connected to one (of 2 [PM 0 & PM 1]) port-multiplier chip. Since that is a POST screen, only the first port/drive on each PM chip is seen (by the BIOS). That is not a problem. The problem is that the kernel does not recognize these specific port-multiplier chips, and never "activates" them--this results in none of the PM-connected drives going active. As stated by others, switch to a card known to work with the hardware (your mobo) and software (unRaid) in play.
  15. With 20+ data drives, and upgrading from one-parity to two-parity, there could be a prior/intervening performance bottleneck. Do you have sufficient (single-core/thread) CPU power? I.e., can you generate enough parity data (fast enough) to justify/validate your stated question? -- "If you push something hard enough, it will fall over."