Oliver Neukum writes:
>The generic driver uses a buffer of this size for convinience"s sake.
>Increasing buffer size will increase throughput at the expense of 
latency.
>A proper fix would be to use multibuffer techniques. Do you have a card
>and are interested in testing?

Oliver, I have a Novatel V620 in an EV-DO area, and I can replicate the 
current failure at-will. (Actually, any "speed test" Web site does the 
trick.)  I'm intrigued by your thoughts concerning multi-buffering.  What 
did you have in mind (from a code point of view)?

FWIW, I disagree with Hoang Tran's patch's use of "int" as the data type 
for the "maxSize" parameter.  It really ought to be __u16, shouldn't it? 
Also, I think "maxSize" is probably a bad name (too generic) and would 
prefer something like "pktsize" if we go the parameter route.  However, it 
sounds like we're headed in a different direction altogether, so I'm all 
ears.

- - - - -
Timothy F. Sipples
Consulting Software Architect, Enterprise Transformation
IBM Americas zSeries Software
NEW Phone: +1 312 529 1612 (effective 1 September 2005)
E-Mail: [EMAIL PROTECTED] (PGP key available.)


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to