Date: Sun, 7 Jan 2018 04:13:33 -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: <FA0FA34D-B941-43DB-8885-902B502A5442@dsl-only.net> In-Reply-To: <F9A5DBFF-79C8-417D-9B6D-0788976B558C@dsl-only.net> References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> <CALM2mEnaA7zDVfONFQEBtC2WghbRFoFW2iPpmBKohP1pd45CcQ@mail.gmail.com> <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> <F9A5DBFF-79C8-417D-9B6D-0788976B558C@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[I add an example of a none-USB to USB2 copy and
a USB2 to non-USB copy. They do not show any
< 8 MiByte/s bottlenecks.]
On 2018-Jan-7, at 3:42 AM, Mark Millard <markmi@dsl-only.net> wrote:
> [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?]
>=20
> On 2018-Jan-7, at 2:44 AM, Mark Millard <markmi at dsl-only.net> =
wrote:
>=20
>> [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.
>=20
> 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?
>=20
> =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.
>=20
> 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.
>=20
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>=20
> In your other table:
>=20
> 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
> =
--------------------------------------------------------------------------=
----------------------------------------
>=20
> This shows lots of deletes per second for some reason.
>=20
> Did you move instead of copy? After each file was copied,
> was it then deleted?
>=20
> It is possible that the deletes slowed this down,
> whatever they were from.
Here are "gstat -pd" samples from during a:
cp -ax /usr/src /media/root/srccpy_test
(which is to USB2 from non-USB.)
dT: 1.071s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps =
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| fd0
0 2346 2346 20234 0.1 0 0 0.0 0 0 =
0.0 11.9| da0
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da3
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| cd0
1162 1375 21 658 60.1 1354 26962 331.4 0 0 =
0.0 81.1| da4
dT: 1.069s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps =
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| fd0
0 859 859 7657 0.1 0 0 0.0 0 0 =
0.0 4.8| da0
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da3
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| cd0
841 1544 7 240 5.3 1536 31956 261.7 0 0 =
0.0 93.0| da4
dT: 1.070s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps =
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| fd0
0 1709 1709 15074 0.1 0 0 0.0 0 0 =
0.0 9.3| da0
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da3
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| cd0
1257 1423 15 479 43.9 1408 31011 277.5 0 0 =
0.0 91.9| da4
dT: 1.070s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps =
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| fd0
0 4350 4350 44982 0.1 0 0 0.0 0 0 =
0.0 22.0| da0
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da3
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| cd0
943 1028 27 867 5.0 1001 19315 614.8 0 0 =
0.0 59.8| da4
Here are "gstat -pd" samples from during a:
cp -ax /media/usr/src /root/srccpy_test
(which is to non-USB from USB2.)
dT: 1.069s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps =
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| fd0
0 306 0 0 0.0 306 38383 0.3 0 0 =
0.0 2.6| da0
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da3
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| cd0
1 548 548 37533 52.7 0 0 0.0 0 0 =
0.0 100.2| da4
dT: 1.070s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps =
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| fd0
0 934 7 209 0.1 927 12438 2.2 0 0 =
0.0 1.5| da0
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da3
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| cd0
1 1296 1296 20674 0.7 0 0 0.0 0 0 =
0.0 90.1| da4
dT: 1.070s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps =
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| fd0
0 1208 5 150 0.1 1203 32069 2.3 0 0 =
0.0 2.2| da0
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| da3
0 0 0 0 0.0 0 0 0.0 0 0 =
0.0 0.0| cd0
1 931 931 27073 6.9 0 0 0.0 0 0 =
0.0 93.6| da4
No bottlenecks causing < 8 MiBytes/s: much faster then that.
USB2 is not such a bottleneck in my context.
But, again, all UFS and the USB SSD stick is the slower
device but is, in turn, limited by USB2 in these.
=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?FA0FA34D-B941-43DB-8885-902B502A5442>