SpeedTouch and ISO mode, stats, ADSL Max.
baldrick at free.fr
Tue Mar 21 08:58:13 EST 2006
> Alistair Strachan did report the same thing in January, archived at
Oops, forgot about that. Anyway, let's suppose for the sake of argument
that the slowness is due to the driver.
Last time I profiled it, almost all of the time was being spent in the
uhci code, allocating transfer descriptors (TDs). Since the number of
TDs is proportional to the size of the receive buffer, having large
receive buffers of which only a fraction is ever used could represent
a significant waste of time. I'm talking about bulk here - this was
before iso was implemented.
Another possibility is that using a tasklet to process received urbs
was a bad idea: too slow. Sounds unlikely to me, maybe you have some
insight? In order to determine this, what I really need is a way in the
kernel to measure the wall-time between being at point A in the code, and
being at point B, where the time difference is small (this makes using
jiffies problematic). That way I can measure eg: the time between
scheduling the tasklet and when it is actually run. Any suggestions?
Otherwise, it's a matter of collecting statistics about the sizes of
packets, urb utilisation etc in the hope of getting some insight...
More information about the Usbatm