access.direct.demultiplexer: add ability for applets to override default USB transfer settings.

[Sazzach]

The first commit in this PR adds a way for an applet to override the default USB transfer size / the number of transfers queued on a DirectDemultiplexerInterface at a time.

The motivation for this change is that while the default values _packets_per_xfer and _xfers_per_queue work well for most applets, they aren't ideal for applets where backpressure results in the loss of data, such as the analyzer applet. In this case, I found that requesting larger transfers sized to hold ~5-10 ms of data allowed for a higher throughput without in_fifo overflows.

The second commit in this PR contains an applet called fixed-throughput. This applet outputs data from the device at a fixed rate, and checks for in_fifo overflows. I used it to test the effect of different combinations of transfer size and transfers queued.

The code block below shows the results of some measurements I took. With the default settings, and a rate of 100 Mbps, the fixed-throughput applet overflowed after ~6 seconds. By changing the settings, the fixed-throughput applet was able to run for ~40 minutes at a rate of 300 Mbps without overflows before I terminated it.

> glasgow run fixed-throughput -h
usage: glasgow run fixed-throughput [-h] [--rpkts READ-PACKETS] [--rxfers READ-TRANSFERS]
                                    rate

Evaluate fixed read throughput performance and check for in FIFO overflows

positional arguments:
  rate                     data rate in Mbps

options:
  -h, --help               show this help message and exit

run arguments:
  --rpkts READ-PACKETS     How many packets per read transfer
  --rxfers READ-TRANSFERS  How many read transfers to have active at a time

> glasgow run fixed-throughput 50
I: g.device.hardware: device already has bitstream ID a341a413bc07ad859c6a3d118bf4a2a4
I: g.cli: running handler for applet 'fixed-throughput'
^Coverflow=False
Elapsed: 68.7474992275238
Mbps: 49.50030727281442
Expected Mbps: 49.5

> glasgow run fixed-throughput 100
I: g.device.hardware: device already has bitstream ID a341a413bc07ad859c6a3d118bf4a2a4
I: g.cli: running handler for applet 'fixed-throughput'
overflow=True
Elapsed: 5.651003122329712
Mbps: 100.1768988169691
Expected Mbps: 100.5

> glasgow run fixed-throughput --rpkts 512 --rxfers 8 100
I: g.device.hardware: device already has bitstream ID a341a413bc07ad859c6a3d118bf4a2a4
I: g.cli: running handler for applet 'fixed-throughput'
^Coverflow=False
Elapsed: 64.04957938194275
Mbps: 100.48714683385604
Expected Mbps: 100.5

> glasgow run fixed-throughput --rpkts 512 --rxfers 8 300
I: g.device.hardware: device already has bitstream ID a341a413bc07ad859c6a3d118bf4a2a4
I: g.cli: running handler for applet 'fixed-throughput'
^Coverflow=False
Elapsed: 2534.1230137348175
Mbps: 300.01638171759214
Expected Mbps: 300.0

[whitequark]

Thank you for the investigation. It's been a while since I looked at this code in depth, and I'm unsure if this is really the best way to solve it, especially given the analyzer's many other deficiencies.

At this moment other commitments do not leave me enough time to discuss a better approach in depth. Are you in the Matrix channel? If so we should talk about it at some point when I do have more time and work out a way forward.

[whitequark]

In particular, it's not clear to me that we can't just change the defaults so that any applet gets a buffer holding 5-10 ms of data. This does go against the DMA memory quotas in the Linux kernel, but:

1. I think the quotas may have been changed at some time between when I first wrote that and today, and
2. 16 MB is a silly amount of memory and we could also insist (by way of a warning) on changing the quota to be higher if it is too low.

[whitequark]

(Also, I think the fixed-throughput applet should perhaps be a part of the benchmark applet instead? It does perform a benchmark, and I don't like adding more top-level names unless there's good justification.)

[Sazzach]

Thanks for the fast response!

Thank you for the investigation. It's been a while since I looked at this code in depth, and I'm unsure if this is really the best way to solve it, especially given the analyzer's many other deficiencies.

No problem! It was time well spent, I learned a number of new things about USB in the process.

At this moment other commitments do not leave me enough time to discuss a better approach in depth. Are you in the Matrix channel? If so we should talk about it at some point when I do have more time and work out a way forward.

No worries about not discussing more now. I'm not on matrix, but I am on the 1BitSquared Discord as "SamIAm", so I see Matrix messages via the bridge.

In particular, it's not clear to me that we can't just change the defaults so that any applet gets a buffer holding 5-10 ms of data. This does go against the DMA memory quotas in the Linux kernel, but:

A potential default change sounds good to me. I think one tradeoff could be latency for applets that don't use auto flush / explicitly flush.

1. I think the quotas may have been changed at some time between when I first wrote that and today, and

2. 16 MB is a silly amount of memory and we could also insist (by way of a warning) on changing the quota to be higher if it is too low.

I'm sad about the 16 MB limit. Its the default on my system (Ubuntu 24.04, Kernel 6.8). Its easy enough to increase by running sudo modprobe usbcore usbfs_memory_mb=, but it seems ridiculous for it to be so low especially with USB cameras etc.

In particular, it's not clear to me that we can't just change the defaults so that any applet gets a buffer holding 5-10 ms of data. This does go against the DMA memory quotas in the Linux kernel, but:

Moving the fixed-throughput applet into the benchmark applet makes sense and I'm happy to make that change.

[whitequark]

Thank you for the responsiveness! I really value this kind of contribution.

I think one tradeoff could be latency for applets that don't use auto flush / explicitly flush.

My view is that any properly designed applet should be using either auto-flush or explicitly flush. Doing neither and just relying on data to 'fall off the FIFO' does happen to work but it is expected to introduce undesirable performance characteristics.

I'm sad about the 16 MB limit. Its the default on my system (Ubuntu 24.04, Kernel 6.8).

Ah, that's upsetting. I really don't want to get involved with LKML (especially not after the latest events) so I guess the default gets to stay what it is. Do you want to explore adding a warning asking for this limit to be raised? I think once you exceed a limit you get a certain error from libusb and we could show the warning once we hit that. I recall this error to be annoyingly ambiguous but we could do what we can, now that we collectively know that it is worth bumping against the limit.

[Sazzach]

Ah, that's upsetting. I really don't want to get involved with LKML (especially not after the latest events) so I guess the default gets to stay what it is. Do you want to explore adding a warning asking for this limit to be raised? I think once you exceed a limit you get a certain error from libusb and we could show the warning once we hit that. I recall this error to be annoyingly ambiguous but we could do what we can, now that we collectively know that it is worth bumping against the limit.

Sure I'll look into detecting the error/making a warning on exceeding the limit. I don't remember what the error was offhand, but I definitely ran into it a few times when I made a mistake calculating the request size.

[whitequark]

Thanks, perfect! If you slice your changes into individual PRs I will likely be able to review and merge them faster (the new benchmark for example could be merged right away as far as I can tell from a very quick glance).