Thank you very much for the very detailed description of the problem.
On Tue, Apr 24, 2001, Martin Diehl <[EMAIL PROTECTED]> wrote:
> At a first glance, this seems to be a minor issue. Nevertheless it
> deserves some explanation. OTOH I would not be completely surprised to
> find the reason behind might also have some impact on iso transfers, for
> which some uhci.c related problems have been reported.
I would. The way UHCI works, Isochronous transfers are quite a bit
different than all other transfers.
> t1: before calling usb_submit_urb() until return from that call
> t2: from return from usb_submit_urb() until first data packet transfered
> t3: between sending first and last packet on the device side
> t4: from device sending last packet until completion handler called
> t5: from completion handler until sleeping process awoken
> T: sum of t1..t5, i.e. from usb_submit_urb() until process wakeup
>
> The observed average values (msec) for 64kB transfer to unloaded host:
>
> t1 t2 t3 t4 t5 T
> usb-ohci 0.9 0.2 56 1 0 58
> usb-uhci 3.1 1 59 3 1 67
> uhci 1.9 1 60 5 0 68
>
> So, in the average there is nothing wrong with all this. OHCI is pretty
> close to the theoretical optimum (1.13MB/sec compared to 1.2 - queueing
> should get close to 1.17) and UHCI (both) somewhat behind.
> [I'm not trying to comment on the apparent shift of about 2msec from
> submit to completion position when comparing both uhci-flavours - but it
> is definitely significant from the statistics]
> Looking at a "normal" transfer, the 1msec frame was well filled with
> typically 16 data-packets placed after the SOF-packet in every frame
> for the whole transfer (typically, because usb-uhci sometimes decided to
> put a 17th data-packet into the not so small idle-gap at the end of the
> frame).
> Remark: when talking about data-packet I mean the complete interaction,
> i.e. the token packet from host to device, the data payload packet from
> the device and the handshake packet returned by the host.
UHCI doesn't necessarily allow you to specify which packets are sent
when, so the 17th data packet you saw is a result of the UHCI controller
deciding that there was enough time to send another packet.
> For the strange "long" transfers of uhci the following happens:
>
> At some instant _during_ the running transfer the data-packet arrangement
> switches from 16-per-frame to 1-per frame. Apparently this never happens
> within the first 40kB or so - that's why you need at least about 50KB
> transfer size to detect this! If it happens, the remaining 10..20kB are
> transfered using only about 1/16 of the bus time.
>
> Although it's pretty hard to do with the scope, I've managed to catch some
> of these alone-in-frame packets. There's nothing wrong with them. They are
> properly ACK'ed by the host well in time (16-18 bit bus turnaround time).
> There is no IN token following. Seems the host for some unknown reason
> decides not to want more than one packet per frame.
This sounds like uhci.c turned off full speed bandwidth reclamation as a
result of a timeout of some sort. From your description, it sounds like
it's a bug in my driver.
This would definately make sense given your example.
> Hopefully, this detailed description might help somebody who has a good
> understanding of the internal details for both UHCI HC's to get some idea
> what might happen for uhci but not for usb-uhci. For me, the described
> behavior is no problem at all. But, if similar dropouts would happen for
> iso-transfer it might cause some trouble rather easy.
Isochronous transfers are scheduled seperately and are not subject to
full speed bandwidth reclamation.
> One idea I have is based on the "usb-uhci sometimes uses 17 data-packets
> per frame" observation. This works fine for usb-uhci. For uhci however
> I've never seen this on the wire. Simply looking at the bus-idle intervall
> at the end of each frame, my conclusion is, 17 packets should be possible
> for every frame - with still about 2-3 usec left. Don't know, why usb-uhci
> does only occasionally picks this up. Well, I'm blindly guessing, but it
> might be possible the "long" transfers for uhci are exactly those which
> are scheduled 17/frame for usb-uhci. Some kind of "frame almost exactly
> filled" bandwith grant situation in combination with bit-stuffing? (the 64
> byte data packets are all always identical except for the first 4 bytes
> containing the (u32) current frame number when the device loads the data
> into the buffer - so most packets will not need bit-stuffing - except
> every now and then when the frame numbers contains at least 6
> consequetive "1" bits.)
I'm surprised that the same didn't happen with uhci. Since we have no
control over exactly how many packets get sent per frame, I would expect
the UHCI controller to do the same for both drivers.
Or it may be just a fluke.
> Needless to say, I'm willing to do further testing or provide more
> information if it might help!
If you're comfortable with C, you can find the full speed bandwidth
reclamation code and play with it. You can remove the timeout code, or
you can force it to use FSBR all of the time.
The code is there so the UHCI controller doesn't eat up all of the PCI
bandwidth spinning on the schedule when it really doesn't need to.
JE
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
