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+



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