I have just rebooted with WAPBL enabled. Some quick notes: -Sequential write speed is a little lower, around 5,4 MB/s.
-Creating 1000 files takes 0,25 sec. while almost no xfers happen. (It just goes to the log I guess). -When creating more files (say 10.000), a known issue comes to light. One CPU core gets utilized 100% in kernel mode while there are almost no xfers. It takes ages until the operation completes. In contrast, a non-WAPBL mounted FS experiences many xfers until the drive limit gets hit (>100 xfers/sec.). I am pretty certain that there is a regression in WAPBL. Can you tell me how I can extract a kernel for the Pi using objdump, so I can conduct some experimentation? 2015-08-04 15:48 GMT+00:00 Jared McNeill <jmcne...@invisible.ca>: > Class 10 is a high-speed rating, not UHS-I. Make sure you are using a > UHS-I card. dmesg will tell you, i.e.: > > ld0: 4-bit width, SDR50, 100.000 MHz > > > > On Tue, 4 Aug 2015, Stephan wrote: > > These are my numbers on a class 10 Sony-SD-card when extracting pkgsrc.tar. >> >> tty ld0 CPU >> tin tout KB/t t/s MB/s us ni sy in id >> 1 130 27.20 83 2.206 1 0 4 1 93 >> 0 132 7.333 186 1.329 0 0 0 0 100 >> 0 45 7.839 258 1.978 0 0 1 0 98 >> 0 44 7.134 192 1.338 0 0 1 1 97 >> 0 44 7.806 215 1.638 0 0 0 0 99 >> 0 44 7.483 238 1.737 0 0 1 1 98 >> 0 44 7.250 158 1.122 0 0 1 0 99 >> 0 44 7.744 255 1.932 0 0 2 1 97 >> 0 44 6.830 169 1.129 1 0 4 0 95 >> 0 44 7.379 201 1.448 0 0 1 0 99 >> 0 44 7.702 226 1.698 0 0 1 1 98 >> 0 44 7.391 218 1.572 0 0 0 0 100 >> 0 45 7.161 215 1.503 0 0 1 1 98 >> 0 44 7.164 223 1.559 0 0 1 0 99 >> 0 44 7.701 192 1.445 0 0 1 0 99 >> 0 44 7.600 262 1.947 0 0 1 1 97 >> tty ld0 CPU >> tin tout KB/t t/s MB/s us ni sy in id >> 0 44 9.719 183 1.738 0 0 1 0 99 >> 0 131 8.244 178 1.435 0 0 0 1 99 >> 0 44 7.861 242 1.855 0 0 0 0 100 >> 0 45 7.539 215 1.582 0 0 0 1 99 >> 0 44 7.020 196 1.344 0 0 1 0 99 >> 0 44 7.266 216 1.532 0 0 3 0 97 >> 0 44 7.798 186 1.417 0 0 1 1 98 >> 0 44 7.184 221 1.549 0 0 1 0 99 >> 0 44 7.703 234 1.758 0 0 1 0 99 >> 0 44 7.268 211 1.497 0 0 1 1 98 >> 0 44 8.064 185 1.458 0 0 2 0 97 >> 0 44 7.485 257 1.882 0 0 1 1 98 >> 0 44 7.235 215 1.518 0 0 1 0 98 >> 0 44 7.071 194 1.340 0 0 0 0 100 >> 0 45 7.667 220 1.646 0 0 1 1 98 >> 0 44 6.915 232 1.564 0 0 1 0 99 >> tty ld0 CPU >> tin tout KB/t t/s MB/s us ni sy in id >> 0 44 7.703 180 1.356 0 0 0 1 99 >> 0 131 6.975 240 1.632 0 0 2 0 98 >> >> Sequential write is about 6 MB/s on average. >> >> >> 2015-08-04 16:45 GMT+02:00 Jared McNeill <jmcne...@invisible.ca>: >> The autobuild server should have the changes: >> >> >> http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201508041020Z/evbarm-earmv6hf/binary/kernel/ >> >> objcopy is used to generate "netbsd.bin" from the ELF binary. Grab >> netbsd-RPI.bin.gz from that >> link, gunzip it, and rename to kernel.img >> >> >> On Tue, 4 Aug 2015, Stephan wrote: >> >> Hi Jared, >> >> I could. Can you provide a current kernel so I don?t need to >> set up a build >> environment beforehand? >> >> I was also wondering what kind of file "kernel.img" (on the >> boot partition) is and >> how to build this. >> According to file, a regular NetBSD kernel is an ELF binary, >> whereas "kernel.img" is >> just "data"?! >> >> Regards, >> >> Stephan >> >> >> 2015-08-04 14:59 GMT+02:00 Jared McNeill < >> jmcne...@invisible.ca>: >> Hi -- >> >> I've added UHS-I support in -current and enabled it for >> Raspberry Pi. Can you >> update and see if >> this makes a difference in SD card performance? >> >> Thanks, >> Jared >> >> On Thu, 9 Jul 2015, Stephan wrote: >> >> Well, you can finde a previous discussion here: >> >> >> http://mail-index.netbsd.org/tech-kern/2014/08/22/msg017539.html >> >> The point was that creating many (even empty) files >> leads to a very high >> kernel CPU >> consumtion along with >> almost no disk activity. What happens behind the scenes >> is still unknown to >> me. One should >> check whether >> WAPBL makes a difference here (mount option "log" >> enables WAPBL journaling). >> It might be >> helpful to have >> DTrace working in order to investigate this. >> >> Cheers! >> >> 2015-07-09 12:33 GMT+02:00 Jean-Baka Domelevo >> Entfellner <domel...@gmail.com>: >> Hallo Stephan, >> >> Thanks for the advice: yes, you were damn right! >> With the dd command >> you gave as example, on top of the untarring, we >> get very different >> values: >> tty ld0 CPU >> tin tout KB/t t/s MB/s us ni sy in id >> 0 19 7.825 17 0.128 0 0 1 3 95 >> 0 131 64.00 70 4.394 0 0 34 2 64 >> 0 44 64.00 85 5.322 0 0 31 11 58 >> 0 44 64.00 73 4.579 0 0 33 8 59 >> 0 44 64.00 72 4.517 3 0 30 6 61 >> 0 44 63.19 58 3.605 0 0 3 6 91 >> 0 44 14.77 64 0.928 0 0 21 1 78 >> 0 44 64.00 60 3.775 0 0 36 8 56 >> 0 44 64.00 69 4.332 1 0 36 2 61 >> 0 44 64.00 56 3.527 0 0 25 3 72 >> 0 44 64.00 55 3.465 1 0 24 3 72 >> 0 44 64.00 56 3.527 1 0 25 2 72 >> 0 44 64.00 57 3.589 1 0 20 6 73 >> 0 44 64.00 68 4.270 0 0 29 6 65 >> 0 44 64.00 73 4.579 3 0 29 6 62 >> 0 44 63.30 68 4.223 0 0 4 7 89 >> 0 44 40.49 88 3.485 1 0 44 4 51 >> ^C >> rpi$ fg >> dd if=/dev/zero of=myfile bs=4k >> ^C20720+0 records in >> 20719+0 records out >> 84865024 bytes transferred in 20.350 secs >> (4170271 bytes/sec) >> >> >> So this means approximately 4MB/s, and that's >> indeed the nominal speed >> of my microSD if it's indeed a class 4 card. Will >> check that once I >> can switch the RPi off. Thanks! >> >> So ffs is slow with creating files... Why is it >> still the standard in >> NetBSD? Is the format of my partition (displayed >> with fstype=4.2BSD in >> "disklabel /dev/ld0") also called "UFS1"? Would >> the format called >> "UFS2" be faster regarding file creation? >> >> And just another off-topic question sparked by >> this one: is there >> really an added value in specifying "bs=4k"? >> According to the manpage, >> the default is one sector, 512 bytes. When I use >> it (dd if=/dev/zero >> of=myfile), I get 3048728 bytes/sec instead of >> 4170271 bytes/sec with >> "bs=4k". Is that discrepancy explainable and >> reproducible? Thanks for >> sharing your light! :) >> >> JB >> >> On Thu, Jul 9, 2015 at 11:39 AM, Stephan < >> stephan...@googlemail.com> >> wrote: >> > Can you please check the speed of sequential >> write (e.g. dd >> if=/dev/zero >> > of=myfile bs=4k)? FFS has always been slow with >> allocating new files, >> which >> > certainly contributes to the issue you?re seeing. >> > >> > 2015-07-09 11:28 GMT+02:00 Jean-Baka Domelevo >> Entfellner >> > <domel...@gmail.com>: >> >> >> >> Hi there, >> >> >> >> I'm currently untarring a pkgsrc.tar.gz (48MB) to >> /usr. The >> >> commandline I used is: >> >> # nohup tar xfz pkgsrc.tar.gz -C /usr & >> >> >> >> so nothing is written to the stdout, it justs >> gunzips and untars. And >> >> I have the feeling it's extremely slow. I'm running: >> >> NetBSD rpi 7.0_RC1 NetBSD 7.0_RC1 >> (RPI.201507072130Z) evbarm >> >> and it's on a RaspberryPi model B+ >> >> >> >> The microSD card is an ADATA (32GB), I don't think >> it's class 10, >> >> maybe class 4 (can't remove it from its slot now >> while the RPi is >> >> running). The boot messages concerning it are: >> >> ld0 at sdmmc0: >> <0x03:0x5344:SS32G:0x80:0x2554f92d:0x0e4> >> >> ld0: 30436 MB, 7729 cyl, 128 head, 63 sec, 512 >> bytes/sect x 62333952 >> >> sectors >> >> ld0: 4-bit width, bus clock 50.000 MHz >> >> >> >> So, while the untarring command is running, I check >> the speed with iostat: >> >> >> >> tty ld0 CPU >> >> tin tout KB/t t/s MB/s us ni sy in id >> >> 0 20 7.767 15 0.113 0 0 1 3 95 >> >> 0 131 8.194 31 0.246 0 0 3 3 94 >> >> 0 44 7.871 31 0.236 0 0 1 3 96 >> >> 0 44 7.793 29 0.219 1 0 1 2 96 >> >> 0 44 8.133 30 0.236 0 0 2 2 96 >> >> 0 44 7.871 31 0.236 0 0 1 1 98 >> >> 0 44 7.793 29 0.219 0 0 1 4 95 >> >> 0 44 7.939 33 0.253 0 0 2 1 97 >> >> 0 44 7.931 29 0.222 0 0 0 2 98 >> >> 0 44 7.571 28 0.205 0 0 6 4 90 >> >> 0 44 7.793 29 0.219 0 0 3 2 95 >> >> 0 44 8.294 34 0.273 0 0 3 5 92 >> >> 0 44 8.000 28 0.217 0 0 3 0 97 >> >> 0 44 8.067 30 0.234 0 0 0 3 97 >> >> >> >> It's on average between 0.20 and 0.25 MB/s, don't >> you think it's >> >> unreasonably slow? Do you have any piece of advice >> for me? >> >> >> >> Thanks, >> >> JB >> > >> > >> >> >> >> >> >> >> >>
