Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Jan 2018 23:50:16 +0800
From:      blubee blubeeme <gurenchan@gmail.com>
To:        Mark Millard <markmi@dsl-only.net>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: USB stack
Message-ID:  <CALM2mEnnc4bzpFoRA_F_FayiBuGLwbwzyf-Gb-U6vmQ0RuGuYQ@mail.gmail.com>
In-Reply-To: <FA0FA34D-B941-43DB-8885-902B502A5442@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> <FA0FA34D-B941-43DB-8885-902B502A5442@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 7, 2018 at 8:13 PM, Mark Millard <markmi@dsl-only.net> wrote:

> [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?]
> >
> > 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.
>
>
> 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.
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
>
>
>
> I ran this test and here's some results.
gstat -pd images:

18GB file from laptop to phone: https://imgur.com/a/7iHwv
18GB file from laptop to ssd: https://imgur.com/a/40Q6V
multiple small files from laptop to phone: https://imgur.com/a/B4v4y
multiple small files from laptop to ssd: https://imgur.com/a/mDiMu

The files are missing timestamps but the originals were taken with scrot
and have timestamps available here:
https://nofile.io/f/mzKnkpM9CyC/stats.tar.gz2

as far as why there's such high deletions? I can't say I'm only using cp.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALM2mEnnc4bzpFoRA_F_FayiBuGLwbwzyf-Gb-U6vmQ0RuGuYQ>