From owner-freebsd-current@freebsd.org Sun Jan 7 12:42:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98A39E6B75E for ; Sun, 7 Jan 2018 12:42:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-154.reflexion.net [208.70.210.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 56FF3201F for ; Sun, 7 Jan 2018 12:42:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8181 invoked from network); 7 Jan 2018 11:42:32 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 7 Jan 2018 11:42:32 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sun, 07 Jan 2018 06:42:32 -0500 (EST) Received: (qmail 28111 invoked from network); 7 Jan 2018 11:42:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Jan 2018 11:42:32 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A20ABEC9458; Sun, 7 Jan 2018 03:42:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: USB stack From: Mark Millard In-Reply-To: <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> Date: Sun, 7 Jan 2018 03:42:31 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> To: blubee blubeeme X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 12:42:39 -0000 [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 wrote: > [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 = 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. 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? =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. 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. =3D=3D=3D Mark Millard markmi at dsl-only.net