Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Very slow transfers to/from micro SD card on a RPi B+



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 <jmcneill%invisible.ca@localhost>:
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 <jmcneill%invisible.ca@localhost>:
      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 <domelevo%gmail.com@localhost>:
            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 <stephanwib%googlemail.com@localhost> 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
      > <domelevo%gmail.com@localhost>:
      >>
      >> 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
      >
      >








Home | Main Index | Thread Index | Old Index