USB Storage speed regression since 2.6.12

USB Storage speed regression since 2.6.12

[DervishD]

    Hi all :)

    I don't know if this is a known issue, but usb-storage speed for
'Full speed' devices dropped from 2.6.11.12 (more than 800Kb/s) to
2.6.12 (less than 250Kb/s). The problem still exists in 2.6.13.

    The lack of speed seems to affect only the OHCI driver. My test
was done over a PCI USB 2.0 card, ALi chipset, OHCI driver (well
EHCI+OHCI) and using a full speed device capable of 12MBps. The
average measured speeds are:

    - 2.4.31:           about 450Kb/seg
    - 2.6.11-Debian:    about 800Kb/seg
    - 2.6.11.12:        about 820Kb/seg
    - 2.6.12.x:         about 200Kb/seg
    - 2.6.13:           about 200Kb/seg

    The .config is more or less the same in all kernels. I've took a
look at the ChangeLog for 2.6.12 and there are lots of changes in the
USB subsystem but I cannot identify which one could be the culprit.

    If anyone needs more information (for example, device
identification in all kernels) just tell. I don't provide much more
information since this can be a known issue and so there is no need
to pollute the list with a long .config and dmesg output...

    Thanks in advance :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: USB Storage speed regression since 2.6.12

[Brice Goglin]

Le 01.09.2005 13:36, DervishD a écrit :
>     I don't know if this is a known issue, but usb-storage speed for
> 'Full speed' devices dropped from 2.6.11.12 (more than 800Kb/s) to
> 2.6.12 (less than 250Kb/s). The problem still exists in 2.6.13.
> 
>     The lack of speed seems to affect only the OHCI driver. My test
> was done over a PCI USB 2.0 card, ALi chipset, OHCI driver (well
> EHCI+OHCI) and using a full speed device capable of 12MBps. The
> average measured speeds are:
> 
>     - 2.4.31:           about 450Kb/seg
>     - 2.6.11-Debian:    about 800Kb/seg
>     - 2.6.11.12:        about 820Kb/seg
>     - 2.6.12.x:         about 200Kb/seg
>     - 2.6.13:           about 200Kb/seg

Are you mounting this storage with vfat and 'sync' option ?
IIRC, sync support for vfat was added around 2.6.12, making
write way slower since it's now really synchron.

Brice

Re: USB Storage speed regression since 2.6.12

[linux-os (Dick Johnson)]

On Thu, 1 Sep 2005, DervishD wrote:

>    Hi all :)
>
>    I don't know if this is a known issue, but usb-storage speed for
> 'Full speed' devices dropped from 2.6.11.12 (more than 800Kb/s) to
> 2.6.12 (less than 250Kb/s). The problem still exists in 2.6.13.
>
>    The lack of speed seems to affect only the OHCI driver. My test
> was done over a PCI USB 2.0 card, ALi chipset, OHCI driver (well
> EHCI+OHCI) and using a full speed device capable of 12MBps. The
> average measured speeds are:
>
>    - 2.4.31:           about 450Kb/seg
>    - 2.6.11-Debian:    about 800Kb/seg
>    - 2.6.11.12:        about 820Kb/seg
>    - 2.6.12.x:         about 200Kb/seg
>    - 2.6.13:           about 200Kb/seg
>
>    The .config is more or less the same in all kernels. I've took a
> look at the ChangeLog for 2.6.12 and there are lots of changes in the
> USB subsystem but I cannot identify which one could be the culprit.
>
>    If anyone needs more information (for example, device
> identification in all kernels) just tell. I don't provide much more
> information since this can be a known issue and so there is no need
> to pollute the list with a long .config and dmesg output...
>
>    Thanks in advance :)
>
>    Raúl Núñez de Arenas Coronado
>
> --
> Linux Registered User 88736 | http://www.dervishd.net
> http://www.pleyades.net & http://www.gotesdelluna.net
> It's my PC and I'll cry if I want to...
> -

