Date: Sun, 7 Jan 2018 03:42:31 -0800 From: Mark Millard <markmi@dsl-only.net> To: blubee blubeeme <gurenchan@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: USB stack Message-ID: <F9A5DBFF-79C8-417D-9B6D-0788976B558C@dsl-only.net> In-Reply-To: <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> <CALM2mEnaA7zDVfONFQEBtC2WghbRFoFW2iPpmBKohP1pd45CcQ@mail.gmail.com> <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[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.]
>=20
> On 2018-Jan-7, at 2:09 AM, blubee blubeeme <gurenchan at gmail.com> =
wrote:
>=20
> . . .
>> This is a larger file, not the largest but hey
>>=20
>> 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
> . . .
>=20
> Note that almost complete lack of kBps near r/s but the large
> kBps near w/s.
>=20
> 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.
>=20
> 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).
>=20
> 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?
=46rom 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.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F9A5DBFF-79C8-417D-9B6D-0788976B558C>