Madozu Posted May 11, 2019 Posted May 11, 2019 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. 1
Sigge Posted May 11, 2019 Posted May 11, 2019 Hi, could you indicate a step by step procedure for installing this kernel? I would love to try it!
Werner Posted May 12, 2019 Posted May 12, 2019 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.
Igor Posted May 12, 2019 Posted May 12, 2019 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 2
Tido Posted May 12, 2019 Posted May 12, 2019 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 Posted May 24, 2019 Posted May 24, 2019 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 Posted May 24, 2019 Posted May 24, 2019 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 Posted May 24, 2019 Posted May 24, 2019 OT Igor, where i can get/buy some Cups for coffee like these? Markus
Igor Posted May 24, 2019 Posted May 24, 2019 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: 1
barish Posted June 3, 2019 Posted June 3, 2019 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 Posted June 3, 2019 Posted June 3, 2019 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 Posted June 3, 2019 Posted June 3, 2019 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. 1
barish Posted June 28, 2019 Posted June 28, 2019 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. 1
pi-rat Posted July 18, 2019 Posted July 18, 2019 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 Posted July 19, 2019 Posted July 19, 2019 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 Posted August 16, 2019 Posted August 16, 2019 Would this be working for the lemaker banana pi or pro? I can test next week.Sent from my LM-G710 using Tapatalk
Igor Posted August 16, 2019 Posted August 16, 2019 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 Posted August 26, 2019 Posted August 26, 2019 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 Posted October 5, 2019 Posted October 5, 2019 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 Posted October 23, 2019 Posted October 23, 2019 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 Posted December 18, 2019 Posted December 18, 2019 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 Posted December 18, 2019 Posted December 18, 2019 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.
Igor Posted December 18, 2019 Posted December 18, 2019 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 Posted December 18, 2019 Posted December 18, 2019 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 Posted December 18, 2019 Posted December 18, 2019 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 Posted December 18, 2019 Posted December 18, 2019 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 Posted December 19, 2019 Posted December 19, 2019 9 hours ago, pi-rat said: Could you explain I explained in that post.
pi-rat Posted December 19, 2019 Posted December 19, 2019 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.
Recommended Posts