Skip to content
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

Closed
AndrewCapon opened this issue Sep 11, 2024 · 22 comments · Fixed by #192
Closed

ISO transfers all under single polling group. #186

AndrewCapon opened this issue Sep 11, 2024 · 22 comments · Fixed by #192
Labels

Comments

@AndrewCapon
Copy link

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?
Screenshot 2024-09-11 at 14 21 01

@martinling
Copy link
Member

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 unidentified.

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.

@AndrewCapon
Copy link
Author

Hi,

Thanks for the reply.

The device is being started after the capture has started though.

@martinling
Copy link
Member

Are you able to share a capture file?

@AndrewCapon
Copy link
Author

I can, just a sec...

@AndrewCapon
Copy link
Author

IsoOnly.pcap.zip

The bulk interfaces are not running here just the ISO.

@AndrewCapon
Copy link
Author

I also noticed not all the configurations are shown in the right pane, is this normal?

@AndrewCapon
Copy link
Author

AudioAndBulk.pcap.zip

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!

@martinling
Copy link
Member

The single configuration being shown seems correct to me. The device descriptor has bNumConfigurations set to 1, indicating that there's only one configuration, and the host only requests that one descriptor.

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.

@martinling martinling added the bug label Sep 11, 2024
@AndrewCapon
Copy link
Author

Sorry used wrong word, I meant Alternate. So interface 1 alternate 0, interface 1 alternate 1, interface 1 alternate 2.

@martinling
Copy link
Member

Yeah we may be doing something wrong there too. I'll take a look.

@AndrewCapon
Copy link
Author

Nice one, thanks very much.

@martinling
Copy link
Member

The issue with alternate interface settings is fixed in #189, which now includes a clip of your first capture as a test case.

image

@martinling
Copy link
Member

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.

@AndrewCapon
Copy link
Author

The issue with alternate interface settings is fixed in #189, which now includes a clip of your first capture as a test case.

image

That's great, thanks for that :)

@AndrewCapon
Copy link
Author

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.

Yeah. I see your point.

@martinling
Copy link
Member

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.

@AndrewCapon
Copy link
Author

Hi Martin,

Thanks very much for that.

So the iso transactions are not interspersed with say the bulk transactions?

Thanks

Andy

@martinling
Copy link
Member

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.

@AndrewCapon
Copy link
Author

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

@miek miek closed this as completed in #192 Sep 21, 2024
@martinling
Copy link
Member

Thanks for the info, I wondered why all the SOFs were grouped, the same reason?

Yes, SOFs are gathered at two levels:

  • Consecutive SOF packets on the wire, without other traffic in between are placed in a group equivalent to a transaction.
  • All SOF groups in the capture are themselves placed in a group equivalent to a transfer.

The benefit of this becomes more obvious in the transaction view, or the interleaved view:
image

@AndrewCapon
Copy link
Author

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 :)

@martinling
Copy link
Member

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants