A20 SATA write speed improvement

[Madozu]

I tested the recently added sunxi-dev patch to improve the SATA write speed. Here are the results:

 

Board: Cubietruck
OS: Ubuntu Bionic (18.04.2), Armbian 5.86
Kernel: 5.1.0 with and without RFC-drivers-ata-ahci_sunxi-Increased-SATA-AHCI-DMA-TX-RX-FIFOs.patch

SATA-device: SAMSUNG SSD 830 Series, 256GB

 

Measurement method: dd if=/dev/zero of=/tesfile bs=? count=? oflag=direct

bs: measured 4k, 64k and 1M block sizes
count: adjusted to ensure that data written is ~500MB

 

Measurements below are made with kernel 5.1.0 without (before) and with the mentioned patch:

dd bs  Before MB/s  After MB/s  Increase
4k            13.3        19.0       43%
64k           35.9        82.0      128%
1M            42.5       112.0      164%

As you can see, the SATA write speed improved, especially when using larger block sizes. Up to now, no negative side-effects encountered.

 

[Sigge]

Hi, could you indicate a step by step procedure for installing this kernel? I would love to try it!

[Werner]

7 hours ago, Sigge said:

Hi, could you indicate a step by step procedure for installing this kernel? I would love to try it!

Either grab the build script and build your own kernel package (https://github.com/armbian/build) or simply wait until the next version bump and do a standard apt upgrade to get the fresh packages.

[Sigge]

Ok, I will wait. Thanks!

[Igor]

 

Samsung SSD 840 Pro 256 GB @ Cubietruck

iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

Kernel 3.4.y
                                                               random   random
                  reclen    write  rewrite     read   reread     read    write
          102400       4    10714    15285    31921    32280    16328    14767
          102400      16    21757    25767    57812    58010    45695    25201
          102400     512    33403    32429   128245   116062   109591    33595
          102400    1024    34846    35240   129965   131121   129515    35227
          102400   16384    37895    37918   207564   204627   204340    38019

Kernel 4.19.y with SATA improvement patch

          102400       4    22876    32704    37686    39143    22571    30990
          102400      16    54254    69325    94749    97225    61354    68529
          102400     512   110670   113325   190346   163677   186012   112679
          102400    1024   113971   115928   206044   207406   184936   115069
          102400   16384   127084   127588   243400   253305   252148   127611

without

          102400       4    18053    22336    45249    46338    24860    22292
          102400      16    30692    32188   106052   106577    71526    32746
          102400     512    39632    39978   186433   185444   178097    39939
          102400    1024    39860    40163   189900   191076   188446    40098
          102400   16384    38875    41508   241939   244088   243405    41314

 

[Tido]

4 hours ago, Igor said:

Samsung SSD 840 Pro 256 GB @ Cubietruck iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

Thank you Igor, the report of Madozu was not promising, not enough numbers. Yours look nice, some day I my Lamobo R1 comes back to life 

 

[lzb]

This patch is included in -next already? I can test it with BananaPi M1.

 

::edit

commit messages seems to confirm it is in -next. Bleh, more like in -dev. I need more coffee...

 

::edit2

4.9.38 (next), only one test made.
fs: btrfs
                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     3951     5919    14107    14547     1337     4955
          102400      16     9908    14394    17473    32988     3338    10818
          102400     512    26440    27888    62459    73201    31875    30057
          102400    1024    26543    29481    61408    74973    36113    28225
          102400   16384    30315    34723    57029   109099   103228    38344

5.1.0-sunxi #5.86 SMP Mon May 13 21:11:09 CEST 2019 armv7l GNU/Linux (3 tests made)
fs: btrfs
                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     6056     7318    19250    19427     1376     4393
          102400      16    16210    16483    42932    45765     5118    16473
          102400     512    57882    44149    58178    69361    38018    61066
          102400    1024    49587    55798    51267    78644    45696    63254
          102400   16384    30345    66470    64869    82639    80843    58395

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     5115     5813    18911    17605     1259     5124
          102400      16    16791    20273    18971    38345     4750    13755
          102400     512    36974    56462    62740    80449    33872    62893
          102400    1024    44808    34004    51920    83809    43962    66327
          102400   16384    57777    47181    44560    78107    79185    53640

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     4989     6186    16698    16474     1138     3173
          102400      16    11646    10015    38828    42461     4455    15354
          102400     512    47299    49030    57053    82134    29582    61737
          102400    1024    45468    35288    58417    81450    32958    64807
          102400   16384    55345    65883    78657    99487   104514    56825

This was made on 1TB spinning rust:

Device Model:     ST1000LM035-1RK172
User Capacity:    1,000,204,886,016 bytes [1.00 TB]

[Igor]

58 minutes ago, lzb said:

Bleh, more like in -dev. 

... or nightly builds. It will soon be pushed to stable repository since there seems to be no reports on problems.

 

1 hour ago, lzb said:

I need more coffee...

Here

[MacBreaker]

OT

 

Igor,

 

where i can get/buy some Cups for coffee like these?

 

Markus

 

[Igor]

5 hours ago, MacBreaker said:

OT

 

Igor,

 

where i can get/buy some Cups for coffee like these?

 

Markus

 

This is/was a limited edition (6pcs, two already broken) gift by TJoe @Code4Sale LLC He made them for Ohio Linux fest:

[barish]

I just got an Olinuxino Lime2 and will soon get a cheap SATA SSD. What would be a good way of testing if the patch messes up read/write access or does any other harm to the system? I remember a message in another thread talking of edge cases of some sort - is there a way of artificially creating them or having a higher probability for those? I am willing to let the board run on tests for some weeks if necessary to find out.

[Tido]

1 hour ago, barish said:

if the patch messes up read/write access or does any other harm to the system?

I don't know if you were already here, but in Igor's tweet I found this link in the answers http://lkml.iu.edu/hypermail/linux/kernel/1905.1/03506.html

Did you already study this information, it maybe quicker than testing for weeks?

 

[barish]

Thanks @Tido for this link, I hadn't seen it and it gives quite a good explanation to why it took so long and why it's so difficult to have a decent SATA speed on Allwinner boards. :-)  So I think testing should include all different kinds of transfer block sizes, verifying the write result on the fly, just to be sure that one trial-and-error-finding is as good as the previous trial-and-error-finding, which has already been tested since 2014.

