You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, making very large latency-sensitive USB reads is done by giving interface.read() a hint with the amount of expected data, which causes it to use a buffer that large. Unfortunately, the following sequence still results in a FIFO underflow:
interface.read(512, hint=512*1000) is called
device returns a single 512-byte packet, interface.read returns
processing starts; bus is idle (no IN-BULK-NAK)
device queues 2 (4) more 512-byte packets, filling FX2 FIFO
interface.read(512, hint=512*1000) is called again
Given how small the FX2+device FIFO are (at most a 2+30 KB on UP5K), the maximum fill rate (up to 30 KB per millisecond), and the OS scheduling latency (at best, a few milliseconds), if we get a context switch anywhere between steps 3 and 5, a FIFO underflow is unavoidable at the maximum fill rate, and becomes linearly less likely at fractions of maximum fill rate. This can be easily demonstrated with the shugart-floppy applet at higher read redundancies.
Thus, we have to teach the software to pipeline USB reads. Up to 30 MB/s of reads should definitely be doable in Python if no particular processing is done (shugart-floppy just appends reads to a buffer), and possibly even with processing.
The text was updated successfully, but these errors were encountered:
Right now, making very large latency-sensitive USB reads is done by giving
interface.read()
ahint
with the amount of expected data, which causes it to use a buffer that large. Unfortunately, the following sequence still results in a FIFO underflow:interface.read(512, hint=512*1000)
is calledinterface.read
returnsinterface.read(512, hint=512*1000)
is called againGiven how small the FX2+device FIFO are (at most a 2+30 KB on UP5K), the maximum fill rate (up to 30 KB per millisecond), and the OS scheduling latency (at best, a few milliseconds), if we get a context switch anywhere between steps 3 and 5, a FIFO underflow is unavoidable at the maximum fill rate, and becomes linearly less likely at fractions of maximum fill rate. This can be easily demonstrated with the
shugart-floppy
applet at higher read redundancies.Thus, we have to teach the software to pipeline USB reads. Up to 30 MB/s of reads should definitely be doable in Python if no particular processing is done (
shugart-floppy
just appends reads to a buffer), and possibly even with processing.The text was updated successfully, but these errors were encountered: