• Content count

  • Joined

  • Last visited

Community Reputation

20 Excellent

About MRFS

  • Rank
  1. Here's the "method" we've been applying with the above: try to maintain apples-to-apples comparisons of 4 x data channels i.e. 4 x SATA-III devices in RAID-0 4 x PCIe 3.0 channels in the DMI 3.0 link 4 x PCIe 3.0 lanes in a single NVMe M.2 device
  2. Here's one more ATTO measurement of 4 x Samsung 840 Pro SSDs in RAID-0, same chipset as above: 1.0 - (1,879 / 2,400) = 21.7% aggregate overhead
  3. For the sake of comparisons, here are 2 controlled measurements of a RocketRAID 2720SGL controller with x8 edge connector, PCIe 2.0 chipset, driving 4 x Samsung SATA-III SSDs at 6G, RAID-0: upstream bandwidth is x8 @ 5 GHz / 10 bits per byte = 4.0 GB/s theoretical max headroom is 4 x SSD @ 600 MB/s = 2.4 GB/s MAX READ speed (measured) = 1.846 GB/s The following ATTO graphs are THE BEST I've seen with this RAID-0 configuration: 1.0 - (1,846 / 2,400) = 23.0% aggregate overhead with 4 x Samsung 840 Pro SSDs: Here a comparable measurement using a very similar motherboard, 4 x Samsung 850 Pro SSDs: Thus, it should be very interesting when an NVMe RAID controller, properly installed in a compatible x16 PCIe 3.0 expansion slot, can drive 4 x Samsung 960 Pro M.2 SSDs in RAID-0 mode! There is an engineering elegance that obtains with the following: 4 @ x4 = x16 x16 PCIe 3.0 lanes = 4 x M.2 SSDs @ x4 PCIe 3.0 lanes
  4. And, there really are not very many RAID controllers with x16 edge connectors: it appears that RAID controller vendors have been slow to catch up with the x16 edge connectors widely available with single and multiple video cards (SLI and Crossfire). (Honestly, I've been pounding on this topic for at least 10 years! Here's a PCIe 2.0 RAID controller with x16 edge connector from Highpoint: (RAID-5 but no RAID-6, according to Newegg's specs) Remember that each PCIe 2.0 lane oscillates at 5 GHz with the 8b/10b legacy frame: i.e. 500 MB/sec. per x1 PCIe 2.0 lane. Thus, what you lose with the slower lane speed, you make up with a larger number of cheap SSD storage devices, and an obviously large upstream bandwidth. MAX HEADROOM across that x16 edge connector is x16 @ 500 MB/sec = 8 GB/second (PCIe 2.0 legacy frame is 10 bits per byte: 1 start bit + 8 data bits + 1 stop bit) An x8 PCIe 3.0 edge connector has just about the same upstream bandwidth: x8 @ 8 GHz / 8.125 = 7.87 GB/s (the PCIe 3.0 jumbo frame is 130 bits / 16 bytes = 8.125 bits per byte)
  5. Forgive me for my obvious preference for Highpoint stuff: I've had much success with their RocketRAID 2720SGL controller, and that's the reason for my bias. FYI: when you step up to PCIe 3.0 RAID controllers, there are a multitude of choices with x8 edge connectors, and lots of price variations e.g. search Newegg for "RAID controller" and then refine your search further. Here are the latest PCIe 3.0 RAID controllers with x8 edge connectors from Highpoint: HighPoint RocketRAID 3740A 12Gb/s PCIe 3.0 x8 SAS/SATA RAID Host Bus Adapter HighPoint RocketRAID 840A PCIe 3.0 x8 6Gb/s SATA RAID Host Bus Adapter The main problem with SAS SSDs, of course, is their much higher unit costs which appear to be out of proportion to the mere increase in data transmission speed (12Gb/s). Even so, both of the latter 2 Highpoint controllers support RAID-5 and RAID-6, as do the more expensive competitors e.g. Areca, LSI, Adaptec, Avago etc. We are frankly waiting to see what AMD's Zen CPUs and AM4 chipsets have to offer: I've written to AMD's CEO recently to recommend that AMD might OEM Highpoint's model 3840A NVMe RAID controller, particularly if the AM4 chipset does not support all modern RAID modes with 4 x M.2 or 4 x U.2 ports integrated into AMD's AM4 chipsets. So, we are playing a wait-and-see game here, at the moment Hope this helps.
  6. Here's my prediction, using the 950 scaling factor (from JBOD to 2-member RAID-0): 950 RAID / 950 JBOD = 3,255 / 2,229 = 1.460 960 JBOD = 3,355 x 1.460 = ~4,900 MB/sec (faster than DMI 3.0's max headroom of 3,938.4 MB/sec) The raw upstream bandwidth of a single PCIe 3.0 x16 edge connector is: x16 x 8 GHz / 8.125 bits per byte = 15,753.8 MB/sec Highpoint computed 15,760, so we're VERY close!
  7. Here's what I calculate for the Samsung 960 Pro M.2, using the 2 READ measurements in the charts above: 960 PRO RAID [NVMe] 1.0 - (3,579 / 3,938.4) = 9.1% overhead 960 PRO JBOD [NVMe] 1.0 - (3,355 / 3,938.4) = 14.8% overhead I submit to you that the 960 Pro is SO FAST, it's already bumping against the max upstream bandwidth of Intel's DMI 3.0 link. I'll venture to predict that the RAID measurement will be much higher, if those 960 Pro SSDs are mounted instead in 2.5" adapters like this one: and wired to an NVMe RAID controller with x16 edge connector, like Highpoint's RocketRAID model 3840A:
  9. I just came across your excellent question, but I also do not have any hard empirical numbers to share with you. Possibly, one theory I maintain for the general absence of such numbers is the reality of quad-core CPUs that are rarely running flat-out at 100% utilization. The latter means, quite bluntly, that a high-speed idle core is quite capable of doing RAID parity calculations. Also, our experience has been almost entirely with RAID-0 arrays -- for speed -- and we have opted for less expensive RAID controllers that shift some of the overhead to those idle CPU cores. To illustrate, even an LGA775 CPU like Intel's Q9550 has such a large amount of on-chip Level 2 cache (12MB), that cache is capable of operating at speeds equal to, or faster than, the speed of dedicated RAID chips mounted on Add-On Cards ("AOC"). You could begin your own research by assembling a Windows software RAID on a more modern multi-core CPU, and monitor standardized tests with Windows Task Manager. For RAID-0 arrays, in particular, another factor to consider is the cumulative amount of SSD cache that results from a RAID-0 array e.g. 4 x Samsung 750 EVO @ 256MB cache effectively equals 1GB of SSD cache. With such a setup, all that a cheap RAID AOC needs to do is the PLX-type switching between the edge connector and 4 such RAID members: the rest of the overhead can be handled easily by idle CPU cores and the controllers embedded in each member SSD. Bottom line: at least for RAID-0 arrays of fast SATA-III SSDs, that question is a little moot. For other modern RAID modes, your question still awaits comparative empirical analyses. For M.2 RAID arrays, it is now well known that the limiting factor is the max upstream bandwidth of Intel's DMI 3.0 link. One observation I noted yesterday was a measurement which showed a RAID-0 of 2 x Samsung 960 Pro running at 90% of its maximum theoretical throughput e.g. 32 Gbps / 8.125 bits per byte x 0.90 ~= 3,544 MB/second !!! An aggregate controller overhead less than 10% is quite extraordinary for 2 x M.2 SSD. However, we won't know how much CPU overhead is required of RAID-5 and RAID-6 parity calculations until motherboards start supporting 4 x M.2 -or- 4 x U.2 ports that are NOT downstream of Intel's DMI 3.0 link.
  10. " While a few motherboards support it, the penetration is overall very low and something that will require more server support if M.2 is to gain mindshare in the enterprise." Would the following adapter line up properly with 2.5" backplanes: Today, the latter website was UP and DOWN, so I'll add the Newegg link:
  11. "Sequential Write: 175MB/s" Is that a typo?
  12. I agree with continuum: the interface is a single SATA connector, and that necessarily implies that the host will see only one (1) SATA device. If I were installing an OS on that drive, I would format the first 20-30 GB as a dedicated OS partition, then format the rest as a dedicated data partition. Because the spinning platter rotates at 5,400 rpm, you'll get better performance if the OS is stored on the outermost tracks: READ and WRITE speeds are directly proportional to track circumference, in order to maintain relatively constant recording density. That's why HDDs slow down as they fill up: the innermost tracks are necessarily slower in direct proportion to their shorter track radius.
  13. Here's how easy it is to build solid backup storage server. I would recommend these parts: Find a stock Intel heatsink/fan unit for the LGA775 socket, remove the faulty push-pins, and use this backing plate instead: Startech make a nice .5 meter SFF-8087 cable that works great with the RocketRAID 2720SGL: leave the INT13 setting factory ENABLED if you plan to boot from this controller; otherwise, install the card withOUT any drives attached (no cables), then download and flash the BIOS to DISABLE INT13 after installing Windows. The Intel D945 can be easily overclocked to 2 cores @ 4.0 GHz w/ SpeedStep, using: 240 MHz Front Side Bus 480 MHz DRAM clock, and that's why the G.SKILL DDR2-1066 is ideal, because it can exceed the JEDEC setting normally limiting the speed of standard DDR2-800 DRAM. The rest you already know how to do (I presume) e.g. power supply, chassis, etc. One last thing, for our storage servers, we install the 2720SGL in the first x16 slot, to ensure it gets max PCIe lanes assigned by these older chipsets. Another option is to find a micro-ATX LGA775 motherboard with integrated graphics: that will eliminate the cost of a video card e.g.:
  14. If you want to laugh out loud at my reply, please do so. I don't know how much data you need to migrate: without that knowledge, what I'm about to say may be totally in appropriate. Several years ago, malware hit our SOHO network and "migrated" to every machine in that network. It took 8 DAYS to re-build everything and disinfect every machine. After that burn, we decided that THE BEST WAY to keep a PC virus-free is to TURN IT OFF!! (lol here is aok Whenever we have been faced with a similar challenge, we ALWAYS start with a FULL BACKUP of all data, including of course the operating system and all files and databases. That FULL BACKUP is copied to one of our aging "backup servers" and then we turn that backup server OFF -- COMPLETELY OFF. Because PC hardware is so cheap now, and because some data bases have become invaluable e.g. mirror images of a website, we do not hesitate to maintain cheap "white boxes" with aging CPUs that do very little except to XCOPY data from here to there. We have even perfected a PUTT and GETT pair of Command Prompt BATCH files that do the job very well, particularly when we only need to backup a sub-folder in our website mirror. Our consistent approach has also been to maintain a formal separation between C: system partitions, and all other partitions. Every discrete storage device or RAID array is formatted with a primary partition exactly equal in size and contents to the Windows C: system partition. The remainder of each such storage device is formatted with a Data partition e.g. D: or E: (in Windows parlance). All of our key workstations host at leasat 2 identical copies of the same OS. From experience, we know that it doesn't take too much to completely corrupt a working OS e.g. the other day, a HDD crashed and that crash ended up corrupting the Windows Registry. So, with our dual-OS setup, we simply re-booted from the backup OS and restored a drive image of the primary C: partition: piece o' cake. As such, my first choice is your Option "A", making sure that you have a working "backup server" with redundant backups of all operating system and dedicated data partitions. Trying to mix HDDs and SSDs sounds like too much work: the future is solid-state, and I think you should migrate now to new system with SSDs and a quality / compatible RAID controller. You can buy large HDDs for your backup server, the sole purpose of which is to archive multiple redundant copies of really important data. Hope this helps. p.s. I would be very interested to read more Comments from others who study your question.