Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

ehci-hcd affects hda speed

 

 

First page Previous page 1 2 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded


alessandro.suardi at gmail

Mar 20, 2008, 2:01 PM

Post #26 of 36 (2209 views)
Permalink
Re: ehci-hcd affects hda speed [In reply to]

On Thu, Mar 20, 2008 at 12:35 PM, Rene Herman <rene.herman [at] keyaccess> wrote:
> On 20-03-08 06:08, Alessandro Suardi wrote:
>
> > On Thu, Mar 20, 2008 at 1:31 AM, Rene Herman <rene.herman [at] keyaccess> wrote:
>
>
> >> I do wonder -- is your hda throughput also the same before _ever_ attaching
> >> anything to the EHCI controller and after? In my case, the slow down only
> >> happened after switching on my external USB drive once, and would persist
> >> from that time until reboot (or unloading ehci-hcd, which I kept modular for
> >> exactly that reason).
> >>
> >> The sleep time wasn't the core problem, so I wonder of later VIA chips do
> >> still have the active async schedule problem...
> >>
> >> Alessandro? You said there still was a difference for you between no EHCI at
> >> all and EHCI after tweaking 4B as Lev showed. How much?
> >
> > When used setpci to tweak the setting, my hdparm -t went
> > from 17 to 25MB/s on /dev/hda.
> >
> > With your patch applied, now after booting it says 33MB/s for
> > hda and 37MB/s on hdb (and I can burn DVDs at a stable 6x
> > now, while growisofs backed off to 4x in less than a minute
> > before the patch).
> >
> > If the patch does exactly what setpci did, then perhaps I had
> > other activity on hda at the moment I ran the test...
>
> Yes, should be the exact same. It could be what I noted -- that you have the
> 33/37 just after booting, and a drop to 25 again after having switched
> on/used a EHCI device for the first time? That would be interesting.
>
> Rene.

It just seems to be oscillating. The following is a series of
consecutive hdparm -t (when one is finished, I hit up-arrow
and then Enter again):

[root [at] donke ~]# hdparm -t /dev/hda

/dev/hda:
Timing buffered disk reads: 86 MB in 3.01 seconds = 28.57 MB/sec
[root [at] donke ~]# hdparm -t /dev/hda

/dev/hda:
Timing buffered disk reads: 88 MB in 3.00 seconds = 29.30 MB/sec
[root [at] donke ~]# hdparm -t /dev/hda

/dev/hda:
Timing buffered disk reads: 92 MB in 3.04 seconds = 30.31 MB/sec
[root [at] donke ~]# hdparm -t /dev/hda

/dev/hda:
Timing buffered disk reads: 88 MB in 3.05 seconds = 28.86 MB/sec
[root [at] donke ~]# hdparm -t /dev/hda

/dev/hda:
Timing buffered disk reads: 98 MB in 3.03 seconds = 32.38 MB/sec


hdb is definitely more stable...

[root [at] donke ~]# hdparm -t /dev/hdb

/dev/hdb:
Timing buffered disk reads: 108 MB in 3.02 seconds = 35.79 MB/sec
[root [at] donke ~]# hdparm -t /dev/hdb

/dev/hdb:
Timing buffered disk reads: 110 MB in 3.03 seconds = 36.36 MB/sec
[root [at] donke ~]# hdparm -t /dev/hdb

/dev/hdb:
Timing buffered disk reads: 110 MB in 3.04 seconds = 36.24 MB/sec
[root [at] donke ~]# hdparm -t /dev/hdb

/dev/hdb:
Timing buffered disk reads: 110 MB in 3.04 seconds = 36.24 MB/sec


Though I only have light activity on /dev/hda - four torrents
uploading at a cumulative 33KB/s via bittorrent-4.4.0-2
(and no activity on /dev/hdb).

/dev/sda, the USB external storage, is mounted but currently
not really accessed. However, the slowdown for me did
appear even modprob'ing ehci_hcd - without even mounting
/dev/sda.

Oh, now that you make me look... /dev/sda hdparm -t dropped
from 22MB/s to ~16MB/s - see my email of a while ago

http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-10/msg09679.html

versus the current

