From owner-freebsd-current@freebsd.org Sun Jan 7 15:50:18 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 BF870E72FB1 for ; Sun, 7 Jan 2018 15:50:18 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8415C6B93E for ; Sun, 7 Jan 2018 15:50:18 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22e.google.com with SMTP id b77so3339055itd.0 for ; Sun, 07 Jan 2018 07:50:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TPTpOFOmKNLsPIFhrF+QHp0wG+NrIr2YaJ1np9e0/lc=; b=IMsbdf7U2nDKtnwRlguLPUqsqFhcK9Q6TfIr2RH9YVzOZmVQuoEUhw7t9LjoKXYdt3 zCtfrEdlD9a8pA+wAyuKVNq9nOCxFfH/xJ6rFk8ezfISlWQ15AR55gtHDpbDBc6i0ALj sRNA9mR3AG0BJ5SEP8H6+GuIUfAVRkAOSufZilQYgD5h6wfSX0X+dykcS1x9J9NsYe62 TILmct3mKKuR4sVh/gA71w7OwR0ECf1cC6bzfF5XdYNKtIbiUlpW+GzTdsUS2manYy2H 6+3fLD/hnHhBHSvmTpWJeuTO3xYRCQER/AFtO2QfL66crbppIH9/arrHp81wySle8abl BXuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TPTpOFOmKNLsPIFhrF+QHp0wG+NrIr2YaJ1np9e0/lc=; b=kff13bc8BbSQ/lpYeJ0NKS8WEQfQaqrVnQBFbee+lWw2DhGC1LHTUQD47WJaSp+jrV 9I8dM8QvTs/5tH0DCCMA0wgQTfUKPjXou51BdN4bRKT7NQBAK71U74K8wUtFkXArfuI9 QqSyiBMpnzHpZTsMbRc8GwR6KvG7abiyD3IV3S1PBryMmCGCS3ZEYdCvegURHdN44fIW F1lcP5W+f6dHBo0N+DL/UrB/iF02U1JSJuTp/O2jktfGI0VszhSbZ7hUnd899pmB6Ubw e7x/O2UBwTEFjRz73d1iEBXNgpwGAg5vtXRhoAK3baid0uCv+1xlgj7VyT9oZxMUEfBz TmsA== X-Gm-Message-State: AKwxytdzeSJlfmlGMgkF6Jx5zBnHIta+CxJN3WDGQmNXJpq9YtjodARK N89WnCAIJTd4HEYMxX25llOUiH9gJxEGHYuaPIE= X-Google-Smtp-Source: ACJfBot2L67m6zwvXjtOUwQyCwIZMazQWjgNONw0+Iwok0DKtyS61n8OuZx0HigYVx5o9H3kKJXDyBw48xwwpxWgwwk= X-Received: by 10.36.185.18 with SMTP id w18mr1795358ite.140.1515340216867; Sun, 07 Jan 2018 07:50:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Sun, 7 Jan 2018 07:50:16 -0800 (PST) In-Reply-To: References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> From: blubee blubeeme Date: Sun, 7 Jan 2018 23:50:16 +0800 Message-ID: Subject: Re: USB stack To: Mark Millard Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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 15:50:18 -0000 On Sun, Jan 7, 2018 at 8:13 PM, Mark Millard 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 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 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 > 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.