Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Jan 2018 17:44:53 -0600
From:      Jon Brawn <jon@brawn.org>
To:        blubee blubeeme <gurenchan@gmail.com>
Cc:        Warner Losh <imp@bsdimp.com>, "O'Connor, Daniel" <darius@dons.net.au>, gljennjohn@gmail.com, FreeBSD current <freebsd-current@freebsd.org>
Subject:   Re: USB stack
Message-ID:  <D9F7EB72-71CF-463F-B4AE-C3EFCB453721@brawn.org>
In-Reply-To: <CALM2mEmgn4FmBLtW4SaGEEqoF6AsFR_y1PUMTZ80_2GpDx1SdQ@mail.gmail.com>
References:  <CALM2mEmZFP9dGOivJknrCaaa-K1cSxNTTEV%2B8XCMpoZp-xcbqQ@mail.gmail.com> <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <CALM2mE=7cKcPzJ=-bVvmHez2inrAqJsuMaW%2BUZZtXesB3pzDtQ@mail.gmail.com> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> <CALM2mE=uFK0BVqxFcrU_K%2BN%2BwYnu9VTewACeNqPTGYFEv93g4g@mail.gmail.com> <CANCZdfqna3dy-29g_fB3-aw71Hps2ph_%2BNMBUW9z7nhMBVztjg@mail.gmail.com> <CALM2mEmgn4FmBLtW4SaGEEqoF6AsFR_y1PUMTZ80_2GpDx1SdQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

[-- Attachment #1 --]

> On Jan 6, 2018, at 10:18 PM, blubee blubeeme <gurenchan@gmail.com> wrote:
> 
> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh <imp@bsdimp.com> wrote:
> 
>> 
>> 
>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme <gurenchan@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@dons.net.au>
>>> wrote:
>>> 
>>>> 
>>>> 
>>>>> On 4 Jan 2018, at 09:23, Gary Jennejohn <gljennjohn@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@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.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) @
> /usr/src/sys/vm/vm_pager.c:374
> Jan  7 12:06:08 blubee kernel:  2nd 0xfffff80148c425f0 zfs (zfs) @
> /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) @
> /usr/src/sys/kern/vfs_bio.c:3562
> Jan  7 12:06:15 blubee kernel:  2nd 0xfffff8002bb31a00 dirhash (dirhash) @
> /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?

Wotcha!

I don’t see any read or write performance figures anywhere? Also, is this CURRENT? If so, aren’t all the debug / warning features that are turned on by default in CURRENT at the moment going to have an effect on throughput? Especially if you’re writing through a filesystem where directory and file accesses will each require a lock to be taken, if only for a short while? If you want to get closer to the true USB speed of the device, stop mounting it and copying files to the filesystem, but instead just dd data onto and off of the device directly, and measure how fast that goes. Remember to backup your data from the card first…

Jon.



[-- Attachment #2 --]
0	*H
010	+0	*H
0%0
$sYԛy0
	*H
010	UGB10UGreater Manchester10USalford10U
COMODO CA Limited1=0;U4COMODO RSA Client Authentication and Secure Email CA0
171028000000Z
181028235959Z010	*H
	
jon@brawn.org0"0
	*H
0
,r	#\Gi7As 1bzE_(>dzh
[
jyg*?n>c!)&ۥY6]vVhR>1=֞Sxݳ]ˈ*p1k5%$ŗUia2:(M,}wi:h:/FN5k=Q_i0H^z8Y|eAY&.TѢJD##k! VǶrE00U#0la|=+qH^ċ0UX_`JX79"7VW0U0U00 U%0++10	`HB 0FU ?0=0;+10+0)+https://secure.comodo.net/CPS0ZUS0Q0OMKIhttp://crl.comodoca.com/COMODORSAClientAuthenticationandSecureEmailCA.crl0+0}0U+0Ihttp://crt.comodoca.com/COMODORSAClientAuthenticationandSecureEmailCA.crt0$+0http://ocsp.comodoca.com0U0
jon@brawn.org0
	*H
`YWqyTټE<JHT$?/ޟ4Zj;	2b%:!̢Oh-
^`l|Hz<]楌GTkp{}<zlvPt|@ɢo9zrC]
G/W=iDK>k`5H^|iT	ňhx?N
yra2~{O8AQur00Πj8;+kٸRV0
	*H
010	UGB10UGreater Manchester10USalford10U
COMODO CA Limited1+0)U"COMODO RSA Certification Authority0
130110000000Z
280109235959Z010	UGB10UGreater Manchester10USalford10U
COMODO CA Limited1=0;U4COMODO RSA Client Authentication and Secure Email CA0"0
	*H
0
W(vu@8v!P%yL}:X>1.4vلj=4HK hyt4z|e`'"2@rF5P3*UT+%4D5+
ZSu+­=7F_Zte
>)
94Fro8pNhFF#Ne6/M{UWֱmAYT"o)CI	m84$.zW4 r^M9,R$
<080U#0~=<8220Ula|=+qH^ċ0U0U00U 
00U 0LUE0C0A?=;http://crl.comodoca.com/COMODORSACertificationAuthority.crl0q+e0c0;+0/http://crt.comodoca.com/COMODORSAAddTrustCA.crt0$+0http://ocsp.comodoca.com0
	*H
x\(4O<_VΟV쏢kI/5@qB!fk&kn{hJd| q[Lǿᓬ?"@fCOݐrXurJH5;#68jle) )Y4’Nezyq{:kx%iچ:w#f6HLP~jo9KXnM#:!!69i\}^M;TSX7	̯3]Tc6O$voX*5!4.aKE8HIĹ7?Ar}r# R/h<סnuy<1	3mɔv#~&pvg' skMH#/ƨ$/uXqTu(|^-vM҆NKX7fA\X5sh2qP\YǟENRarpGtZp_"k7DdJVGz100010	UGB10UGreater Manchester10USalford10U
COMODO CA Limited1=0;U4COMODO RSA Client Authentication and Secure Email CA$sYԛy0	+0	*H
	1	*H
0	*H
	1
180107234454Z0#	*H
	1	J7<E:DW3IU0	+710010	UGB10UGreater Manchester10USalford10U
COMODO CA Limited1=0;U4COMODO RSA Client Authentication and Secure Email CA$sYԛy0*H
	1010	UGB10UGreater Manchester10USalford10U
COMODO CA Limited1=0;U4COMODO RSA Client Authentication and Secure Email CA$sYԛy0
	*H
Y0Ê,&cYEp,~w-8#hDB%N"j9j6).٬n_lU6Z~s4xQ~gZIw2HuOE8
cQa$P)7FyBG<ݓ
$ճUB!Vc>+o5VVuw[	kDLZOUA:y8e'qV1vʿ\ȿ3cHމ2p

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D9F7EB72-71CF-463F-B4AE-C3EFCB453721>