[root [at] donke ~]# hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 48 MB in 3.02 seconds = 15.90 MB/sec
[root [at] donke ~]# hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 48 MB in 3.02 seconds = 15.90 MB/sec

--alessandro

"We act as though comfort and luxury were the chief requirements
of life, when all that we need to make us really happy is
something to be enthusiastic about."

(Charles Kingsley)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


melnikovsky at mail

Apr 15, 2008, 12:56 PM

Post #27 of 36 (2206 views)
Permalink
Re: ehci-hcd affects hda speed [In reply to]

hi,

Sorry, I had virtually no time to answer earlier. If (hopefully) someone
is still interested, here's my feedback

On Thu, 20 Mar 2008 at 3:50am, Rene Herman wrote:

RH> I do wonder -- is your hda throughput also the same before _ever_
RH> attaching anything to the EHCI controller and after? In my case, the
RH> slow down only happened after switching on my external USB drive once,
RH> and would persist from that time until reboot (or unloading ehci-hcd,
RH> which I kept modular for exactly that reason).
I have repeated experiments with P3B-F and VT6212L combination (to
improve visibility the AsyncSchedSleepTime is set to 1us):

#0. Nothing is connected to USB, no ehci-hcd loaded
hda throughput 28+-1MB/s

#1. ehci-hcd loaded, still no USB peripherals
hda throughput 28+-1 MB/s

#2. Something (USB hub and FLASH drive tested) is attached
hda throughput 15+-1 MB/s

#3. All USB peripherals are removed
hda throughput 15+-1 MB/s

#4. ehci-hcd is rmmod'ed
hda throughput 28+-1MB/s

The oddest peculiarity for me is the hysteretic difference between #1 and
#3 states. I mean experimental data (hda throughput) depends not on the
state (hardware/loaded modules), but on the path we followed.

Interestingly enough, sampling registers (via /sys) often shows Async bit
set of the status register in the state #3. It is always cleared in #1.
The async file is empty in both states. I wonder, how many degrees of
freedom does an empty schedule have? Does "empty" mean "has no incomplete
requests" or "has no requests at all"? Just guessing...

RH> The sleep time wasn't the core problem, so I wonder of later VIA chips do
RH> still have the active async schedule problem...
I don't think this is purely VIA problem. I did not _try_ to install that
VT6212L card into newer motherboard, but my _feeling_ is that we see an
"incompatibility" between older PCI mobo chipsets and VIA USB controller.
Actually, taking into account superior PCI bandwidth of modern PCs (if
compared with my old P3B-F motherboard) I am not sure we can perform a
clean reliable test without PCI bus analyzer.

-l
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


oliver at neukum

Apr 15, 2008, 1:02 PM

Post #28 of 36 (2201 views)
Permalink
Re: ehci-hcd affects hda speed [In reply to]

Am Dienstag, 15. April 2008 21:56:24 schrieb Lev A. Melnikovsky:
> The oddest peculiarity for me is the hysteretic difference between #1 and
> #3 states. I mean experimental data (hda throughput) depends not on the
> state (hardware/loaded modules), but on the path we followed.

Did you compile with CONFIG_USB_SUSPEND?

Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rene.herman at keyaccess

Apr 15, 2008, 1:24 PM

Post #29 of 36 (2202 views)
Permalink
Re: ehci-hcd affects hda speed [In reply to]

On 15-04-08 21:56, Lev A. Melnikovsky wrote:

> Sorry, I had virtually no time to answer earlier. If (hopefully) someone
> is still interested, here's my feedback

Interested yes, although being no longer in posession of the hardware it's a
somewhat academic interest...

> I have repeated experiments with P3B-F and VT6212L combination (to
> improve visibility the AsyncSchedSleepTime is set to 1us):
>
> #0. Nothing is connected to USB, no ehci-hcd loaded
> hda throughput 28+-1MB/s
>
> #1. ehci-hcd loaded, still no USB peripherals
> hda throughput 28+-1 MB/s
>
> #2. Something (USB hub and FLASH drive tested) is attached
> hda throughput 15+-1 MB/s
>
> #3. All USB peripherals are removed
> hda throughput 15+-1 MB/s
>
> #4. ehci-hcd is rmmod'ed
> hda throughput 28+-1MB/s
>
> The oddest peculiarity for me is the hysteretic difference between #1 and
> #3 states. I mean experimental data (hda throughput) depends not on the
> state (hardware/loaded modules), but on the path we followed.

