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