Re: USB stack

From: blubee blubeeme <gurenchan_at_gmail.com>
Date: Sun, 7 Jan 2018 13:44:18 +0800
On Sun, Jan 7, 2018 at 1:32 PM, Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>
wrote:

> On Sun, 7 Jan 2018 12:25:17 +0800
> blubee blubeeme <gurenchan_at_gmail.com> wrote:
>
> > On Sun, Jan 7, 2018 at 12:20 PM, Warner Losh <imp_at_bsdimp.com> wrote:
> >
> > >
> > >
> > > On Sat, Jan 6, 2018 at 9:18 PM, blubee blubeeme <gurenchan_at_gmail.com>
> > > wrote:
> > >
> > >>
> > >>
> > >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh <imp_at_bsdimp.com> wrote:
> > >>
> > >>>
> > >>>
> > >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme <gurenchan_at_gmail.com
> >
> > >>> wrote:
> > >>>
> > >>>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or
> greater
> > >>>> and the topic gets derailed...?
> > >>>>
> > >>>
> > >>> Yes, it does.
> > >>>
> > >>>
> > >>>> Are you guys saying that 7-8MB/s is USB speeds?
> > >>>>
> > >>>
> > >>> I've gotten up to 24MB/s for maybe a decade. That's not possible with
> > >>> USB 1.x. More recently, I've maxed out the writes on a USB stick at
> about
> > >>> 75MB/s (the fastest it will do), which isn't possible with USB
> 2.0... I've
> > >>> not tried USB3 with an SSD that can do more....
> > >>>
> > >>> Warner
> > >>>
> > >>>
> > >>>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel <
> darius_at_dons.net.au>
> > >>>> wrote:
> > >>>>
> > >>>> >
> > >>>> >
> > >>>> > > On 4 Jan 2018, at 09:23, Gary Jennejohn <gljennjohn_at_gmail.com>
> > >>>> wrote:
> > >>>> > >> What is an "LG v30"?
> > >>>> > >>
> > >>>> > > It's a smartphone from LG and only supports USB2 speed.  The
> > >>>> reported
> > >>>> > > transfer rate is no big surprise.
> > >>>> >
> > >>>> > OK thanks.
> > >>>> >
> > >>>> > --
> > >>>> > Daniel O'Connor
> > >>>> > "The nice thing about standards is that there
> > >>>> > are so many of them to choose from."
> > >>>> >  -- Andrew Tanenbaum
> > >>>> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F
> CE8C
> > >>>> >
> > >>>> >
> > >>>> _______________________________________________
> > >>>> freebsd-current_at_freebsd.org mailing list
> > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_f
> > >>>> reebsd.org"
> > >>>>
> > >>>
> > >>> I just connected a Transcend StorageJet 1TB hdd not a mobile phone
> > >> -------------------------------------------------------------------
> > >> Jan  7 11:56:56 blubee kernel: umass0 on uhub0
> > >> Jan  7 11:56:56 blubee kernel: umass0: <StoreJet Transcend StoreJet
> > >> Transcend, class 0/0, rev 3.00/80.00, addr 4> on usbus0
> > >> Jan  7 11:56:56 blubee kernel: umass0:  SCSI over Bulk-Only; quirks =
> > >> 0x0100
> > >> Jan  7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3
> > >> Jan  7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0
> > >> lun 0
> > >> Jan  7 11:56:56 blubee kernel: da0: <StoreJet Transcend 0> Fixed
> Direct
> > >> Access SPC-4 SCSI device
> > >> Jan  7 11:56:56 blubee kernel: da0: Serial Number W9328YZN
> > >> Jan  7 11:56:56 blubee kernel: da0: 400.000MB/s transfers
> > >> Jan  7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte
> sectors)
> > >> Jan  7 11:56:56 blubee kernel: da0: quirks=0x2<NO_6_BYTE>
> > >> Jan  7 12:06:08 blubee kernel: lock order reversal:
> > >> Jan  7 12:06:08 blubee kernel:  1st 0xfffffe07c26336c0 bufwait
> (bufwait)
> > >> _at_ /usr/src/sys/vm/vm_pager.c:374
> > >> Jan  7 12:06:08 blubee kernel:  2nd 0xfffff80148c425f0 zfs (zfs) _at_
> > >> /usr/src/sys/dev/md/md.c:952
> > >> Jan  7 12:06:08 blubee kernel: stack backtrace:
> > >> Jan  7 12:06:08 blubee kernel: #0 0xffffffff80acfa03 at
> > >> witness_debugger+0x73
> > >> Jan  7 12:06:08 blubee kernel: #1 0xffffffff80acf882 at
> > >> witness_checkorder+0xe02
> > >> Jan  7 12:06:08 blubee kernel: #2 0xffffffff80a41b8e at
> > >> lockmgr_lock_fast_path+0x1ae
> > >> Jan  7 12:06:08 blubee kernel: #3 0xffffffff81094309 at
> VOP_LOCK1_APV+0xd9
> > >> Jan  7 12:06:08 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66
> > >> Jan  7 12:06:08 blubee kernel: #5 0xffffffff80611d32 at
> > >> mdstart_vnode+0x442
> > >> Jan  7 12:06:08 blubee kernel: #6 0xffffffff806102ce at
> md_kthread+0x1fe
> > >> Jan  7 12:06:08 blubee kernel: #7 0xffffffff80a2d654 at fork_exit+0x84
> > >> Jan  7 12:06:08 blubee kernel: #8 0xffffffff80ef5e0e at
> > >> fork_trampoline+0xe
> > >> Jan  7 12:06:15 blubee kernel: lock order reversal:
> > >> Jan  7 12:06:15 blubee kernel:  1st 0xfffffe07c41d5dc0 bufwait
> (bufwait)
> > >> _at_ /usr/src/sys/kern/vfs_bio.c:3562
> > >> Jan  7 12:06:15 blubee kernel:  2nd 0xfffff8002bb31a00 dirhash
> (dirhash)
> > >> _at_ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281
> > >> Jan  7 12:06:15 blubee kernel: stack backtrace:
> > >> Jan  7 12:06:15 blubee kernel: #0 0xffffffff80acfa03 at
> > >> witness_debugger+0x73
> > >> Jan  7 12:06:15 blubee kernel: #1 0xffffffff80acf882 at
> > >> witness_checkorder+0xe02
> > >> Jan  7 12:06:15 blubee kernel: #2 0xffffffff80a748a8 at _sx_xlock+0x68
> > >> Jan  7 12:06:15 blubee kernel: #3 0xffffffff80d6a28d at
> > >> ufsdirhash_add+0x3d
> > >> Jan  7 12:06:15 blubee kernel: #4 0xffffffff80d6d119 at
> ufs_direnter+0x459
> > >> Jan  7 12:06:15 blubee kernel: #5 0xffffffff80d76313 at
> > >> ufs_makeinode+0x613
> > >> Jan  7 12:06:15 blubee kernel: #6 0xffffffff80d71ff4 at
> ufs_create+0x34
> > >> Jan  7 12:06:15 blubee kernel: #7 0xffffffff810919e3 at
> > >> VOP_CREATE_APV+0xd3
> > >> Jan  7 12:06:15 blubee kernel: #8 0xffffffff80b4a53d at
> vn_open_cred+0x2ad
> > >> Jan  7 12:06:15 blubee kernel: #9 0xffffffff80b42e92 at
> kern_openat+0x212
> > >> Jan  7 12:06:15 blubee kernel: #10 0xffffffff80f16d2b at
> > >> amd64_syscall+0x79b
> > >> Jan  7 12:06:15 blubee kernel: #11 0xffffffff80ef5b7b at
> > >> Xfast_syscall+0xfb
> > >>
> > >>
> > >> Is the slow transfers user error?
> > >>
> > >
> > > It's likely due to the slow UFS issue...
> > >
> > > Warner
> > >
> > The Transcend ssd is formated ZFS, I use it as a backup.
> >
> > The microsd might suffer from what you say since it's formatted by
> Android
> > but I do not get these slow transfer speeds on other OS.
> >
> > so a quick roundup.
> > 1) 256GB Samsung microsd card gets 7-8MB/s transfer speeds;
> > let's say that's because of the Android OS default format.
> > I only get these slow speeds on FreeBSD, why is that?
>
> Warner is asking "how are you copying" on another thread. How?
> Although it's over LAN, I experience slooooow copying using shells/fd
> to copy (1-2MB/s), while 10-60MB/s by /bin/cp.
> Not measured, but feeling alike for USB memstick (same file to same
> memstick, with at least one reboot between each copy).
> It shoud be said to other filers, which doesn't call /bin/cp internally
> or does just what /bin/cp does.
>
> As for USB memsticks, I had a problematic one, which caused plenty of
> errors, maybe by mismatched quirks. It worked but very slow, sometimes
> suddenly disappeares, although it claimed 90MB/s capable. :-(
>
> >
> > 2) 1TB Transcend SSD formatted to ZFS I pasted the dmesg log above;
> > are the slow speeds user error or something else?
> >
> > _at_Warner Losh
> > what was your setup where you were able to transfer 23-75MB/s to your USB
> > device?
> > _______________________________________________
> > freebsd-current_at_freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_
> freebsd.org"
> >
>
>
> --
> Tomoaki AOKI    <junchoon_at_dec.sakura.ne.jp>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>

I copy using /bin/cp to and from /mnt after I mount said device.
The devices are;
LG v30 with 256GB Samsung microsd
1TB Trascend SSD

Both were linked earlier in this thread.

so, any reason why i'm getting these slow speeds?

I asked what was his setup to get 23-75MB/s but no response to that
question as of yet, why?
Received on Sun Jan 07 2018 - 04:44:20 UTC

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