What's new

Entware Entware: which USB stick performs well?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Rest is elementary... I've done steps (1), (2) and (3) above several times over across multiple SoC's running ARMv7a

I've also done it a couple of times on my recently purchased SBC. End result ..I got better benchmarks that I've never seen reported on the web.. The process does bring back some good & fun memory. But when I settle down on the triumph in a few week's time, I would ask why I've to go through the hassle (and wasting time..lol)
 
Intel X25-E 64GB, 10 year old SSD in a external USB3 cabinett:
Code:
# /jffs/bin/iozone  -e -I -a -s 20M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Iozone: Performance Test of File I/O
                Version $Revision: 3.482 $
                Compiled for 32 bit mode.
                Build: linux-arm

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa,
                     Alexey Skidanov, Sudhir Kumar.

        Run began: Wed Sep  5 09:54:45 2018

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 20480 kB
        Record Size 4 kB
        Record Size 16 kB
        Record Size 512 kB
        Record Size 1024 kB
        Record Size 16384 kB
        Command line used: /jffs/bin/iozone -e -I -a -s 20M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
           20480       4     8974     9568    10257    10236     7577     9969
           20480      16    20293     5862    20853    21102    17803    21026
           20480     512    33000    32849    37326    37372    37198    33124
           20480    1024    32915    32822    37500    37407    37265    32914
           20480   16384    33700    34259    38506    38620    38551    34210

iozone test complete.
 
Last edited:
Sandisk Ultra Fit 128GB:
Code:
# /jffs/bin/iozone  -e -I -a -s 20M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Iozone: Performance Test of File I/O
                Version $Revision: 3.482 $
                Compiled for 32 bit mode.
                Build: linux-arm

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa,
                     Alexey Skidanov, Sudhir Kumar.

        Run began: Wed Sep  5 09:56:33 2018

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 20480 kB
        Record Size 4 kB
        Record Size 16 kB
        Record Size 512 kB
        Record Size 1024 kB
        Record Size 16384 kB
        Command line used: /jffs/bin/iozone -e -I -a -s 20M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
           20480       4     1416     1247     3897     3928     1689      987
           20480      16     3438     3421    11322    11289     6565     3082
           20480     512    23358    22189    34706    34896    33377    21792
           20480    1024    23556    22245    34429    25331    33708    23852
           20480   16384    18692    20245    35475    35863    35807    22513

iozone test complete.
 
Last edited:

It's not really surprising to me. I hope people have realised that there is die level parallelism, board level parallelism.. So as the saying goes..one chopstick is weak..10 chopsticks make a huge difference.

*drum* what's surprising is that your Ultra Fit result is much better than @XIII. I believe this gent has more work to do for his router in addition to having a new steak!

I'll add the Ultra Fit result to iozone-db.txt. Thanks for the submission.
 
*drum* what's surprising is that your Ultra Fit result is much better than @XIII. I believe this gent has more work to do for his router in addition to having a new steak!
He uses a 128 GB stick, while I used a 32 GB stick. Can that explain the difference?

(I don't know about USB sticks, but SSD's are usually faster if they are larger)

What else do you suggest I should change on my router?

(I had similar results on 3 identical sticks on 3 different routers (56u, 68u, 86u); though all routers have a similar setup)
 
He uses a 128 GB stick, while I used a 32 GB stick. Can that explain the difference?

(I don't know about USB sticks, but SSD's are usually faster if they are larger)

What else do you suggest I should change on my router?

(I had similar results on 3 identical sticks on 3 different routers (56u, 68u, 86u); though all routers have a similar setup)

I think you're spot on about the effect of size.
 
FWIW: My 128GB is a ext2 formated device (well to be precise I have the first partition in ext2, and the 2nd in tfat - however it is the first partition I used for this test, and it is also the partition I use for my swap file).