On the chip having inited itself at least. Yes, your results match what I
experienced.

> Interestingly enough, sampling registers (via /sys) often shows Async bit
> set of the status register in the state #3. It is always cleared in #1.
> The async file is empty in both states. I wonder, how many degrees of
> freedom does an empty schedule have? Does "empty" mean "has no incomplete
> requests" or "has no requests at all"? Just guessing...

Should leave this up to David, but as far as I'm aware "no at all".

> RH> The sleep time wasn't the core problem, so I wonder of later VIA chips do
> RH> still have the active async schedule problem...
> I don't think this is purely VIA problem. I did not _try_ to install that
> VT6212L card into newer motherboard, but my _feeling_ is that we see an
> "incompatibility" between older PCI mobo chipsets and VIA USB controller.

I very much doubt that. Can't really imagine an off-silicon reason the chip
would keep scanning the async schedule. I'm also now using a NEC controller
card in that same machine and it also shows no problems.

> Actually, taking into account superior PCI bandwidth of modern PCs (if
> compared with my old P3B-F motherboard) I am not sure we can perform a
> clean reliable test without PCI bus analyzer.

http://lkml.org/lkml/2005/5/30/259

>
> -l
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rene.herman at keyaccess

Apr 15, 2008, 1:32 PM

Post #30 of 36 (2199 views)
Permalink
Re: ehci-hcd affects hda speed [In reply to]

On 15-04-08 21:56, Lev A. Melnikovsky wrote:

[ sorry, hit send prematurely by accident ]

> Sorry, I had virtually no time to answer earlier. If (hopefully) someone
> is still interested, here's my feedback

Interested yes, although being no longer in posession of the hardware it's a
somewhat academic interest...

> I have repeated experiments with P3B-F and VT6212L combination (to
> improve visibility the AsyncSchedSleepTime is set to 1us):
>
> #0. Nothing is connected to USB, no ehci-hcd loaded
> hda throughput 28+-1MB/s
>
> #1. ehci-hcd loaded, still no USB peripherals
> hda throughput 28+-1 MB/s
>
> #2. Something (USB hub and FLASH drive tested) is attached
> hda throughput 15+-1 MB/s
>
> #3. All USB peripherals are removed
> hda throughput 15+-1 MB/s
>
> #4. ehci-hcd is rmmod'ed
> hda throughput 28+-1MB/s
>
> The oddest peculiarity for me is the hysteretic difference between #1 and
> #3 states. I mean experimental data (hda throughput) depends not on the
> state (hardware/loaded modules), but on the path we followed.

On the chip having inited itself at least. Yes, your results match what I
experienced precisely.

> Interestingly enough, sampling registers (via /sys) often shows Async bit
> set of the status register in the state #3. It is always cleared in #1.
> The async file is empty in both states. I wonder, how many degrees of
> freedom does an empty schedule have? Does "empty" mean "has no incomplete
> requests" or "has no requests at all"? Just guessing...

Should leave this up to David, but as far as I'm aware "no at all".

> RH> The sleep time wasn't the core problem, so I wonder of later VIA chips do
> RH> still have the active async schedule problem...
> I don't think this is purely VIA problem. I did not _try_ to install that
> VT6212L card into newer motherboard, but my _feeling_ is that we see an
> "incompatibility" between older PCI mobo chipsets and VIA USB controller.

I very much doubt that. Can't really imagine an off-silicon reason the chip
would keep scanning the async schedule. I'm also now using a NEC controller
card in that same machine and it shows no problems.

> Actually, taking into account superior PCI bandwidth of modern PCs (if
> compared with my old P3B-F motherboard) I am not sure we can perform a
> clean reliable test without PCI bus analyzer.

In my original thread on the issue:

http://lkml.org/lkml/2005/5/30/259

there's was some indication that a rev 0x86 VIA (more modern) does something
similar due to Grant Coady in there also being able to see the Async bit on
at all while looking at it so while throughput may not be hindered much, the
issue could probably still be debugged/seen on newer (VIA) hardware by
examing that state file.

You are probably by now one of the best positioned users to debug the issue
though with a VT2612 in an older machine so perhaps you can work with David
Brownell to perhaps for once and all confirm that it's just unfixable VIA
silicon or something which can be helped. As indicated, I just gave up on
the bloody controller :-)

Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


melnikovsky at mail

Apr 15, 2008, 1:41 PM

Post #31 of 36 (2204 views)
Permalink
Re: ehci-hcd affects hda speed [In reply to]

On Wed, 16 Apr 2008 at 12:02am, Oliver Neukum wrote:

ON> Am Dienstag, 15. April 2008 21:56:24 schrieb Lev A. Melnikovsky:
ON> > The oddest peculiarity for me is the hysteretic difference between #1 and
ON> > #3 states. I mean experimental data (hda throughput) depends not on the
ON> > state (hardware/loaded modules), but on the path we followed.
ON>
ON> Did you compile with CONFIG_USB_SUSPEND?

# CONFIG_USB_SUSPEND is not set

Does this explain something?

Thanks
-L
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


david-b at pacbell

Apr 15, 2008, 4:17 PM

Post #32 of 36 (2193 views)
Permalink
Re: ehci-hcd affects hda speed [In reply to]

On Tuesday 15 April 2008, Lev A. Melnikovsky wrote:

> I have repeated experiments with P3B-F and VT6212L combination (to
> improve visibility the AsyncSchedSleepTime is set to 1us):

Which you *know* is aggravating the problem. What numbers
do you observe with a generic 2.6.25-rc9 kernel? (That is,
without that abusive 1 usec setting ... that kernel includes
the patch switching to a more customary 10 usec value.)


> The oddest peculiarity for me is the hysteretic difference between #1 and
> #3 states. I mean experimental data (hda throughput) depends not on the
> state (hardware/loaded modules), but on the path we followed.
>
> Interestingly enough, sampling registers (via /sys) often shows Async bit
> set of the status register in the state #3. It is always cleared in #1.

With 2.6.25-rc9's default setting for async sleep time?


> The async file is empty in both states. I wonder, how many degrees of
> freedom does an empty schedule have? Does "empty" mean "has no incomplete
> requests" or "has no requests at all"? Just guessing...

Means "none at all". So if the "Async" status bit is set
while the "Async" command is clear, it means the hardware
is clearly misbehaving. That status bit is supposed to
turn itself off after the command bit is cleared ... within
a couple milliseconds.


> I don't think this is purely VIA problem.

We've certainly seen enough "purely on VIA hardware" issues
though; and I don't recall evidence showing this is NOT
another one of those. Example, that bogus 1 usec default...

One hopes that when http://linux.via.com.tw finally appears,
it will include errata for all relevant chipsets.

- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


oliver at neukum

Apr 15, 2008, 10:38 PM

Post #33 of 36 (2213 views)
Permalink
Re: ehci-hcd affects hda speed [In reply to]

Am Dienstag, 15. April 2008 22:41:19 schrieb Lev A. Melnikovsky:
>
> On Wed, 16 Apr 2008 at 12:02am, Oliver Neukum wrote:
>
> ON> Am Dienstag, 15. April 2008 21:56:24 schrieb Lev A. Melnikovsky:
> ON> > The oddest peculiarity for me is the hysteretic difference between #1 and
> ON> > #3 states. I mean experimental data (hda throughput) depends not on the
> ON> > state (hardware/loaded modules), but on the path we followed.
> ON>
> ON> Did you compile with CONFIG_USB_SUSPEND?
>
> # CONFIG_USB_SUSPEND is not set
>
> Does this explain something?

EHCI should not scan an empty async. However this manufacturer
has shown a liberal attitude about conforming with specifications.
If the root hub is suspended, it can't do DMA. So it might help.

Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


melnikovsky at mail

Apr 16, 2008, 3:23 PM

Post #34 of 36 (2196 views)
Permalink
Re: ehci-hcd affects hda speed [In reply to]

Oliver,

ON> EHCI should not scan an empty async. However this manufacturer
ON> has shown a liberal attitude about conforming with specifications.
ON> If the root hub is suspended, it can't do DMA. So it might help.
Yes, it does, thank you. No DMA when suspended. Auto-suspend is executed
if external hub is the only attached device. Can this be used to block
spurious schedule traversal?

