On Wed, 4 Oct 2006 [EMAIL PROTECTED] wrote:
> > In ALL of the control transfers that I looked at, the time difference
> > between the SETUP packet and the first IN or OUT packet was never more
> > than 5 or 6 microseconds. The time difference between the ACK of the
> > SETUP and the first IN/OUT is around 2 or 3 microseconds. That's true
> for
> > the Windows trace as well.
>
> I was talking about transactions, not packets.
That's not a good way to talk. Transactions are made up of up to 3
packets, so they don't have definite times. Or at least, not as definite.
> Let me give you a quick
> example to make sure we're talking about the same thing:
>
> luvcview-error-32-on-set-cur:
Right.
> The failed SetCur at 7.126
I don't know what's going on, but your timestamps don't agree with the
ones I see. On my system, that file begins at time 3.314 with normal
device initialization, proceeding through SetConfig at 4.069 and SetCur,
GetDef, SetCur, and IN ending at 4.158. There there is a whole bunch of
appended data which starts at 7.270. The failed SetCur is near the end at
10.804.
> has 479 microseconds between the SETUP
> transaction and the OUT transaction (with plenty of PINGs in between).
Um, no. There is 479 us between the SETUP and the final failed OUT. But
here's what actually happens:
SETUP 10.804 455 550
DATA0 455 983
ACK 456 467
OUT 10.804 459 400
DATA1 459 833
NAK 460 800
... Lots of PINGs. Some get NAK. Some get ACK, after which
the host sends OUT, DATA1, and the device replies NAK...
Eventually the transfer fails with this transaction:
OUT 10.804 934 500
DATA1 934 917
STALL 935 883
As you can see, there is a gap of only 3.85 us between the SETUP packet
and the first OUT packet (only 2.933 us between the ACK and the first
OUT).
> The
> successful SetCur right before it, at 7.104, has 866 microseconds between
> the same transactions (with more PINGs in between).
On my system there is a successful SetCur 22 ms before the failed one.
Presumably that's the one you're talking about. The timing between the
SETUP transaction and the first OUT transaction is similar to the timing
above. The interval between the SETUP and the _last_ OUT is 866 us.
> What controls this difference in timing? From my understanding of the
> earlier messages in this thread, this is the EHCI controller and cannot
> directly be influenced by the kernel, right?
No. The timing you're worried about, i.e., the time between the SETUP
transaction and the failed OUT transaction, is determined by when the
STALL is received. And it's the device that sends the STALL.
In short, the timing is controller by the device, not the EHCI controller,
and it cannot directly be influenced by the kernel.
> > Quoting from the USB 2.0 spec:
> >
> > ---------------------------------------------------------------------
> >
> > 8.5.1.1 NAK Responses to OUT/DATA During PING Protocol
> >
> > The endpoint may also respond to the OUT/DATA transaction with a NAK
> > handshake. This means that the endpoint did not accept the data and does
> > not have space for a wMaxPacketSize data payload at this time. The host
> > controller must return to using a PING token until the endpoint indicates
> > it has space. A NAK response is expected to be an unusual occurrence. A
> > high-speed bulk/control endpoint must specify its maximum NAK rate in its
> > endpoint descriptor. The endpoint is allowed to NAK at most one time each
> > bInterval period. A NAK suggests that the endpoint responded to a
> previous
> > OUT or PING with an inappropriate handshake, or that the endpoint
> > transitioned into a state where it (temporarily) could not accept data.
> An
> > endpoint can use a bInterval of zero to indicate that it never NAKs. An
> > endpoint must always be able to accept a PING from the host, even if it
> > never NAKs.
> >
> > ---------------------------------------------------------------------
> >
> > I'd say you just barely squeak by. If there were an endpoint descriptor
> > for endpoint 0, the device's NAK rate would certainly the descriptor's
> > limit, since the maximum allowed rate is 1 NAK per microframe. In any
> > case it's clear that the device's behavior doesn't comply with the intent
> > of the spec; it's not an "unusual occurrence".
>
> But you're talking about NAKs here, whereas the control requests in
> questions only shows PINGs that are responded with ACKs.
Not true at all. They show lots (hundreds or maybe thousands) of PINGs.
I didn't count them, but maybe 1/3 are responded with ACKs.
> > After a quick look, I didn't notice any particular difference in timing
> of
> > the control transfers under Linux and under Windows.
>
> If you look at the same delay between SETUP and OUT _transactions_, you'll
> see that under Windows it takes longer than 500 microseconds, sometimes
> even more than a millisecond.
No, it's not Windows which takes that time. It's the device.
And it's not OUT _transactions_, either. The trace shows hundreds of OUT
transactions in the control transfer. You're looking at only the _last_
one.
> > Exactly what are the conditions under which you expect the device to mess
>
> > up the protocol?
>
> I'm not sure I understand your question. What do you mean by "mess up the
> protocol"?
Respond with STALL when it should respond with ACK. Or as you mentioned
earlier, drop or lose an interrupt.
Alan Stern
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