The SCSI subsystem has similar problems. The speed has
gone down since linux-2.4.26. I'm compiling a bunch of
kernels to see which one starts the down-hill trend.
The SCSI disc sybsystem with this kernel (the initial RedHat
distribution, unmodified 2.6.5-1.358) is awful.

The data I have so far from `hdparam -tT` is:

linux-2.6.13

/dev/sda:
  Timing buffer-cache reads:   3036 MB in  2.00 seconds = 1515.96 MB/sec
  Timing buffered disk reads:   28 MB in  3.14 seconds =   8.93 MB/sec

/dev/sdb:
  Timing buffer-cache reads:   3052 MB in  2.00 seconds = 1523.95 MB/sec
  Timing buffered disk reads:   78 MB in  3.01 seconds =  25.87 MB/sec

/dev/sdc:
  Timing buffer-cache reads:   3024 MB in  2.00 seconds = 1511.47 MB/sec
  Timing buffered disk reads:   56 MB in  3.11 seconds =  18.01 MB/sec

/dev/hda:
  Timing buffer-cache reads:   3040 MB in  2.00 seconds = 1520.23 MB/sec
  Timing buffered disk reads:  132 MB in  3.02 seconds =  43.66 MB/sec

linux-2.4.26	(baseline)

/dev/sda:
  Timing buffer-cache reads:   3032 MB in  2.00 seconds = 1589.64 MB/sec
  Timing buffered disk reads:  128 MB in  3.12 seconds =  43.02 MB/sec

/dev/sdb:
  Timing buffer-cache reads:   3062 MB in  2.00 seconds = 1605.36 MB/sec
  Timing buffered disk reads:  166 MB in  3.01 seconds =  58.73 MB/sec

/dev/sdc:
  Timing buffer-cache reads:   3024 MB in  2.00 seconds = 1511.47 MB/sec
  Timing buffered disk reads:  102 MB in  3.08 seconds =  34.72 MB/sec

/dev/hda:
  Timing buffer-cache reads:   3032 MB in  2.00 seconds = 1589.64 MB/sec
  Timing buffered disk reads:  130 MB in  3.01 seconds =  45.28 MB/sec

Linux-2.4.26 had reasonable performance. The latest kernel has
essentially the same IDE performance, but absolutely awful SCSI
performance, sort of like a floppy.

IT looks as though the SCSI system isn't brought into
synchronous mode because there are two slow devices
(urelated) on the NARROW interface even though there
are 3 WIDE FAST devices on the other bus.

SCSI subsystem initialized
ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 21 (level, low) -> IRQ 17
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
         <Adaptec 2940 Ultra SCSI adapter>
         aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs

   Vendor: SEAGATE   Model: ST32171W          Rev: 0484
   Type:   Direct-Access                      ANSI SCSI revision: 02
  target0:0:0: asynchronous.
scsi0:A:0:0: Tagged Queuing enabled.  Depth 4
  target0:0:0: Beginning Domain Validation
  target0:0:0: wide asynchronous.
  target0:0:0: Domain Validation skipping write tests
  target0:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 8)
  target0:0:0: Ending Domain Validation
SCSI device sda: 4194057 512-byte hdwr sectors (2147 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 4194057 512-byte hdwr sectors (2147 MB)
SCSI device sda: drive cache: write back
  sda: sda1 sda2 < sda5 >
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
   Vendor: SEAGATE   Model: ST318233LWV       Rev: 0002
   Type:   Direct-Access                      ANSI SCSI revision: 03
  target0:0:1: asynchronous.
scsi0:A:1:0: Tagged Queuing enabled.  Depth 4
  target0:0:1: Beginning Domain Validation
  target0:0:1: wide asynchronous.
  target0:0:1: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 8)
  target0:0:1: Ending Domain Validation