Thnks
-L
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


melnikovsky at mail

Apr 16, 2008, 3:44 PM

Post #35 of 36 (2208 views)
Permalink
Re: ehci-hcd affects hda speed [In reply to]

On Wed, 16 Apr 2008 at 3:17am, David Brownell wrote:

DB> Which you *know* is aggravating the problem. What numbers
DB> do you observe with a generic 2.6.25-rc9 kernel? (That is,
DB> without that abusive 1 usec setting ... that kernel includes
DB> the patch switching to a more customary 10 usec value.)
~29.5 MB/s with ehci_hcd unloaded,
~26.0 MB/s with ehci_hcd loaded + USB hub is connected

The machine is mostly idle.

LM> hda throughput 28+-1MB/s
LM> #1. ehci-hcd loaded, still no USB peripherals
LM> hda throughput 28+-1 MB/s
LM> #2. Something (USB hub and FLASH drive tested) is attached
LM> hda throughput 15+-1 MB/s
LM> #3. All USB peripherals are removed
LM> hda throughput 15+-1 MB/s
LM> #4. ehci-hcd is rmmod'ed
LM> hda throughput 28+-1MB/s
DB> > The oddest peculiarity for me is the hysteretic difference between #1 and
DB> > #3 states. I mean experimental data (hda throughput) depends not on the
DB> > state (hardware/loaded modules), but on the path we followed.
DB> >
DB> > Interestingly enough, sampling registers (via /sys) often shows Async bit
DB> > set of the status register in the state #3. It is always cleared in #1.
DB>
DB> With 2.6.25-rc9's default setting for async sleep time?
Yes. Async bit is oscillating and the frequency I see it set is much lower
than that with 1us sleep time, but it is possible to catch the bit set
high anyway. Here's one sample:

$ cat /sys/class/usb_host/usb_host4/registers

bus pci, device 0000:00:09.2 (driver 10 Dec 2004)
EHCI Host Controller
EHCI 1.00, hcd state 1
ownership 00000001
SMI sts/enable 0xc0080000
structural params 0x00002204
capability params 0x00006872
status a008 Async Recl FLR
command 010009 (park)=0 ithresh=1 period=256 RUN
intrenable 37 IAA FATAL PCD ERR INT
uframe 28e0
port 1 status 001000 POWER sig=se0
port 2 status 001000 POWER sig=se0
port 3 status 001000 POWER sig=se0
port 4 status 001000 POWER sig=se0
irq normal 18 err 0 reclaim 4 (lost 0)
complete 18 unlink 1

DB> Means "none at all". So if the "Async" status bit is set
DB> while the "Async" command is clear, it means the hardware
DB> is clearly misbehaving. That status bit is supposed to
DB> turn itself off after the command bit is cleared ... within
DB> a couple milliseconds.
Yes, I understand that, but... I am not going to defend VIA, the chip does
misbehave. I just wonder what is the difference between the states #1 and
#3? Command register is the same, hardware is the same. If we know the
difference, can we benefit from our understanding?

Namely: is it possible that an (empty) schedule is different?

DB> One hopes that when http://linux.via.com.tw finally appears,
OK, two hope :-)

-L
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


oliver at neukum

Apr 17, 2008, 1:20 AM

Post #36 of 36 (2199 views)
Permalink
Re: ehci-hcd affects hda speed [In reply to]

Am Donnerstag, 17. April 2008 00:23:08 schrieb Lev A. Melnikovsky:
> Oliver,
>
> ON> EHCI should not scan an empty async. However this manufacturer
> ON> has shown a liberal attitude about conforming with specifications.
> ON> If the root hub is suspended, it can't do DMA. So it might help.
> Yes, it does, thank you. No DMA when suspended. Auto-suspend is executed
> if external hub is the only attached device. Can this be used to block
> spurious schedule traversal?

Obviously, yes, if only hubs are attached. The question is whether it
should be. It would be better to find a way to fix the chip bug in the active
state. However, as fixing all hardware bugs for that vendor may be difficult
I wanted to test whether a partial work around is available.

Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

First page Previous page 1 2 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.