I have a USB 3.0 portable drive which I've used for years with two desktops, each with black USB 2.0 ports. I used to get roughly 25 MB/s transfer speed which AIUI is roughly to be expected given that it's limited to USB 2. Lately, the transfer speed is much slower, around 2 MB/s. I thought maybe it was the new 6.10 kernel, so I tried the older 6.9.12 kernel, no difference. I also have a F40 laptop with two blue SS USB 3.0 ports and one yellow USB port, which ought to be at least as fast as the blue ports. When I plug the portable drive into either of the blue ports, I get roughly 50 MB/s, and with the yellow port I get roughly 25 MB/s. The fact that I can get up to 50 MB/s tells me that there's probably nothing physically wrong with the portable drive. Are there any known kernel issues that would mess up USB transfer speed? Unfortunately I don't remember exactly when the problem started but it was fairly recent.
Testing a little more, the transfer speed between the desktop's black USB ports and the portable drive is only slow (around 2 MB/s) in one direction, from the desktop to the portable drive. From the portable drive to the desktop, it's about the same as before, around 25 MB/s. With the laptop's 3.x USB ports, the direction didn't seem to matter AFAICT.
BTW the portable drive's USB port is labeled SS and colored blue, so it's definitely USB 3.0.
Is this a spinning disk or an SSD? And what are you writing to the disk? And what filesystem is on the disk?
On Thu, Aug 15, 2024 at 12:23 PM Andre Robatino robatino@fedoraproject.org wrote:
Testing a little more, the transfer speed between the desktop's black USB ports and the portable drive is only slow (around 2 MB/s) in one direction, from the desktop to the portable drive. From the portable drive to the desktop, it's about the same as before, around 25 MB/s. With the laptop's 3.x USB ports, the direction didn't seem to matter AFAICT.
BTW the portable drive's USB port is labeled SS and colored blue, so it's definitely USB 3.0.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The portable drive is a HDD, formatted with BTRFS (same as each of the three F40 machines, the two desktops and the laptop). The desktops have HDDs and the laptop has an SSD but they always have and the transfer speed used to be faster, none of that hardware has changed. After noticing the slow transfer, I'm testing by rsync'ing a single large file in both directions to note the transfer speed (and of course deleting it on the target disk afterwards so it's doing the full transfer each time). I suppose that nowadays it's rare to have machines with black USB 2.0 ports so that may be why nobody's noticed it, my hardware is old. As I said the speed seems to be more or less normal to/from the laptop with its USB 3.x ports, though I'm puzzled why it would be slower with the yellow ports than the blue ones, yellow ports are faster.
You might install usbview and run it. It will give you a gui window and let you drill down and examine what each USB device looks like.
It would make me think it is some BTRFS issue. maybe for some reason the disk is fragmented and having to write blocks all over the place. The way I know to test this is to write the file, note the rate that you write it, and then clear the disk cache on the machine and/or force dd to read the file enabling directio and see if it is slow coming off the disk. If it is fragmentation the read off the disk will be similarly slow.
On Thu, Aug 15, 2024 at 1:16 PM Andre Robatino robatino@fedoraproject.org wrote:
The portable drive is a HDD, formatted with BTRFS (same as each of the three F40 machines, the two desktops and the laptop). The desktops have HDDs and the laptop has an SSD but they always have and the transfer speed used to be faster, none of that hardware has changed. After noticing the slow transfer, I'm testing by rsync'ing a single large file in both directions to note the transfer speed (and of course deleting it on the target disk afterwards so it's doing the full transfer each time). I suppose that nowadays it's rare to have machines with black USB 2.0 ports so that may be why nobody's noticed it, my hardware is old. As I said the speed seems to be more or less normal to/from the laptop with its USB 3.x ports, though I'm puzzled why it would be slower with the yellow ports than the blue ones, yellow ports are faster.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The drive is about 76% full but I don't think it's fragmentation since the transfer of the same ~2 GB file to the portable drive is consistently relatively fast from a blue or yellow USB port, and very slow from a black USB port. Here's the output of "df -T /dev/sdb1" with the drive plugged in:
Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/sdb1 btrfs 976759808 735116440 239872328 76% /run/media/andre/Seagate
Below is the output from usbview, this is with it plugged into the desktop's black USB 2.0 port so it's only showing that speed, not the USB 3.0 speed of the portable drive.
Backup+ BK Manufacturer: Seagate Serial Number: NA515PK9 Speed: 480Mb/s (high) Bus: 2 Address: 3 USB Version: 2.10 Device Class: 00 Device Subclass: 00 Device Protocol: 00 Maximum Default Endpoint Size: 64 Number of Configurations: 1 Vendor Id: 0bc2 Product Id: a013 Revision Number: 01.00
Config Number: 1 Number of Interfaces: 1 Attributes: 80 MaxPower Needed: 100mA
Interface Number: 0 Name: usb-storage Alternate Number: 0 Class: 08 Sub Class: 06 Protocol: 50 Number of Endpoints: 2
Endpoint Address: 02 Direction: out Attribute: 2 Type: Bulk Max Packet Size: 512 Interval: 0ms
Endpoint Address: 81 Direction: in Attribute: 2 Type: Bulk Max Packet Size: 512 Interval: 0ms
So it is only slow on the slow port? If so it kind of sounds like the fs may be mounted sync and/or the disks write cache is disabled. smartctl --xall <device> sometimes works against usb disk and sometimes it does not work. if it works it will tell you the write cache status. The sync and/or btrfs filesystem settings would be seen in /proc/mounts
On Thu, Aug 15, 2024 at 3:09 PM Andre Robatino robatino@fedoraproject.org wrote:
The drive is about 76% full but I don't think it's fragmentation since the transfer of the same ~2 GB file to the portable drive is consistently relatively fast from a blue or yellow USB port, and very slow from a black USB port. Here's the output of "df -T /dev/sdb1" with the drive plugged in:
Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/sdb1 btrfs 976759808 735116440 239872328 76% /run/media/andre/Seagate
Below is the output from usbview, this is with it plugged into the desktop's black USB 2.0 port so it's only showing that speed, not the USB 3.0 speed of the portable drive.
Backup+ BK Manufacturer: Seagate Serial Number: NA515PK9 Speed: 480Mb/s (high) Bus: 2 Address: 3 USB Version: 2.10 Device Class: 00 Device Subclass: 00 Device Protocol: 00 Maximum Default Endpoint Size: 64 Number of Configurations: 1 Vendor Id: 0bc2 Product Id: a013 Revision Number: 01.00
Config Number: 1 Number of Interfaces: 1 Attributes: 80 MaxPower Needed: 100mA
Interface Number: 0 Name: usb-storage Alternate Number: 0 Class: 08 Sub Class: 06 Protocol: 50 Number of Endpoints: 2 Endpoint Address: 02 Direction: out Attribute: 2 Type: Bulk Max Packet Size: 512 Interval: 0ms Endpoint Address: 81 Direction: in Attribute: 2 Type: Bulk Max Packet Size: 512 Interval: 0ms-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The output of "smartctl --xall /dev/sdb1" includes
SMART support is: Available - device has SMART capability. SMART support is: Disabled Temperature Warning: Disabled or Not Supported query_cmd_support response too short Read Cache is: Enabled Writeback Cache is: Enabled
Interestingly, I haven't been able to get SMART data from my internal drives using gnome-disks (see https://bugzilla.redhat.com/show_bug.cgi?id=2303813 ) but I could using smartctl -a. With the portable drive, it's reversed, I get the SMART data from gnome-disks but not from smartctl -a or -x. Anyway, I doubt that has anything to do with this since that started with kernel 6.10.3 and the slow transfer problem started before 6.9.12.
The output of /proc/mounts includes
/dev/sdb1 /run/media/andre/Seagate btrfs rw,sync,seclabel,nosuid,nodev,relatime,space_cache,subvolid=5,subvol=/ 0 0
On any other filesystems I have used, using sync makes performance suck.
No idea about what is normal/ok for btrfs.
You might see if all btrfs filesystems are using sync or just the removable ones are.
On Thu, Aug 15, 2024 at 5:21 PM Andre Robatino robatino@fedoraproject.org wrote:
The output of "smartctl --xall /dev/sdb1" includes
SMART support is: Available - device has SMART capability. SMART support is: Disabled Temperature Warning: Disabled or Not Supported query_cmd_support response too short Read Cache is: Enabled Writeback Cache is: Enabled
Interestingly, I haven't been able to get SMART data from my internal drives using gnome-disks (see https://bugzilla.redhat.com/show_bug.cgi?id=2303813 ) but I could using smartctl -a. With the portable drive, it's reversed, I get the SMART data from gnome-disks but not from smartctl -a or -x. Anyway, I doubt that has anything to do with this since that started with kernel 6.10.3 and the slow transfer problem started before 6.9.12.
The output of /proc/mounts includes
/dev/sdb1 /run/media/andre/Seagate btrfs rw,sync,seclabel,nosuid,nodev,relatime,space_cache,subvolid=5,subvol=/ 0 0
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 15 Aug 2024, at 21:29, Roger Heflin rogerheflin@gmail.com wrote:
So it is only slow on the slow port? If so it kind of sounds like the fs may be mounted sync and/or the disks write cache is disabled. smartctl --xall <device> sometimes works against usb disk and sometimes it does not work. if it works it will tell you the write cache status. The sync and/or btrfs filesystem settings would be seen in /proc/mounts
Are you using nemo file manager on cinnamon? Is so its a know issue that has been fixed https://discussion.fedoraproject.org/t/much-slower-usb-transfer-speed-after-...
Barry
On Thu, Aug 15, 2024 at 3:09 PM Andre Robatino robatino@fedoraproject.org wrote:
The drive is about 76% full but I don't think it's fragmentation since the transfer of the same ~2 GB file to the portable drive is consistently relatively fast from a blue or yellow USB port, and very slow from a black USB port. Here's the output of "df -T /dev/sdb1" with the drive plugged in:
Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/sdb1 btrfs 976759808 735116440 239872328 76% /run/media/andre/Seagate
Below is the output from usbview, this is with it plugged into the desktop's black USB 2.0 port so it's only showing that speed, not the USB 3.0 speed of the portable drive.
Backup+ BK Manufacturer: Seagate Serial Number: NA515PK9 Speed: 480Mb/s (high) Bus: 2 Address: 3 USB Version: 2.10 Device Class: 00 Device Subclass: 00 Device Protocol: 00 Maximum Default Endpoint Size: 64 Number of Configurations: 1 Vendor Id: 0bc2 Product Id: a013 Revision Number: 01.00
Config Number: 1 Number of Interfaces: 1 Attributes: 80 MaxPower Needed: 100mA
Interface Number: 0 Name: usb-storage Alternate Number: 0 Class: 08 Sub Class: 06 Protocol: 50 Number of Endpoints: 2 Endpoint Address: 02 Direction: out Attribute: 2 Type: Bulk Max Packet Size: 512 Interval: 0ms Endpoint Address: 81 Direction: in Attribute: 2 Type: Bulk Max Packet Size: 512 Interval: 0ms-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
No, I'm using GNOME, although I do have the cinnamon desktop installed. From looking at your link it looks like it's due to using sync, next time I boot my laptop I intend to check if the /proc/mounts shows the portable drive using sync there, since my transfer speed seems to be normal on that.
I just checked the laptop and the /proc/mounts line for the portable drive is
/dev/sdb1 /run/media/andre/Seagate btrfs rw,seclabel,nosuid,nodev,relatime,space_cache,subvolid=5,subvol=/ 0 0
and indeed there is no sync! (Otherwise it's identical to the one posted above from my desktop.) I realized that I have cinnamon installed on my desktops, but not the laptop. Now I have to look into disabling sync, hopefully that will fix it. Thanks for the link!
Installing the nemo Bodhi update from https://bodhi.fedoraproject.org/updates/FEDORA-2024-4717e54d2b does cause sync to be eliminated from the line in /proc/mounts, and my transfer speed is back to normal. Thanks for the replies!
So here is why sync sucks only on a usb 2.0 connection.
The host fills up the disks write cache some portion of (32MB/64MB/128MB) and then the disk waits for the head get to were the data needs to be written and writes it, as the write cache clears space the host sends more data, but at usb2.0 the host cannot send data as fast as the disk is writing so cannot keep up and the write cache will empty. Once the head is no longer writting (location has passed under the head) then the disk write cache will fill and the disk needs to wait for the head to come back around (probably around 10ms) and then this happens again.
At 6000 rpm that is about 100 writes / second and given a 2mb/sec rate then the write cache being used is around 20MB.
At 3.0 speeds the usb bus is fast enough that the write cache should not empty very often and so it is rare that the disk is waiting for the disk head to be at the right location to write the data.
On Fri, Aug 16, 2024 at 8:34 AM Andre Robatino robatino@fedoraproject.org wrote:
Installing the nemo Bodhi update from https://bodhi.fedoraproject.org/updates/FEDORA-2024-4717e54d2b does cause sync to be eliminated from the line in /proc/mounts, and my transfer speed is back to normal. Thanks for the replies!
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 16 Aug 2024, at 18:12, Roger Heflin rogerheflin@gmail.com wrote:
So here is why sync sucks only on a usb 2.0 connection.
The report that lead to the revert of the sync change was on 3.0 connections. The slow down was x10 or more.
So no this is not a USB 2 only issue.
Only if the user program and the USB device can overlap I/O do you get the max speed. If the user space program has to wait on the previous write then you always see a dramatic slowdown.
Barry
It would depend on the buffer size being used. In Andre's case he reported it was ok with non-2.0 speeds, probably just luck that the buffer on his disk is large enough that it works ok.
In general I have never had good luck with sync providing anything resembling a decent speed except with raid subsystems that have battery backed-up caches and/or return done the moment it gets into its cache (whether safe or not).
On Fri, Aug 16, 2024 at 1:25 PM Barry Scott barry@barrys-emacs.org wrote:
On 16 Aug 2024, at 18:12, Roger Heflin rogerheflin@gmail.com wrote:
So here is why sync sucks only on a usb 2.0 connection.
The report that lead to the revert of the sync change was on 3.0 connections. The slow down was x10 or more.
So no this is not a USB 2 only issue.
Only if the user program and the USB device can overlap I/O do you get the max speed. If the user space program has to wait on the previous write then you always see a dramatic slowdown.
Barry
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Roger Heflin wrote:
It would depend on the buffer size being used. In Andre's case he reported it was ok with non-2.0 speeds, probably just luck that the buffer on his disk is large enough that it works ok.
In my case, I didn't have the nemo package installed on my laptop (the one with USB 3.0 ports) so sync was never enabled when using that machine. The two machines with USB 2.0 ports both have nemo installed (as part of the cinnamon desktop) so sync was enabled on them, but the nemo update from Bodhi fixes that.
On Fri, 2024-08-16 at 19:17 +0000, Andre Robatino wrote:
In my case, I didn't have the nemo package installed on my laptop (the one with USB 3.0 ports) so sync was never enabled when using that machine. The two machines with USB 2.0 ports both have nemo installed (as part of the cinnamon desktop) so sync was enabled on them, but the nemo update from Bodhi fixes that.
Is it just nemo with the problem? Because that file browser is on systems under various different program names (nemo, nautilus, caja) with *some* tinkering between the different forks.
* It is only a file "browser," it doesn't have enough of the features required to be called a file "manager."
Tim wrote:
Is it just nemo with the problem? Because that file browser is on systems under various different program names (nemo, nautilus, caja) with *some* tinkering between the different forks.
All I know is that my two desktops have the GNOME, KDE, MATE, Cinnamon, and Basic DEs installed, and by updating the nemo package to the Bodhi testing version, sync was disabled, so there's nothing else in those DEs causing the problem at present.
On 16 Aug 2024, at 19:28, Roger Heflin rogerheflin@gmail.com wrote:
It would depend on the buffer size being used.
The buffer size is not the limit., unless it's lots of GiB in size. It's the fact that you go into a half-duplex mode that sets the limit.
This pattern slows down all sorts of algorithms, disk access, network access etc is this:
1. Write 2. Wait for ack to write (sync) 3. Write 4. Wait for ack to write (sync)
It's the wait times for 2, 4 etc that kill performance even if you have infinite bandwidth.
This is why the early web was slow. Load a page that needs to load images etc triggers this pattern.
If the user app can write while the kernel is flushing to storage then you get to run at the limit of the storage interface. This is like full-duplex networking.
Barry
On 16 Aug 2024, at 21:29, Andre Robatino robatino@fedoraproject.org wrote:
All I know is that my two desktops have the GNOME, KDE, MATE, Cinnamon, and Basic DEs installed, and by updating the nemo package to the Bodhi testing version, sync was disabled, so there's nothing else in those DEs causing the problem at present.
The nemo package installed a udev rule that affected all USB disks. And as the udev rule is a system settings if affects the whole system regardless of the DE that you log into.
Barry
-
Andre Robatino -
Barry -
Barry Scott
-
Roger Heflin -
Tim