[barish]

To sum up my not too excessive tests of the new kernel on the Lime2 - I did not encounter any read/write errors up to now. Right from the start I switched to nightly builds and still had a reasonably stable system. What I found dissapointing were the speeds over network (SMB): I did never exceed 44MB/s in any condition (reading, writing, HDD, SSD, SD card, SATA, USB, always GBit-Ethernet).

If there's any procedure of testing read/write over SATA excessively - please let me know. Does a benchmark apply?

OT: So this board might be a good update to my first generation Raspberry Pi (which makes 6MB/s ;-) ) but compared to the EspressoBin V5, which I obtained a couple of days ago and which is stable (other than the V7 I had to send back), it is about half as fast. And I am running the EspressoBin at a conservative 800MHz.

[pi-rat]

My BPM1 runs Armbian and kernel "4.19.57-sunxi", the one that apt installed. But accessing the SSD is still very slow. I guess that means the patch has not yet arrived in repositories?

[Igor]

8 hours ago, pi-rat said:

I guess that means the patch has not yet arrived in repositories?

Patch is present since May, 11th https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/RFC-drivers-ata-ahci_sunxi-Increased-SATA-AHCI-DMA-TX-RX-FIFOs.patch

Without providing data from:

armbianmonitor -u
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

your report is pointless. "still very slow" means nothing.

[jimandroidpc]

Would this be working for the lemaker banana pi or pro? I can test next week.

Sent from my LM-G710 using Tapatalk

[Igor]

55 minutes ago, jimandroidpc said:

Would this be working for the lemaker banana pi or pro? I can test next week.

Sent from my LM-G710 using Tapatalk
 

It should, yes.

[Igor]

While cleaning my drawers I stumble upon Cubieboard 1 (A10)  http://ix.io/1Txt

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    16721    27087    31477    31590    18673    27409
          102400      16    39496    52677    74797    75147    47009    55523
          102400     512    84950    85975   101176   104662   129620    79095
          102400    1024    78612    93220   105843   133403   105685    80637
          102400   16384    98981    98275   188174   144679   188825    90922

 

[Watire]

Hello everyone,

I use a cheap generic chinese sourced sata multiplier that works with no issues with the patch The dd tests are conclusive also. But I do not see much improvement with common commands like cp, mv and rsync when transferring massive amount of files between disks.

Is there a kernel tuning parameter (about block sizes maybe) that could help transfer speed between hard drives ?

 

[jeymc]

Is that speed will be the same for Olinuxino A20 Lime2 board?

