Date: Fri, 15 May 2020 14:45:05 +0000 From: bugzilla-noreply@freebsd.org To: usb@FreeBSD.org Subject: [Bug 244356] Writing to a USB 3.0 stick is very slow Message-ID: <bug-244356-19105-ChIbLgeXOG@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-244356-19105@https.bugs.freebsd.org/bugzilla/> References: <bug-244356-19105@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D244356 --- Comment #45 from Olivier Certner <olivier.freebsd@free.fr> --- Hi S=C3=A9bastien and Hans, Contrary to what I recalled (or something changed since then), SD_64G and SD_128G indeed seem bad. I did some tests in order to verify behavior on ot= her OSes, and both sticks exhibit the same transfer pattern on recent Linux and MacOS X machines, i.e., usually 2 or 3s of decent bandwidth, followed by 2 = or 3s without transfer and some "probe" transaction, often repeated. So I'm si= mply going to RMA them. The only difference with other OSes is that apparent bandwidth is somewhat higher, though still low (USB 2.0 or less speeds). KB/t appears to be frequently near 1024, where it is around 128 on FreeBSD (but then with high= er tps); the overhead of smaller transactions may explain the difference. Will test KT_32G later to see how it fares. Hans, thanks for `usbtest`. A few question: In `usbtest`, does <Random> for the I/O size has any alignm= ent constraint on the size (like multiples of some power of 2, or only powers of 2)? And what about <Increasing>? In umass, is it possible to have longer transaction then 128KB? Thanks. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-244356-19105-ChIbLgeXOG>