On 2019-05-02 10:22, O'Connor, Daniel wrote:
On 2 May 2019, at 06:15, Hans Petter Selasky <[email protected]> wrote:
On 2019-05-01 10:34, O'Connor, Daniel wrote:
I don't have a solid hypothesis for the failures as yes but one thing I'd like
to make sure is that the USB stack is keeping the USB hardware busy with
pending requests - does anyone know if the USB FIFO code does that
automatically?
Only the XHCI driver supports HW based double buffering of BULK transfers.
Ahh interesting - is that a ECHI hardware limitation or a driver one?
Hi,
It is an EHCI hardware "limitation". It is possible to queue up more
jobs with the EHCI, but it ends that you get a race with the hardware
you'll need to catch. I think it is related to how receiving short
packets are handled.
I suppose you are using BULK. Else you will need to use ISOCHRONOUS transfers.
Yes it's using bulk transfers.
I did consider isochronous transfers when I started this project but I wasn't
sure if there would be enough bandwidth (but perhaps I read the spec wrong). I
imagine there would be enough for this data rate but we have others at higher
speeds (eg 35MB/sec).
If you want reliable data transfer, BULK is the best.
Related to bandwidth - are there any statistics gathered about how busy a port
is?
No, but I wanted to add a text-graph frontent to usbdump to collect this
info realtime. Else use a USB wire-analyzer.
--HPS
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[email protected]"