it is too slow for SSD disk which is  attached on SATA port.I expected much more, but I see in Youtube some guys showing speed transfer results on Raspberry Pi 4 and Rock Pi4 with attached SSDs on their USB 3.0 ports and the results are something like 260 Mb/s for read and 245Mb/s for write, which can be acceptable as good performance.

[pi-rat]

On 7/18/2019 at 10:20 PM, pi-rat said:

My BPM1 runs Armbian and kernel "4.19.57-sunxi", the one that apt installed. But accessing the SSD is still very slow. I guess that means the patch has not yet arrived in repositories?

 

Same here: half a year later, the usual updates raised kernel version up to 4.19.62-sunxi, but writing and reading on the SSD is still not faster than half a year ago.

 

On 7/19/2019 at 7:11 AM, Igor said:

Patch is present since May, 11th https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/RFC-drivers-ata-ahci_sunxi-Increased-SATA-AHCI-DMA-TX-RX-FIFOs.patch

 

 

That is a dead link. Besides: after Igor's statement "Standard upgrade will get you there." I would have expected that this patch would be activated in standard kernel by now.

 

How do I get this patch into my Banana's kernel?

[Igor]

12 minutes ago, pi-rat said:

this patch would be activated in standard kernel by now.

 

It is, for months and it was also tested. There is nothing more to be done. It could fell out by some mistake, but unlikely. If you want that we tests all features at each upgrade, you will need to cover that ...

armbianmonitor -u

is how you need to start our conversation when you have a problem. I have no idea what kind of system you have.

[pi-rat]

I'm running a BPM1: http://ix.io/24O6

 

 

[Igor]

Your kernel is not the latest so it is possible that support is missing. Do this:

Upgrade to legacy or current and run this to make sure:

iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

 

[pi-rat]

Done:

 

root@pi:~/tmp# uname -a
Linux pi 4.19.84-sunxi #19.11.3 SMP Mon Nov 18 18:39:42 CET 2019 armv7l GNU/Linux

root@pi:~/tmp# iozone -e -I -a -s 100M -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.429 $
                Compiled for 32 bit mode.
                Build: linux

        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.

        Run began: Wed Dec 18 22:09:31 2019

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 102400 kB
        Record Size 4 kB
        Record Size 16 kB
        Record Size 512 kB
        Record Size 1024 kB
        Record Size 16384 kB
        Command line used: iozone -e -I -a -s 100M -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
          102400       4    16724    28876    38947    40546    16189    28782                                                          
          102400      16    41431    53605    89153    89090    43316    54839                                                          
          102400     512    96615    96805   161257   161252   150858   100117                                                          
          102400    1024   101276   104887   175556   175069   149251   105019                                                          
          102400   16384   123541   121274   244701   253998   227554   124656                                                          

iozone test complete.

I am not sure what these numbers mean, but according to "hdparm -tT" accessing the disk is no faster then before. Should I try kernel 5 instead?

 

[Igor]

9 minutes ago, pi-rat said:

but according to "hdparm -tT" accessing the disk is no faster then before

 

Perhaps this means your test method is a fail?

 

9 minutes ago, pi-rat said:

I am not sure what these numbers mean,

It means everything is alright  "Output is in kBytes/sec"

man iozone # for more

 

 

This tool is Linux / CLI version of the most used one https://crystalmark.info/en/software/crystaldiskmark/

[pi-rat]

Thank you!

 

Could you explain what is the difference between this way of updating the kernel and the usual "apt uprade"? Do I always need to use "armbian-config" instead?

[Igor]

9 hours ago, pi-rat said:

Could you explain

I explained in that post.

[pi-rat]

Please don't get mad at me, but that's what I don't understand: before the switch the system was running on kernel

4.19.62-sunxi

 

After the switch it is now running on kernel

4.19.84-sunxi

 

To me, this is the same kernel branch: 4.19.x.

 

If it was kernel 4.20.x now, or even kernel 5.x, I would totally understand it, but the way it looks to me, it doesn't make sense to me, that armbian-config switches the kernel to a different branch with the same kernel version,while apt-upgrade doesn't.

[Igor]

40 minutes ago, pi-rat said:

while apt-upgrade doesn't.

Old kernel naming doesn't receive updates anymore. You have to do this manual procedure / switch to new naming ... then update goes the usual way. It could be done automatically, but even without it was already insane lots of work most people don't even notice or support. Manual updating is a small price you need to pay.