Re: USB stack

From: blubee blubeeme <gurenchan_at_gmail.com>
Date: Sat, 13 Jan 2018 01:41:11 +0800
On Tue, Jan 9, 2018 at 10:09 AM, Mark Millard <markmi_at_dsl-only.net> wrote:

>
> On 2018-Jan-8, at 1:15 AM, blubee blubeeme <gurenchan at gmail.com> wrote:
>
> > On Mon, Jan 8, 2018 at 3:20 PM, Mark Millard <markmi at dsl-only.net>
> wrote:
> >> [The involvement of sysutils/fusefs-simple-mtpfs
> >> and sysutils/fusefs-libs and multimedia/libmtp
> >> in order to use the Media Transfer Protocol (MTP)
> >> against the LG v30 likely explains much of the
> >> performance difference vs. local UFS file
> >> systems. I provide some related notes.]
> >>
> >> blubee blubeeme gurenchan at gmail.com wrote on
> >> Mon Jan 8 05:17:24 UTC 2018 :
> >>
> >> [Note: the original was in a reply to a Jon Brawn
> >> post. I've merged it back with my post.]
> >>
> >> > On 2018-Jan-7, at 11:46 AM, Mark Millard <markmi at dsl-only.net>
> wrote:
> >> >
> >> >> On 2018-Jan-7, at 10:23 AM, blubee blubeeme <gurenchan at gmail.com>
> wrote:
> >> >>
> >> >>
> >> >>
> >> >>> On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard <markmi at
> dsl-only.net> wrote:
> >> >>>
> >> >>>> On 2018-Jan-7, at 7:50 AM, blubee blubeeme <gurenchan at gmail.com>
> wrote:
> >> >>>>
> >> >>>>> 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.
> >> >>>>
> >> >>>> I assume that md99 is for a file-based swap-space, such as
> >> >>>> via /var/swap0 file. (As a side note I warn about bugzilla
> >> >>>> 206048 for such contexts.) Otherwise please describe how
> >> >>>> md99 is created. (Below I assume the swap-space usage of
> >> >>>> md99.)
> >> >>>>
> >> >>>> The only other device that your pictures show is your
> >> >>>> NVMe device nvd0.
> >> >>>>
> >> >>>> No picture shows a device for the LG v30 when it is mentioned
> >> >>>> above as being copied to or from. How is it that there is no
> >> >>>> mounted device shown for the LG v30?
> >> >>>>
> >> >>>> No picture shows a device for the SSD when it is mentioned
> >> >>>> above as being copied to or from. How is it that there
> >> >>>> is no mounted device shown for the SSD?
> >> >>>>
> >> >>>> Without a device displayed for the LG-v30/SSD there is nothing
> >> >>>> displayed for its reads or writes. This makes the gstat -pd
> >> >>>> useless.
> >> >>>>
> >> >>>> May be the p needs to be omitted for some reason? gstat -d
> >> >>>>
> >> >>>> ===
> >> >>>> Mark Millard
> >> >>>> markmi at dsl-only.net
> >> >>>
> >> >>> You are correct that md99 is a file backed swap disk, I am aware of
> the issues but I had to test some things out.
> >> >>>
> >> >>> Those tests earlier was a huge time sink.
> >> >>> Here's the dmesg output from earlier:
> >> >>> . . .
> >> >>> ----------------------------------
> >> >>>
> >> >>> I don't know why gstat isn't showing the info u are looking for.
> >> >>>
> >> >>> You said earlier that something was getting deleted,
> >> >>> I don't know what could be causing that.
> >> >>
> >> >> Those "deletes" are more commonly called TRIM on SSD's.
> >> >> FreeBSD called them, BIO_DELETE as I remember.
> >> >>
> >> >> Those deletes have nothing to do with umounting, deleteing
> >> >> devices, etc.
> >> >>
> >> >>> I've provided tons of debug out, logs, pciconf, dmesg, etc...
> >> >>> Even say forget the mobile device and go from
> >> >>> zpool
> >> >>
> >> >> From which I've not been able to figure out the kind of
> >> >> information that I'm looking for.
> >> >>
> >> >> Just because a device is present, does not mean that it
> >> >> is available as a file system. I'm more interested in
> >> >> how the file systems are made available --or if some
> >> >> non-file system way of working is involved.
> >> >>
> >> >>> Are you saying that there's something misconfigured on my end?
> >> >>> What other info do you need me to provide to try to figure out
> >> >>> what's going on or why I'm getting these transfer rates?
> >> >>
> >> >> I'm saying I still can not tell how you make the SSD or the
> >> >> LGv 30 available to FreeBSD (mount?). Or why no matching
> >> >> mounted device shows up in gstat's display.
> >> >>
> >> >> If you wish to keep trying to help me help you, . . .
> >> >>
> >> >> Please show how you make the file system on the
> >> >> SSD available to FreeBSD: what FreeBSD commands make
> >> >> the device available for use. (I'd guess that mount
> >> >> is used or that something like /etc/fstab is used
> >> >> to do mounts more implicitly.)
> >> >>
> >> >> Please show how you make the LG v30 available to FreeBSD:
> >> >> what FreeBSD commands make the device available for
> >> >> use. (I'd guess that mount is used or that something like
> >> >> /etc/fstab is used to do mounts more implicitly.)
> >> >>
> >> >> (I would expect these are mount commands, or at least
> >> >> involve mount commands/calls. Some of the following makes
> >> >> that presumption.)
> >> >>
> >> >> For each of those: with the device available show the
> >> >> output of:
> >> >>
> >> >> mount
> >> >>
> >> >> and of:
> >> >>
> >> >> df -m
> >> >>
> >> >> Similarly, show the exact commands used to make the
> >> >> copies to and from the SSD. Show the exact commands
> >> >> used to make the copies to and from the LG v30.
> >> >>
> >> >> (You can for now stop the commands early or just
> >> >> not start any that would take a long time.)
> >> >>
> >> >> I'm looking for a way to get information similar to
> >> >> what I expected gstat to show. I'd expect a mounted
> >> >> file system but may be something else is involved?
> >> >
> >> [Extracted from a reply to a Jon Brawn post.]
> >> > _at_Mark Millard
> >> > I use sysutils/simple-mtpfs to mount the android device.
> >> > when I mount the phone through USB this is the relevant section:
> >> > /dev/fuse                                   356311 78912 277398    22%
> >> > /mnt
> >> >
> >> > That's the most complicated mount process that I use,
> >> > for the ssd it's just a simple mount /dev/device /mnt
> >> > relevant output:
> >> > /dev/da0                                    923913 121450 728550
> 14%
> >> > /mnt
> >> >
> >> > Can you tell me what information you're looking for so that I can
> gather it
> >> > all up and send it.
> >>
> >>
> >> I do not find a /usr/ports/sysutils/simple-mtpfs . But I
> >> do find:
> >>
> >> # ls -lTd /usr/ports/sysutils/*simple*
> >> drwxr-xr-x  3 root  wheel  512 Sep 23 19:51:59 2017
> /usr/ports/sysutils/fusefs-simple-mtpfs
> >>
> >> And that was very important to know.
> >>
> >> . . .
> >
> >
> > OK, forget the android specific usb issues for now;
> > there is quite a few layers of crud between the laptop and the android
> device.
> >
> > I have this SSD.
> >
> > What are some tests that you'd like to run to test the speeds
> > on my end?
>
> Returning to just the SSD context. . .
>
> Because your pictures were missing the SSD for some
> reason, we first need to figure out if and how to
> see the SSD activity levels, such as via gstat.
>
> For now I focus on just that.
>
> You provided as information about the SSD:
>
> /dev/da0                                    923913 121450 728550    14%
> /mnt
>
> which is from "df -m". But I'd also asked for "mount"
> output. As an example for one of my contexts:
>
> # mount
> /dev/gpt/FBSDFSSDroot on / (ufs, NFS exported, local, noatime,
> soft-updates)
> devfs on /dev (devfs, local, multilabel)
>
> Note the types of information displayed, which is very different from
> what df -m reports.
>
> ( /dev/gpt/FBSDFSSDroot is a label reference instead of a physical
> device and partition/slice number notation.)
>
> After mounting the partition/slice from the SSD, can you show the
> mount command's description of the partition/slice that you mounted?
>
> (Actually, your "df -m" output does not show a partition/slice
> notation. I'm not sure what to make of that.)
>
> There is another view of things that can be handy. . .
> (output is from one of my example contexts)
>
> # gpart show -p da0
> =>       40  937703008    da0  GPT  (447G)
>          40       1024  da0p1  freebsd-boot  (512K)
>        1064  746586112  da0p2  freebsd-ufs  (356G)
>   746587176   31457280  da0p3  freebsd-swap  (15G)
>   778044456  159383552  da0p4  freebsd-swap  (76G)
>   937428008     275040         - free -  (134M)
>
> Note: Normally da0 would not show up in a mount
> line, instead it would be /dev/da0p2 for the UFS
> partition being mounted in my example.
>
> Your da0 might not show GPT or any other partition
> or slice structure (given the "df -m" output that
> you listed).
>
> (If zfs is involved, there may be better commands
> for some types of information above, but I've minimal
> ZFS background knowledge. You may have to explain
> your configuration if ZFS is in use on the SSD.)
>
> With that much information (if non-ZFS), I know what
> I expect to be listed in gstat -pd and in gstat -d .
>
> It is possible to use just:
>
> gstat -d
>
> and the same device and its partitions will show up
> multiple times for different ways they can be
> accessed. For example:
>
> dT: 1.073s  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      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.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| cd0
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| da0p1
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| da0p2
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| da0p3
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| da0p4
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| label/FBSDx64Cboot
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| gpt/FBSDFSSDboot
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| gpt/FBSDFSSDroot
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| gpt/FBSDFSSDswap
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| gpt/FBSDFSSDswap2
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| da1p1
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| da2p1
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| da2p2
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| da2p3
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| da2p4
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| gpt/FBSDFSSDbkp
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| ufsid/<REPLACED>
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| gpt/FBSDFSboot
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| gpt/FBSDFSroot
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| ufsid/<REPLACED>
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| gpt/FBSDFBswap
>     0      0      0      0    0.0      0      0    0.0      0      0
> 0.0    0.0| gpt/FBSDFSswap
>
> The sorter list from gstat -pd can be nicer to look at
> when its content happens to be sufficient for ones
> purpose at the time. Otherwise the fuller list can be
> used, giving specific rates and such for individual
> partitions.
>
>
> The initial question for gstat seems to be: can we find the mounted
> SSD partition/slice and/or the overall SSD device in the gstat output.
> Can you check on that? If you find the partition and/or overall device,
> can you show those lines so that I know what they look like?
>
> (gstat might not be an appropriate tool if the SSD is a ZFS-only
> device.)
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
>
> I didn't restart gstat between the tests... so It didn't update to show
the devices after they were added.
dT: 1.064s  w: 1.000s  filter: d
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
    0      0      0      0    0.0      0      0    0.0    0.0| nvd0
    0      0      0      0    0.0      0      0    0.0    0.0| nvd0p1
    0      0      0      0    0.0      0      0    0.0    0.0| nvd0p2
    0      0      0      0    0.0      0      0    0.0    0.0| nvd0p3
    0      0      0      0    0.0      0      0    0.0    0.0| nvd0p4
    0      0      0      0    0.0      0      0    0.0    0.0| msdosfs/EFI
    0      0      0      0    0.0      0      0    0.0    0.0| da0
    0      0      0      0    0.0      0      0    0.0    0.0| ufsid/xxxx
    0      0      0      0    0.0      0      0    0.0    0.0|
msdosfs/TRANSCEND

This is the current output for a simple USB device but this brings up a
whole new slew of errors;
not related to speed but of encodings.
Received on Fri Jan 12 2018 - 16:41:14 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:14 UTC