From owner-freebsd-usb@freebsd.org Tue May 26 10:03:20 2020 Return-Path: Delivered-To: freebsd-usb@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1F3652F8525 for ; Tue, 26 May 2020 10:03:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49WV0805c4z3ZTb for ; Tue, 26 May 2020 10:03:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 0147E2F862B; Tue, 26 May 2020 10:03:20 +0000 (UTC) Delivered-To: usb@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 011022F862A for ; Tue, 26 May 2020 10:03:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49WV076JgDz3ZTZ for ; Tue, 26 May 2020 10:03:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D3F7721C96 for ; Tue, 26 May 2020 10:03:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 04QA3J0e060742 for ; Tue, 26 May 2020 10:03:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 04QA3Jho060741 for usb@FreeBSD.org; Tue, 26 May 2020 10:03:19 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: usb@FreeBSD.org Subject: [Bug 244356] Writing to a USB 3.0 stick is very slow Date: Tue, 26 May 2020 10:03:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: usb X-Bugzilla-Version: 12.1-RELEASE X-Bugzilla-Keywords: needs-qa, performance X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: olivier.freebsd@free.fr X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: usb@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 10:03:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D244356 --- Comment #89 from Olivier Certner --- Last test on SD_128G was done with UFS+SU, block size and fragment size set= to 64k. Unfortunately, I got lots of (apparently transient) write errors in `dmesg`, so not sure whether results are really representative. Either the stick is failing, or the controller still doesn't like the pattern of acces= ses presented to it. Each transaction's size is 64k at least, sometimes 128k. Perhaps strangely, errors are reported mostly for 128k-aligned addresses (~94% of the time). M= ight be because the first write was to the upper 64k part of a 128k block. And s= ince I'm not seeing them with exFAT, this would hint for a flash block size of precisely 128k. I did some more stats about clusters of errors, but nothing especially interesting jumped to my eye. For the record, global bandwidth is again bad (4.8MiB/s; 28MiB/s not counti= ng stalls), stalls account for ~83% of total test duration. Around 84GiB were copied. If I do the same statistics after around ~18GiB have been copied, f= or them to be more comparable with previous tests, I get 17.4MiB/s overall bandwidth, which is way much better than best reported bandwidth for UFS so= far (around x2). There is a steep bandwidth decrease after about 14GiB have been transferred. Prior to this point bandwidth is >=3D 20MiB/s, sometimes growi= ng up to 50MiB/s. After this point, bandwidth is always below 10MiB/s, in general less than half of it (but with some spikes to 10MiB/s now and then). The bandwidth decrease is much less clear with exFAT. It happens after a lot more data have been transferred (>=3D 68GiB, going from ~60MiB/s to ~30MiB/= s), is not as dramatic as bandwidth can recover to up to 75% of the initial value sometimes, and may not be comparable since I saw that for some reason files= get overwritten (strange, I should figure this out). Now going to try simple `yes | dd` tests on Linux and FreeBSD, after full s= tick zeroing. --=20 You are receiving this mail because: You are the assignee for the bug.=