On Tuesday November 8, [EMAIL PROTECTED] wrote: > On Tue, 8 Nov 2005 14:11:12 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote: > > > > If you start experimenting, try to set the NO_FSBR flag in usblp.c > > > to writeurb->transfer_flags. > > > > Good Lord, no, don't do that! With NO_FSBR set, the maximum theoretical > > transfer rate is 64 bytes/ms. If you leave it unset, the maximum > > theoretical transfer rate is 1216 bytes/ms. > > Correct, and I am aware. However, Neil is getting less bandwidth, which > is why I suggested it. > > > c7e12500 2264943987 S Bo:002:01 -115 8192 = 1b252d31 32333435 5840504a > > 4c205345 54205041 47455052 4f544543 543d4155 > > c7e12500 2284767551 C Bo:002:01 0 8192 > > > > > 8192 byte bulk-out transfer. At the maximum theoretical rate, it should > > take about 7 ms. In fact it took 20 seconds! You can't blame that on the > > USB controller. > > Yep, I saw a few of the same hiccups down below too. > However, it may be just how much it takes for this thing to feed > a page of paper.
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. Also when using ehci, it all flows much faster, so the problem cannot be that the printer is 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? 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 what, what would be the easiest way to instrument the kernel to confirm that a packet really was going every msec? Thanks in advance, NeilBrown