SCSI device sdb: 35566480 512-byte hdwr sectors (18210 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 35566480 512-byte hdwr sectors (18210 MB)
SCSI device sdb: drive cache: write back
  sdb: sdb1 sdb2
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
   Vendor: SEAGATE   Model: ST39102LW         Rev: 0005
   Type:   Direct-Access                      ANSI SCSI revision: 02
  target0:0:2: asynchronous.
scsi0:A:2:0: Tagged Queuing enabled.  Depth 4
  target0:0:2: Beginning Domain Validation
  target0:0:2: wide asynchronous.
  target0:0:2: Domain Validation skipping write tests
  target0:0:2: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 8)
  target0:0:2: Ending Domain Validation
SCSI device sdc: 17783240 512-byte hdwr sectors (9105 MB)
SCSI device sdc: drive cache: write back
SCSI device sdc: 17783240 512-byte hdwr sectors (9105 MB)
SCSI device sdc: drive cache: write back
  sdc: sdc1 sdc2 sdc3
Attached scsi disk sdc at scsi0, channel 0, id 2, lun 0
   Vendor: YAMAHA    Model: CRW6416S          Rev: 1.0b
   Type:   CD-ROM                             ANSI SCSI revision: 02
  target0:0:4: asynchronous.
  target0:0:4: Beginning Domain Validation
  target0:0:4: Domain Validation skipping write tests
  target0:0:4: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15)
  target0:0:4: Ending Domain Validation
libata version 1.12 loaded.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.5-1.358 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: USB Storage speed regression since 2.6.12

[DervishD]

    Salut Brice :)

 * Brice Goglin <Brice.Goglin@ens-lyon.org> dixit:
> Le 01.09.2005 13:36, DervishD a écrit :
> >     The lack of speed seems to affect only the OHCI driver. My test
> > was done over a PCI USB 2.0 card, ALi chipset, OHCI driver (well
> > EHCI+OHCI) and using a full speed device capable of 12MBps. The
> > average measured speeds are:
> > 
> >     - 2.4.31:           about 450Kb/seg
> >     - 2.6.11-Debian:    about 800Kb/seg
> >     - 2.6.11.12:        about 820Kb/seg
> >     - 2.6.12.x:         about 200Kb/seg
> >     - 2.6.13:           about 200Kb/seg
> Are you mounting this storage with vfat and 'sync' option ?

    Yes, that may be the problem, but I think that is not the only
problem, see below.

> IIRC, sync support for vfat was added around 2.6.12, making
> write way slower since it's now really synchron.

    The fact is that if I mount the device under 2.4.31 using the
'sync' option, the speed are the ones shown above, but if I mount
them with 'async', the speed is that of the light ;) I mean, the
'sync' option is doing something even in 2.4.31. The same applies to
2.6.11, but I have to test in 2.6.12 & 13.

    Thanks for your help. If the problem is just that, the sync
option, I'll drop a note to the mailing list. Merci mille fois ;)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

[SOLVED] USB Storage speed regression since 2.6.12

[DervishD]

    Hi Brice, again :)

 * Brice Goglin <Brice.Goglin@ens-lyon.org> dixit:
> Are you mounting this storage with vfat and 'sync' option ?
> IIRC, sync support for vfat was added around 2.6.12, making
> write way slower since it's now really synchron.

    That seems to be the problem. Mounting without 'sync' the speed
of transfers is almost infinite ;) but when doing a manual sync it
gives the usual speed of about 800Kb/sec (a little bit less, in
fact...). I've took a look at the ChangeLog for 2.6.12 and I cannot
find any reference to vfat and sync options, but the patch contains a
couple of references to MS_SYNCHRONIZE (or something like that), so
maybe was then when the "-o sync" honouring was added.

    I don't feel comfortable with an vfat mounted asynchronously, but
