On Thu, 10 Nov 2005, Neil Brown wrote: > It cannot be a page-feed thing, as the file is one page, and the page > doesn't come out until after the 'dd' completes.
Then do you have any idea what the 20-second delay could be? Does the printer have to warm up? > Also when using ehci, it all flows much faster, so the problem cannot > be that the printer is slow. Maybe not the printer controller, but the USB interface could be slow. Or its full-speed implementation could be slow. > I read a bit about UHCI, and decided to try a dd with 512 byte writes > as each one of those would fit easily into a 1ms frame (assuming usblp > doesn't merge multiple writes to fill frames), I then extracted the > time between 'S' and 'C' (Start and Complete??) for each packet listed > by usbmon, and graphed this. The graph (attached) has a very strong > artifact. > I set the ytics to every 112msecs (because that seemed to be the right > number, somewhere between 111 and 112 I think) and the vast majority > of times lie very close to these grid lines. > If I sort the times, you can see that about 1/4 did not suffer any > 112msec delay. (second graph). > > If I zoom into just these, we see they mostly took 3ms, with 4ms, 5ms, > and even 6ms being not uncommon (third graph). Presumably the ms > grading is due to the uhci frame rate, but does anyone have any > guesses what the 112msec (0x70) grading could relate to? No idea. If it's not something in the printer then it's a bug in your USB controller. > Also, could you help me understand how flow-control works? I'm > guessing from what I read that the uhci just resends a packet every > millisec (assuming there are no other devices to serve) until it gets > an appropriate ACK - is that correct? If you have NO_FSBR set, that's correct. If you don't have NO_FSBR set, the controller resends the packet more or less continually until it receives an ACK. > If what, what would be the easiest way to instrument the kernel to > confirm that a packet really was going every msec? This information is not available to the kernel. You would need to get a USB protocol analyzer, a hardware device that monitors the signals on the USB cable. Alan Stern ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
