13 Jul
2016
13 Jul
'16
5:25 p.m.
Hi,
I've hit a strange issue with a new USB storage device.
(Corsair Slider X2 64GB)
On a Windows 10 laptop, it'll happily get ~75mbyte/sec writes.[1]
Reads are even faster.
However on my Linux workstation the best I can get is 27 mbyte/sec, and the
usual speed more like 9-10 mbyte/sec. ie. Awful.
Reads aren't much better, at 37mbyte/sec.
The same workstation can happily read and write very fast to other USB 3
storage devices, so I know the USB 3 ports are active.
I've tested with vfat, ext4, btrfs and ntfs filesystems, plus just plain
using "dd" to write to the raw device. In all cases, performance is
terrible.
I've played with mount options (sync, async, direct io, journal modes, etc)
and it doesn't make a huge difference.
I don't suppose anyone else has hit this, and might have a fix?
(I'll test on an alternative Linux system tonight, with a slightly
different Linux kernel and motherboard.)
-Toby
1: Actual writes, not cached -- which I think is Windows default for
removable storage. But tested by writing far more data than the laptop has
RAM, followed by quickly selecting "Safely eject the device".
14 Jul
14 Jul
5:16 p.m.
Toby Corkindale via luv-main
<luv-main(a)luv.asn.au> writes:
Hi,
I've hit a strange issue with a new USB storage device.
(Corsair Slider X2 64GB)
On a Windows 10 laptop, it'll happily get ~75mbyte/sec writes.[1]
Reads are even faster.
However on my Linux workstation the best I can get is 27 mbyte/sec, and the
usual speed more like 9-10 mbyte/sec. ie. Awful.
Reads aren't much better, at 37mbyte/sec.
The same workstation can happily read and write very fast to other USB 3
storage devices, so I know the USB 3 ports are active.
I've tested with vfat, ext4, btrfs and ntfs filesystems, plus just plain
using "dd" to write to the raw device. In all cases, performance is
terrible.
I've played with mount options (sync, async, direct io, journal modes, etc)
and it doesn't make a huge difference.
I don't suppose anyone else has hit this, and might have a fix?
(I'll test on an alternative Linux system tonight, with a slightly
different Linux kernel and motherboard.)
Brainstorm things to check:
* remove any unnecessary components e.g. USB hubs from the environment.
* does dmesg complain about it?
* does it draw too much power for that port?
* are other port blocks (different chipset &c) OK?
e.g. front panel is often worse.
* Is it DEFINITELY doing more than USB2 theoretical max?
Compare the speed you get to the max speed of USB2 and USB3.
(IIRC USB2.0 is 480mbps = 60MiB/s).
* is power saving being auto-enabled ever time you plug in the device,
by some crack-smoking udev rule? Remember to check the device *and*
the internal hub. If powertop --auto is involved, remove it while testing.
* is the system doing a lot of fsyncs &c at the time?
this can break even unrelated filesystems IME.
The place I hit it was doing a dpkg install (many many syncs) while
under heavy RRD write load (random access).
* faint hope, but does SMART work with the drive?
5:41 p.m.
On Thu, 14 Jul 2016 at 17:17 Trent W. Buck via luv-main <luv-main(a)luv.asn.au wrote:
No
* are other port blocks (different chipset &c) OK?
> e.g. front panel is often worse.
Seems to perform the same.
* Is it DEFINITELY doing more than USB2 theoretical max?
> Compare the speed you get to the max speed of USB2 and USB3.
> (IIRC USB2.0 is 480mbps = 60MiB/s).
I can read at nearly 100mbyte/sec, which is definitely USB3 speed.
> * is power saving being auto-enabled ever time you plug in the device,
> by some crack-smoking udev rule? Remember to check the device *and*
> the internal hub. If powertop --auto is involved, remove it while
> testing.
powertop is not running. I'm not sure how to check the rest :/
Another fast USB stick is confirmed as working at ~60mbyte/sec in the same
machines and ports though.
* is the system doing a lot of fsyncs &c at the time?
> this can break even unrelated filesystems IME.
Err, to some degree, yes.. both systems I've tested have had apps running,
at least in the background. But this is true for a Windows system too --
there's always a whole lotta stuff going on in there.
> The place I hit it was doing a dpkg install (many many syncs) while
> under heavy RRD write load (random access).
> * faint hope, but does SMART work with the
drive?
Negative. Neither does hdparm.
Thanks for the suggestions though.
-Toby
Toby Corkindale via luv-main
<luv-main(a)luv.asn.au> writes:
Hi,
I've hit a strange issue with a new USB storage device.
(Corsair Slider X2 64GB)
(I'll test on an alternative Linux system tonight, with a slightly
different Linux kernel and motherboard.)
Brainstorm things to check:
* remove any unnecessary components e.g. USB hubs from the environment.
* does dmesg complain about it?
No
* does it draw too much power for that port?
15 Jul
15 Jul
10:53 a.m.
Toby Corkindale wrote:
Something like this:
find /sys/ -xdev -path '*usb*/power/control' -exec grep -H -e ^ -e auto {} +
"on" means the device is permanently powered up.
"auto" means it'll turn off when idle.
I'm not sure what they should be *in general*, but a couple of times
I've hit problems with devices misbehaving and forcing their power
from "auto" to "on" helped.
* is power
saving being auto-enabled ever time you plug in the device,
by some crack-smoking udev rule? Remember to check the device *and*
the internal hub. If powertop --auto is involved, remove it while
testing.
powertop is not running. I'm not sure how to check the rest :/
14 Jul
14 Jul
5:18 p.m.
Toby Corkindale via luv-main
<luv-main(a)luv.asn.au> writes:
PS: also: if you take the working windows+hardware config and replace
windows with live linux, then something like gddrescue /dev/zero /dev/sdz,
does that show the same slowdown? If so that would be a strong
indication the fault is with linux kernel/userland, not hardware.
5:44 p.m.
On Wed, Jul 13, 2016 at 07:25:25AM +0000, Toby Corkindale via luv-main wrote:
I've hit a strange issue with a new USB storage
device.
(Corsair Slider X2 64GB)
On a Windows 10 laptop, it'll happily get ~75mbyte/sec writes.[1]
Reads are even faster.
However on my Linux workstation the best I can get is 27 mbyte/sec, and the
usual speed more like 9-10 mbyte/sec. ie. Awful.
Reads aren't much better, at 37mbyte/sec.
does 'lsusb -t' say it's running at 5000M?
eg.
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
|__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
I guess there's a chance your device has been blacklisted for not playing
nicely with usb3 or something like that too. you could grep for its usb
ids under /etc/udev or /usr/lib/udev.
cheers,
robin
5:56 p.m.
Thanks for the tip. But that confirms it's running at 5000M:
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
|__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
Weird, hey?
It is almost like it's just not being allowed to get full speed though.
I'm running Linux kernel 4.4.0 and 4.3.0 on the relevant machines.
I did actually discover that initially, on one machine, I was accidentally
using USB2, but after that facepalm moment and using usb3, only read speed
went up -- writes still cap out at 27-28 mbyte/sec.
Toby
On Thu, 14 Jul 2016 at 17:44 Robin Humble via luv-main <luv-main(a)luv.asn.au>
wrote:
On Wed, Jul 13, 2016 at 07:25:25AM +0000, Toby
Corkindale via luv-main
wrote:
I've hit a strange issue with a new USB
storage device.
(Corsair Slider X2 64GB)
On a Windows 10 laptop, it'll happily get ~75mbyte/sec writes.[1]
Reads are even faster.
However on my Linux workstation the best I can get is 27 mbyte/sec, and
the
usual speed more like 9-10 mbyte/sec. ie. Awful.
Reads aren't much better, at 37mbyte/sec.
does 'lsusb -t' say it's running at 5000M?
eg.
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
|__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
I guess there's a chance your device has been blacklisted for not playing
nicely with usb3 or something like that too. you could grep for its usb
ids under /etc/udev or /usr/lib/udev.
cheers,
robin
_______________________________________________
luv-main mailing list
luv-main(a)luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
15 Jul
15 Jul
11 a.m.
On Thu, 14 Jul 2016 at 18:59 Robin Humble via luv-main <luv-main(a)luv.asn.au>
wrote:
On Thu, Jul 14, 2016 at 07:56:55AM +0000, Toby
Corkindale wrote:
When I was first testing it, I noticed that with block sizes around, say,
10M, it went at ~8mbyte/sec. With 100+M blocks, I could hit 24 or so.
-Toby
went up -- writes still cap out at 27-28
mbyte/sec.
if you dd using large blocks does that improve things?
eg.
dd if=/dev/zero of=<whatever> bs=8M oflag=direct
18 Jul
18 Jul
11:24 a.m.
Toby Corkindale via luv-main writes:
That's why I suggested GNU ddrescue -
it auto-adjusts the block size for best throughput.
(... I think. These days I mostly just use cp foo.iso /dev/sdb.)
if you dd
using large blocks does that improve things?
eg.
dd if=/dev/zero of=<whatever> bs=8M oflag=direct
When I was first testing it, I noticed that with block sizes around, say,
10M, it went at ~8mbyte/sec. With 100+M blocks, I could hit 24 or so.
2:54 p.m.
On Mon, 18 Jul 2016 at 11:24 Trent W. Buck via luv-main <luv-main(a)luv.asn.au>
wrote:
Toby Corkindale via luv-main writes:
That's why I suggested GNU ddrescue -
it auto-adjusts the block size for best throughput.
(... I think. These days I mostly just use cp foo.iso /dev/sdb.)
And that's the thing.. all I want to do is "cp file /mnt/blah" too.
And that method (cp) does report the highest throughput -- it's just that
it caps out at 27 mbyte/sec. Whereas on a Windows laptop or workstation, it
smashes it out at 75mbyte/sec. (And there are plenty of reviews online
confirming the high speed)
I guess it's just something in the Linux usb implementation sucking in some
peculiar way to this Corsair stick.. :(
Toby
if you dd
using large blocks does that improve things?
eg.
dd if=/dev/zero of=<whatever> bs=8M oflag=direct
When I was first testing it, I noticed that with block sizes around, say,
10M, it went at ~8mbyte/sec. With 100+M blocks, I could hit 24 or so.
2446
days inactive
2451
days old
10 comments
4 participants
participants (4)
-
Robin Humble -
Toby Corkindale -
Trent W. Buck -
trentbuck＠gmail.com