-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ISO transfers all under single polling group. #186
Comments
This happens because the enumeration process wasn't captured, so Packetry hasn't seen the configuration descriptor request, which would include the endpoint descriptors in the response. Without seeing the endpoint descriptors, Packetry doesn't know what the type of endpoint 2 is, so it describes transfers made on it as If you start the capture before you connect the device, you should get the descriptor tree in the devices pane, and these transfers should then be correctly identified. |
Hi, Thanks for the reply. The device is being started after the capture has started though. |
Are you able to share a capture file? |
I can, just a sec... |
The bulk interfaces are not running here just the ISO. |
I also noticed not all the configurations are shown in the right pane, is this normal? |
Both bulk and audio running, I can't even see the audio transfers in this one. This could all be silly user error as I just got the thing! |
The single configuration being shown seems correct to me. The device descriptor has The thing with isochronous transactions being shown in polling groups is a bug, though. I think the state machine is wrong here and it's expecting an ACK, which it shouldn't do in the isochronous case. I'll see about a fix. |
Sorry used wrong word, I meant Alternate. So interface 1 alternate 0, interface 1 alternate 1, interface 1 alternate 2. |
Yeah we may be doing something wrong there too. I'll take a look. |
Nice one, thanks very much. |
The issue with alternate interface settings is fixed in #189, which now includes a clip of your first capture as a test case. |
I have some work in progress on fixing the isochronous transfers too, but that's going to take a bit longer to get right. One of the more tricky issues involved is that in the case where we haven't seen the endpoint descriptors, a transaction with just IN or OUT followed by DATA0 or DATA1 is ambiguous. It could be a successful isochronous transaction, but it could also be an incomplete bulk/interrupt transaction that wasn't ACKed or NAKed by the host when it should have been. |
That's great, thanks for that :) |
Yeah. I see your point. |
The issues with handling isochronous transactions are fixed in #192, which I'd appreciate your review on. I think that your two captures shared above are now interpreted correctly. Note though that the result is not all that different - the isochronous transactions on each endpoint are still placed in one group, but that group is now labelled as an isochronous transfer rather than as a polling group. |
Hi Martin, Thanks very much for that. So the iso transactions are not interspersed with say the bulk transactions? Thanks Andy |
In Packetry transactions are always grouped into transfers. If you want a transaction-by-transaction level view, that's available in PR #145, but that's not merged yet as it needs some further work on integrating selection and scrolling between the multiple views. The other work you might be interested in is the interleaved view in PR #150, which will let you expand two transfers and look at how their transactions are interleaved in time. |
Hi Martin, Thanks for the info, I wondered why all the SOFs were grouped, the same reason? Looks like I am probably after the transaction or packet view. I have gone back to using my old analyser, I will build and try your new version when I get a chance... Thanks Andy |
Sorry, I have been meaning to post here to say thanks for all the updates you have done. Packetry is so much more useful for me now. Nice job :) |
Thanks! |
So I can see the order of my bulk transfers, the polling and then the "Unidentified transfer".
All my ISO packets though are contained in single "Polling" groups so I get something like : "Polling 89064 times for unidentified transfer on endpoint 36.3 OUT" and "Polling 89064 times for unidentified transfer on endpoint 36.3 IN".
If I expand the groups I see the transactions.
Why are these not displayed with the other transfers?
The text was updated successfully, but these errors were encountered: