Transfer packaging not using microframes #34

paamand · 2020-01-08T11:43:19Z

Making it very clear that the USB "frames" are in fact 1ms frames and not microframes.

Making it very clear that the "frames" are in fact 1ms frames and not microframes.

msftclas · 2020-01-08T11:43:32Z

All CLA requirements met.

GrantMeStrength · 2020-01-21T21:43:24Z

Hi Bill. Let me know if you can't OK this one.

PRMerger12 · 2020-01-22T02:25:30Z

@paamand : Thanks for your contribution! The author(s) have been notified to review your proposed change.

MartinBorveMicrosoft · 2020-02-11T02:00:04Z

sdk-api-src/content/winusb/nf-winusb-winusb_readisochpipe.md

 If the caller submits multiple read requests to stream data from the device, the transfer size should be a multiple of the maximum bytes per interval (as returned by <a href="https://docs.microsoft.com/windows/desktop/api/winusb/nf-winusb-winusb_querypipeex">WinUsb_QueryPipeEx</a>) * 8 / interval.


+Because of the transfer packaging, <b>only full 1ms USB frames are available</b> and low-latency applications requiring microframe transfers must use a kernel mode driver instead.


I'm not sure I understand this statement. Regardless of whether WinUsb or a kernel-mode driver is used, the underlying kernel-mode interface only allows isochronous transfers to be scheduled on a 1ms frame boundary. For high-speed/SuperSpeed devices which microframes are scheduled is determined by the interval of the endpoint.

Whether a developer needs to use a kernel-mode driver versus WinUSB for low-latency applications is determined by the latency between completion of the isoch transfer on the bus and when the driver or app is notified of that completion. It has nothing to do with frames versus micro-frames.

I agree with both statements. But the critical point here is that lowest latency notification of the driver/app is only done at the 1ms interval regardless of the bInterval of the endpoint. How about:

Suggested change

Because of the transfer packaging, only full 1ms USB frames are available and low-latency applications requiring microframe transfers must use a kernel mode driver instead.

Because of the transfer packaging used in the underlying kernel-mode interface, the lowest latency notification to an application or driver is 1ms intervals. This also applies to high-speed/SuperSpeed devices regardless of the interval specified by the endpoint. Applications requiring sub-millisecond latency must implement a custom kernel-mode driver.

I would only take the typo fixes for these changes. Discussion about the need for a user-mode app versus kernel-mode driver should not be part of the API documentation.

Maybe, but details about the imposed limitations of the implementation is definitely useful for anyone using the API in latency critical applications.

MartinBorveMicrosoft · 2020-02-11T19:39:42Z

sdk-api-src/content/winusb/nf-winusb-winusb_writeisochpipe.md

 If the caller submits multiple write requests to stream data to the device, the transfer size should be a multiple of the maximum bytes per interval (as returned by <a href="https://docs.microsoft.com/windows/desktop/api/winusb/nf-winusb-winusb_querypipeex">WinUsb_QueryPipeEx</a>) * 8 / interval.


+Because of the transfer packaging, <b>only full 1ms USB frames are available</b> and low-latency applications requiring microframe transfers must use a kernel mode driver instead.


See previous comment.

See comment to previous comment.

MartinBorveMicrosoft · 2020-02-11T19:39:53Z

sdk-api-src/content/winusb/nf-winusb-winusb_readisochpipeasap.md



-<b>WinUsb_ReadIsochPipeAsap</b> packetizes the transfer buffer so that in each interval,  the host can send the maximum bytes allowed per interval. The maximum bytes is as specified by the endpoint descriptor for full and high-speed endpoints, and endpoint companion descriptor for SuperSpeed endpoints.
+<b>WinUsb_ReadIsochPipeAsap</b> packetizes the transfer buffer so that in each 1ms interval,  the host can send the maximum bytes allowed per interval. The maximum bytes is as specified by the endpoint descriptor for full and high-speed endpoints, and endpoint companion descriptor for SuperSpeed endpoints.


Packetization is at the micro-frame (125us) level for high-speed/SuperSpeed endpoints, so saying "1ms interval" is not really accurate.

Should say the host can receive the maximum bytes allowed.

Agree that this is not accurate. Intention is to document the consequence of packetization for low-latency applications. This is done by the insertion at line 113. Remove this change.

True. Fixed in PR Fixed ambiguity of "read" vs "write". #33

Suggested change

WinUsb_ReadIsochPipeAsap packetizes the transfer buffer so that in each 1ms interval, the host can send the maximum bytes allowed per interval. The maximum bytes is as specified by the endpoint descriptor for full and high-speed endpoints, and endpoint companion descriptor for SuperSpeed endpoints.

WinUsb_ReadIsochPipeAsap packetizes the transfer buffer so that in each interval, the host can send the maximum bytes allowed per interval. The maximum bytes is as specified by the endpoint descriptor for full and high-speed endpoints, and endpoint companion descriptor for SuperSpeed endpoints.

sdk-api-src/content/winusb/nf-winusb-winusb_writeisochpipeasap.md

billlattimer

@paamand can you please amend your commit to include the just the correction lines? Thanks!

Trying to keep the amendment accurate and helpful for developers.

PRMerger15 · 2020-02-26T21:35:40Z

@paamand : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Trying to keep the amendment accurate and helpful for developers

PRMerger16 · 2020-02-26T21:40:22Z

@paamand : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Trying to keep the amendment accurate and helpful for developers

paamand · 2020-02-26T21:47:48Z

@paamand can you please amend your commit to include the just the correction lines? Thanks!

@billlattimer The minor typo corrections are fixed in PR #33. This is about clarifying the constraints of the packetization for low-latency applications. I've done my best to do this as accurate as possible. Updated with commits.

paamand added 4 commits January 8, 2020 12:29

Update nf-winusb-winusb_readisochpipeasap.md

1c0b1c3

Making it very clear that the "frames" are in fact 1ms frames and not microframes.

Update nf-winusb-winusb_writeisochpipe.md

1965b6e

Making it very clear that the "frames" are in fact 1ms frames and not microframes.

Update nf-winusb-winusb_writeisochpipeasap.md

f5aa6a9

Making it very clear that the "frames" are in fact 1ms frames and not microframes.

Update nf-winusb-winusb_readisochpipe.md

89b88ac

Making it very clear that the "frames" are in fact 1ms frames and not microframes.

PRMerger17 added the do-not-merge label Jan 8, 2020

PRMerger17 added the review-team-triage label Jan 8, 2020

kcpitt assigned GrantMeStrength Jan 13, 2020

GrantMeStrength assigned billlattimer Jan 21, 2020

GrantMeStrength removed their assignment Jan 21, 2020

PRMerger12 requested a review from GrantMeStrength January 22, 2020 02:25

PRMerger12 assigned GrantMeStrength Jan 22, 2020

PRMerger12 added desktop/prod sdk-api-reference/tech Change sent to author labels Jan 22, 2020

MartinBorveMicrosoft reviewed Feb 11, 2020

View reviewed changes

GrantMeStrength removed their assignment Feb 12, 2020

billlattimer reviewed Feb 26, 2020

View reviewed changes

Update nf-winusb-winusb_readisochpipe.md

d7487d4

Trying to keep the amendment accurate and helpful for developers.

PRMerger15 assigned GrantMeStrength Feb 26, 2020

paamand added 2 commits February 26, 2020 22:37

Update nf-winusb-winusb_readisochpipeasap.md

05450f9

Trying to keep the amendment accurate and helpful for developers

Update nf-winusb-winusb_writeisochpipe.md

58edf1d

Trying to keep the amendment accurate and helpful for developers

Update nf-winusb-winusb_writeisochpipeasap.md

793674c

Trying to keep the amendment accurate and helpful for developers

GrantMeStrength merged commit f3e1691 into MicrosoftDocs:docs Feb 27, 2020

paamand mentioned this pull request Jul 5, 2021

Winusb Isochronous Transfers not Working. libusb/libusb#541

Closed

		If the caller submits multiple read requests to stream data from the device, the transfer size should be a multiple of the maximum bytes per interval (as returned by <a href="https://docs.microsoft.com/windows/desktop/api/winusb/nf-winusb-winusb_querypipeex">WinUsb_QueryPipeEx</a>) * 8 / interval.


		Because of the transfer packaging, <b>only full 1ms USB frames are available</b> and low-latency applications requiring microframe transfers must use a kernel mode driver instead.

	Because of the transfer packaging, <b>only full 1ms USB frames are available</b> and low-latency applications requiring microframe transfers must use a kernel mode driver instead.
	Because of the transfer packaging used in the underlying kernel-mode interface, the lowest latency notification to an application or driver is 1ms intervals. This also applies to high-speed/SuperSpeed devices regardless of the interval specified by the endpoint. Applications requiring sub-millisecond latency must implement a custom kernel-mode driver.

		If the caller submits multiple write requests to stream data to the device, the transfer size should be a multiple of the maximum bytes per interval (as returned by <a href="https://docs.microsoft.com/windows/desktop/api/winusb/nf-winusb-winusb_querypipeex">WinUsb_QueryPipeEx</a>) * 8 / interval.


		Because of the transfer packaging, <b>only full 1ms USB frames are available</b> and low-latency applications requiring microframe transfers must use a kernel mode driver instead.



		<b>WinUsb_ReadIsochPipeAsap</b> packetizes the transfer buffer so that in each interval, the host can send the maximum bytes allowed per interval. The maximum bytes is as specified by the endpoint descriptor for full and high-speed endpoints, and endpoint companion descriptor for SuperSpeed endpoints.
		<b>WinUsb_ReadIsochPipeAsap</b> packetizes the transfer buffer so that in each 1ms interval, the host can send the maximum bytes allowed per interval. The maximum bytes is as specified by the endpoint descriptor for full and high-speed endpoints, and endpoint companion descriptor for SuperSpeed endpoints.

Transfer packaging not using microframes #34

Transfer packaging not using microframes #34

Uh oh!

Conversation

paamand commented Jan 8, 2020

Uh oh!

msftclas commented Jan 8, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GrantMeStrength commented Jan 21, 2020

Uh oh!

PRMerger12 commented Jan 22, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

billlattimer left a comment

Choose a reason for hiding this comment

Uh oh!

PRMerger15 commented Feb 26, 2020

Uh oh!

PRMerger16 commented Feb 26, 2020

Uh oh!

paamand commented Feb 26, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

msftclas commented Jan 8, 2020 •

edited

Loading