the new implementation seems to rewrite the fat on every single write
(that's the reason of the slowdown, probably), and since I'm not sure
about the quality of the flash memory present in the device, it is
very probable that it would wear the first sectors :( So I have to
mount it 'async' under 2.6.13; I didn't have to do that on older
kernels because the 'sync' was not honoured by vfat, so the fat was
updated asynchronously but the data were written synchronously (not
cached, at least).

    Thanks a lot for your help :))

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: [SOLVED] USB Storage speed regression since 2.6.12

[Mark Lord]

DervishD wrote:
..
> the new implementation seems to rewrite the fat on every single write
> (that's the reason of the slowdown, probably), and since I'm not sure
> about the quality of the flash memory present in the device, it is
> very probable that it would wear the first sectors :( So I have to
> mount it 'async' under 2.6.13; I didn't have to do that on older

Nearly all flashcard devices (CompactFlash, SD, MMC, ..)
have built-in wear-leveling in the on-card controller logic.
So continuously rewriting the FAT will NOT rewrite the same
on-card physical pages over and over, but rather it will
try to spread those writes out over the entire (available)
span of physical sectors on the device.

So no worries about "wearing out the FAT sectors",
but I'd still use "async" just to reduce the overall
wear and tear regardless.

Cheers

Re: [SOLVED] USB Storage speed regression since 2.6.12

[DervishD]

    Hi Mark :)

 * Mark Lord <lkml@rtr.ca> dixit:
> >the new implementation seems to rewrite the fat on every single
> >write (that's the reason of the slowdown, probably), and since I'm
> >not sure about the quality of the flash memory present in the
> >device, it is very probable that it would wear the first sectors
> >:( So I have to mount it 'async' under 2.6.13; I didn't have to do
> >that on older
> Nearly all flashcard devices (CompactFlash, SD, MMC, ..)
> have built-in wear-leveling in the on-card controller logic.

    I know, but this device is a very cheap MP3 player, and I'm
afraid that the builtin flash memory is not good enough to have
leveling circuitry... Just in case, using async is good.

    Thanks for the advice :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: USB Storage speed regression since 2.6.12

[Bill Davidsen]

DervishD wrote:
>     Hi all :)
> 
>     I don't know if this is a known issue, but usb-storage speed for
> 'Full speed' devices dropped from 2.6.11.12 (more than 800Kb/s) to
> 2.6.12 (less than 250Kb/s). The problem still exists in 2.6.13.
> 
>     The lack of speed seems to affect only the OHCI driver. My test
> was done over a PCI USB 2.0 card, ALi chipset, OHCI driver (well
> EHCI+OHCI) and using a full speed device capable of 12MBps. The
> average measured speeds are:
> 
>     - 2.4.31:           about 450Kb/seg
>     - 2.6.11-Debian:    about 800Kb/seg
>     - 2.6.11.12:        about 820Kb/seg
>     - 2.6.12.x:         about 200Kb/seg
>     - 2.6.13:           about 200Kb/seg
> 
>     The .config is more or less the same in all kernels. I've took a
> look at the ChangeLog for 2.6.12 and there are lots of changes in the
> USB subsystem but I cannot identify which one could be the culprit.
> 
I see a worse problem, I load the driver, mount the filesystems on the 
USB 160GB disk, and the disk just "goes away." I see the devices in 
/proc/scsi/scsi but I can't access the devices any more. Definitely time 
for a fallback to a more stable kernel!

Re: USB Storage speed regression since 2.6.12

[Andrew Morton]

Bill Davidsen <davidsen@tmr.com> wrote:
>
> I see a worse problem, I load the driver, mount the filesystems on the 
> USB 160GB disk, and the disk just "goes away." I see the devices in 
> /proc/scsi/scsi but I can't access the devices any more. Definitely time 
> for a fallback to a more stable kernel!

Please us get 2.6.13 fixed first.  Can you generate the dmesg output for
good and bad kernels, diff them and see if there's anything useful there?

What does "can't access" mean?  -EIO?