Re: USB stack

[The other numbers show lots of delete activity on nvd0,
not just primarily reads. Also: Can you test a different
USB device, such as a USB SSD stick?]

On 2018-Jan-7, at 2:44 AM, Mark Millard <markmi at dsl-only.net> wrote:

> [The following notes a problem with how a test was done.
> I omit the rest of the material.]
> 
> On 2018-Jan-7, at 2:09 AM, blubee blubeeme <gurenchan at gmail.com> wrote:
> 
> . . .
>> This is a larger file, not the largest but hey
>> 
>> L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w    d/s   kBps   ms/d   %busy Name
>>    0      4      0      0    0.0      2      8    0.0      0      0    0.0    0.1| nvd0
>>    0      0      0      0    0.0      0      0    0.0      0      0    0.0    0.0| md99
>>  128    982      1     32   58.8    981 125428  110.5      0      0    0.0  100.0| da1
> . . .
> 
> Note that almost complete lack of kBps near r/s but the large
> kBps near w/s.
> 
> It appears that the file has been cached in RAM and is not
> being read from media at all. So this test is of a RAM to
> disk transfer, not disk to disk, as far as I can tell.
> 
> You need to avoid re-reading the same file unless you
> dismount and remount between tests or some such. Or
> just use a different file not copied since booting (that
> file may or may not be a previous copy of the same file
> by content).
> 
> See if you can get gstat -pd results that show both
> read kBps and write kBps figures.

Can you test another USB device, such as a USB SSD
stick, sometime known to be reliably fast and not
involving reading from the LG v30?

From what I read Android has many file systems supported
or used at one time: ext4, f2fs, yaffs, yaffs2,
vfat, msdos being in the list. Normal SD and SDHC files
systems are FAT32 and SDXC is exFAT.

So "Android 7.1" does not answer my question about which
file system is actually on the usdcard being used. I'd
guess FAT32 or exFAT, depending on SD/SDHC vs. SDXC, but
I do not really know.


My results show that getting above 8 MiBytes/s over
USB 2.0 is supported for other than the rather low end
of the FreeBSD range of systems. Beyond that is something
more specific to your context and not involved in mine.
The file system might be involved.

So far, from the tables and what you have written, the
LG v30 is required to be involved for the slowdown
to sub 8 MiBytes/s. This is part of why I ask about
testing an alternative USB device that is fast: it
tests USB without involving the LG v30 or the usdcard.

If USB ends up faster, then it is not USB's "stack" that
is the primary source of the current bottleneck for your
context: something else is also involved, such as the
file system may be.

Can you show gstat -pd output for copying from the
LG v30? Copying to the 1TB USB backup device? The
%busy figures might be interesting.


In your other table:

This is an example copying [multiple small files] to the 1TB drive.
------------------------------------------------------------------------------------------------------------------
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w    d/s   kBps   ms/d   %busy Name
    0    547    290  35239    2.0      4     16   73.1    249  44291   93.7   48.8| nvd0
    0      0      0      0    0.0      0      0    0.0      0      0    0.0    0.0| md99
   21    333      0      0    0.0    333  36040   16.2      0      0    0.0   76.2| da1
------------------------------------------------------------------------------------------------------------------

This shows lots of deletes per second for some reason.

Did you move instead of copy? After each file was copied,
was it then deleted?

It is possible that the deletes slowed this down,
whatever they were from.



===
Mark Millard
markmi at dsl-only.net