Re: [linux-usb-devel] VIA and NEC EHCI

[David Brownell]

Jonathan Thorpe wrote:
> Greetings,

Thanks for the info ... the irq threshold experiment worked as I
had expected, although I hadn't noticed "hdparm" gave such low
numbers on 2.4 kernels. On 2.5 they can be more than four times
bigger, in part because usb-storage there uses urb queueing.


> After having a look, I came up with some surprising results. Without any
> log2_irq_thresh setting at all, I was able to keep the system stable
> enough (by not using the USB 2.0 storage device before the test) to get a
> reading from "hdparm -t /dev/sda":

Where "without setting" the module parameter means using the software's
default latency of 1 uframe.

> --
> /dev/sda:
> Timing buffered disk reads: 64 MB in 15.05 seconds = 4.25 MB/sec

Here's what I just measured, MB/sec from 'hdparm -tT' where the only
variables beyond boot sequence were "what EHCI is used":

EHCI Silicon 2.5.58 2.4.21-pre3
-------------------- ------ -----------
NEC 0.95 16.45 9.61
Philips ISP 1561 18.80 9.37
VT 6202 17.54 (hung)
VT 8235 (southbridge) 18.73 4.46

From which it seems clear that something is keeping the peak transfer rate
on the VIA chips well below what the others achieve on 2.4 ... as if for
some reason they need twice as many microframes to transfer the data. That
same "something" might couple to other problems, of course.

It's nice to have a quick demo of how Alan's usb_sg_*() changes win on 2.5;
note that the disk transfer speed is clearly an issue here.


> --
>
> With a setting of 1, I got:

That is, latency is 2 uframes ... remember that in 2 uframes, 13KB (peak)
can be transferred to a disk, but 2.4 usb-storage usually only manages
about one page (usually 4 KB) per IRQ.


> --
> /dev/sda:
> Timing buffered disk reads: 64 MB in 18.16 seconds = 3.52 MB/sec
> --
>
> A setting of 3 was slower yet, but I could use it for doing regular small
> file transfers without a hang (heavy loads would still hang):

That is, latency is 8 uframes == 1 frame; pretty much like OHCI or UHCI
except that, if the drivers don't queue urbs, you'd be wasting a lot
more bandwidth.

> --
> /dev/sda:
> Timing buffered disk reads: 64 MB in 40.21 seconds = 1.59 MB/sec
> --
>
> A setting of 5 wouldn't hang at all, no matter how much stress I tried to
> put on the device, but as you can see, the speeds are far below USB 1.1.

Setting it to 5 means delay of 2^5 = 32 uframes = 4 frames.

> --
> /dev/sda:
> Timing buffered disk reads: 64 MB in 119.39 seconds =548.92 kB/sec
> --

Increasing the latencies on 2.4 does show the expected drop in throughput.
On 2.5, where it's easier for drivers to queue urbs, the effect should be
a lot less pronounced in many loads (like this one).

The fact that you see a stability effect confirms my impression that
interrupt rates affect the hang.


I'll follow up on those PCI issues separately.

- Dave





-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel