Announcement

Collapse
No announcement yet.

Sabrent Rocket 4 Plus 1TB NVMe PCIe 4.0 SSD On Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Sabrent Rocket 4 Plus 1TB NVMe PCIe 4.0 SSD On Linux

    Phoronix: Sabrent Rocket 4 Plus 1TB NVMe PCIe 4.0 SSD On Linux

    Last year Sabrent launched the Rocket 4 Plus PCIe 4.0 NVMe solid-state drive and left me puzzled for months finding that the Linux performance was coming in short of expectations under Linux. However, Sabrent recently released a firmware update (v1.2) for the Rocket 4 Plus and now the drive seems to be much better positioned under Linux.

    https://www.phoronix.com/vr.php?view=30409

  • #2
    That fs-mark test is a real bugger: fs-mark: 3: 5000 Files, 1MB Size, 4 Threads

    Quickly ate up 20GB of space. I was like nah I'm good, and killed the test and freed up the space by doing: $ rm -rf installed-tests/pts/fs-mark-1.0.2/fs_mark-3.3/scratch/*

    Michael, is there a test you like for testing disk performance that's quick and dirty?

    Comment


    • #3
      Performance of these bandwidth-doubled drives are still not terribly spectacular, and running bare is becoming more of a concern. Looks like it's time for u.2 to see consumer availability. Big heatsink and set max power limits vs the 3-8watt (MB dependent) limit on the often uncovered m.2.

      Comment


      • #4
        Firmware updates, ugh. It used to be so easy. On my 486 I pulled the EPROM, put it into an EPROM eraser (UV black light) for 10 minutes, then burn the new firmware onto it using an EPROM burner. Don't forget to cover the little glass window with a sticker afterwards. Pop the IC back into the socket and power on the PC, easy.

        Then in the mid 1990's when Flash memory became a thing, you'd boot a DOS floppy and flash whatever firmware you want using the MS-DOS flashing tool. Same same into the 2000's, but with a FreeDOS bootable CD instead of a floppy. Mobos, SCSI/SAS cards, LAN cards, everything worked this way.

        Now it's a tangled web of proprietary flashing tools that only work on Windows OS. Unless you go with enterprise grade gear, then they often have a Linux tool. But sometimes the Linux tool was built using a very old toolchain and won't work on newer Linux distros, then you have to boot a CentOS 5 DVD and try again. Pretty soon you've spent your entire day trying to figure out how to flash a device. Ugh.

        My neighbor recently bought a $2000 mirrorless camera. Takes nice photos, sure, but the UI is buggy and slow, and there's a constant stream of firmware updates. Seems like every time he's out with it, he has to spend 20 minutes updating the firmware before he can start taking pics.

        Is it just me, or are consumers all beta testers now, and you have to pony up big $$$ for enterprise gear, to get the privilege of stable reliable equipment?
        Last edited by torsionbar28; 03 August 2021, 02:33 PM.

        Comment


        • #5
          Originally posted by perpetually high View Post
          That fs-mark test is a real bugger: fs-mark: 3: 5000 Files, 1MB Size, 4 Threads

          Quickly ate up 20GB of space. I was like nah I'm good, and killed the test and freed up the space by doing: $ rm -rf installed-tests/pts/fs-mark-1.0.2/fs_mark-3.3/scratch/*

          Michael, is there a test you like for testing disk performance that's quick and dirty?
          No...because you'll be testing the disk's internal cache instead of the actual disk performance.... large tests are mandatory for getting correct numbers on disk performance.

          Comment


          • #6
            Originally posted by cb88 View Post
            No...because you'll be testing the disk's internal cache instead of the actual disk performance.... large tests are mandatory for getting correct numbers on disk performance.
            Yup, exactly. Just a few years ago spinning disks had only 16 MB of cache, so you only needed to write a few hundred MB for a valid test. Even the biggest newest HDD's top out at just 256 MB.

            But with SSD's, even many cheap ones have a few GB of DRAM cache. Some even use a few GB of NAND as a pseudo-SLC cache. So the only way to get a proper benchmark is to write a few 10's of GB or for a larger SSD, a few hundred GB.

            Comment


            • #7
              Originally posted by cb88 View Post

              No...because you'll be testing the disk's internal cache instead of the actual disk performance.... large tests are mandatory for getting correct numbers on disk performance.
              I see, that makes sense thanks.

              I was hoping for something similar to hdparm, which is usually my go-to for a quick bench.
              Code:
              $ sudo hdparm -Tt /dev/md126p2
              
              /dev/md126p2:
              Timing cached reads: 32856 MB in 2.00 seconds = 16446.30 MB/sec
              Timing buffered disk reads: 3062 MB in 3.01 seconds = 1018.52 MB/sec
              $ sudo hdparm -Tt /dev/md126p2
              
              /dev/md126p2:
              Timing cached reads: 33416 MB in 2.00 seconds = 16727.25 MB/sec
              Timing buffered disk reads: 3062 MB in 3.01 seconds = 1018.83 MB/sec
              $ sudo hdparm -Tt /dev/md126p2
              
              /dev/md126p2:
              Timing cached reads: 33252 MB in 2.00 seconds = 16644.65 MB/sec
              Timing buffered disk reads: 3038 MB in 3.00 seconds = 1011.64 MB/sec
              To your point, "cached" and "buffered" reads. I run it three times to get a feel for the average, but that's about the extent I go to benchmarking the drive. That's on a RAID0 of two Samsung 860 EVO's. Blazing fast, glad I gave RAID a shot

              Comment


              • #8
                Originally posted by perpetually high View Post

                I see, that makes sense thanks.

                I was hoping for something similar to hdparm, which is usually my go-to for a quick bench.
                Code:
                $ sudo hdparm -Tt /dev/md126p2
                
                /dev/md126p2:
                Timing cached reads: 32856 MB in 2.00 seconds = 16446.30 MB/sec
                Timing buffered disk reads: 3062 MB in 3.01 seconds = 1018.52 MB/sec
                $ sudo hdparm -Tt /dev/md126p2
                
                /dev/md126p2:
                Timing cached reads: 33416 MB in 2.00 seconds = 16727.25 MB/sec
                Timing buffered disk reads: 3062 MB in 3.01 seconds = 1018.83 MB/sec
                $ sudo hdparm -Tt /dev/md126p2
                
                /dev/md126p2:
                Timing cached reads: 33252 MB in 2.00 seconds = 16644.65 MB/sec
                Timing buffered disk reads: 3038 MB in 3.00 seconds = 1011.64 MB/sec
                To your point, "cached" and "buffered" reads. I run it three times to get a feel for the average, but that's about the extent I go to benchmarking the drive. That's on a RAID0 of two Samsung 860 EVO's. Blazing fast, glad I gave RAID a shot
                I don't think there is a way to do that on SSDs.... the reason being is that writes go into different levels of flash depending on how large they are, so if you write 1GB of data to an SSD it will go very fast, but you'll see it drop off as the SLC cache or Dram cache runs out.

                Data that has been on the drive awhile untouched eventually gets migrated into MLC or TLC areas etc..

                Comment


                • #9
                  Originally posted by torsionbar28 View Post
                  Firmware updates, ugh. It used to be so easy. On my 486 I pulled the EEPROM, put it into an EEPROM eraser (UV black light) for 10 minutes, then burn the new firmware onto it using an EEPROM burner. Don't forget to cover the little glass window with a sticker afterwards. Pop the IC back into the socket and power on the PC, easy.
                  Doesn't sound too easy. Those burners must have been rare devices.

                  Originally posted by torsionbar28 View Post
                  Then in the mid 1990's when Flash memory became a thing, you'd boot a DOS floppy and flash whatever firmware you want using the MS-DOS flashing tool. Same same into the 2000's, but with a FreeDOS bootable CD instead of a floppy. Mobos, SCSI/SAS cards, LAN cards, everything worked this way.
                  That was back when DOS was the standard...

                  Originally posted by torsionbar28 View Post
                  Now it's a tangled web of proprietary flashing tools that only work on Windows OS. Unless you go with enterprise grade gear, then they often have a Linux tool. But sometimes the Linux tool was built using a very old toolchain and won't work on newer Linux distros, then you have to boot a CentOS 5 DVD and try again. Pretty soon you've spent your entire day trying to figure out how to flash a device. Ugh.
                  Manufacturer laziness and the fact Windows is everywhere (and probably in the manufacturer's plants too!).
                  I do wish things were better in this regard.

                  Also most of these tools are ugly as hell and have spartan UIs.

                  Originally posted by torsionbar28 View Post
                  My neighbor recently bought a $2000 mirrorless camera. Takes nice photos, sure, but the UI is buggy and slow, and there's a constant stream of firmware updates. Seems like every time he's out with it, he has to spend 20 minutes updating the firmware before he can start taking pics.
                  You know what I do? I never upgrade my devices' firmware unless there is a major problem (like my motherboard freezing the entire computer after a few hours).
                  It's unneeded hassle and often a new firmware brings absolutely nothing new (unless it is a big device like a motherboard).

                  Originally posted by torsionbar28 View Post
                  Is it just me, or are consumers all beta testers now, and you have to pony up big $$$ for enterprise gear, to get the privilege of stable reliable equipment?
                  It isn't just you. It does feel like it.
                  With so many reports of hardware failing too early, SSDs going from MLC to TLC and to QLC, horrible return processes, and other things, it does feel like it.

                  Comment


                  • #10
                    Originally posted by tildearrow View Post
                    Doesn't sound too easy. Those burners must have been rare devices.
                    By 'easy', I mean the process is standardized, well defined, and without 'gotchas' or crazy prerequisites. You knew exactly how long the process takes and what the steps are before you began. Plus it was a standard process for all computer equipment, not specific to any one vendor. At the time, I used the EPROM burner at my work, I didn't have one at home. Nowadays I use a GQ-4x which is inexpensive and convenient for burning ROMS for vintage equipment (mobos, vga cards, etc) if you're into that sort of thing. Also useful for automotive DIY, now that everything in cars is computer controlled.
                    Last edited by torsionbar28; 03 August 2021, 02:38 PM.

                    Comment

                    Working...
                    X