Also, and this is maybe important, I did test my +10 year old X25-E since it is:
a) very old SSD
b) a SLC based version that simlpy is faster than the SATA-2 interface mounted on it
c) I had it already, I only needed to mount it in a SATA3 (do observer the X25-E is a SATA2 device) to USB3 cabinet which was about 10usd so it is a rather old but still cheap solution (yes I could use a M2 to USB3 device and all that, way to expensive if you ask me).

Finding an old Intel X25-E (do observer the "E" here - there is a M version also, which is way slower!) seems maybe hard, there were only 32GB and 64GB versions back then... Anyway it is just that I had it, and I thought it could be good to know what 10-year old stuff still can do...
 
c) I had it already, I only needed to mount it in a SATA3 (do observer the X25-E is a SATA2 device) to USB3 cabinet which was about 10usd so it is a rather old but still cheap solution

Interesting details. Did you test it on a USB2 port on 88U? The result implies that's likely the case. Or else I would think the SATA3 to USB3 bridge somehow only works as USB2.
 
Interesting details. Did you test it on a USB2 port on 88U? The result implies that's likely the case. Or else I would think the SATA3 to USB3 bridge somehow only works as USB2.

No, it is actually connected to the USB3 port on my AC88 - and yes I have also noticed the "roof" on performance which makes me wonder of the quality of the cabinett.... I have an older SATA2 to USB2 cabinet somewhere - I might have a go in that one too just for comparison...?
 
No, it is actually connected to the USB3 port on my AC88 - and yes I have also noticed the "roof" on performance which makes me wonder of the quality of the cabinett.... I have an older SATA2 to USB2 cabinet somewhere - I might have a go in that one too just for comparison...?

I recall WebGUI has a feature "disable 2.4Ghz interference" or something like that turns USB3 port down to USB2..Would be interesting to see how it perform on a USB2 port. My SanDisk Extreme USB 3.0 stick performs better on 56U's USB2 port than my SBC's USB3 port for 4KiB random read/write. I couldn't figure out the reason.
 
I recall WebGUI has a feature "disable 2.4Ghz interference" or something like that turns USB3 port down to USB2..Would be interesting to see how it perform on a USB2 port. My SanDisk Extreme USB 3.0 stick performs better on 56U's USB2 port than my SBC's USB3 port for 4KiB random read/write. I couldn't figure out the reason.
It is now in the USB3.0 icon on network-map, only visible if something pluged in there and you can choose the port to act as USB2.0 or 3.0.
 
Okay, so I turned the "Reducing USB 3.0 interference" OFF (I had it on before) and now the numbers are alot better, more as expected.

Intel X25-E 64GB version (a SATA-2 device!), over SATA3-to-USB3 bridge, in a cabinet on the side:
Code:
        Command line used: /jffs/bin/iozone -e -I -a -s 20M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
           20480       4    41645    42163    37517    36631    15843    40504
           20480      16    93529   110040    98240    96698    52147   108054
           20480     512   176672    84625   185871   188078   189603   178566
           20480    1024   176313   176533   188794   188079   190050   178735
           20480   16384   177218   199314   207085   204075   206733   199481
 
That looks more like a SSD I would expect :D
 
I've also done it a couple of times on my recently purchased SBC. End result ..I got better benchmarks that I've never seen reported on the web.. The process does bring back some good & fun memory. But when I settle down on the triumph in a few week's time, I would ask why I've to go through the hassle (and wasting time..lol)

It's not one of these is it? Have to say though that working with the Rockchip SoC's has been more challenging that some of the others - documentation is part of the challenge. Once sorted, they're decent performers...

The armbian team has made the most progress on the rockchip series of SoC's -- lot of good insight shared in their forums.
 
Or any of the Samsung portable SSD's...
I have a bunch (5 to be exact) of them at my work - however none are mountable to my ASUS router since they are encrypted.... damn security :cool::cool:

Edit: I notice that the cost of a 256GB Samsung T5 is about half of the Sandisk I mentioned.
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top