Date: Thu, 2 May 2019 18:48:34 +0930 From: "O'Connor, Daniel" <darius@dons.net.au> To: Hans Petter Selasky <hps@selasky.org> Cc: freebsd-usb@freebsd.org Subject: Re: USB transfers in device drivers Message-ID: <BBA09A08-52F1-413F-861A-D607F91531C1@dons.net.au> In-Reply-To: <e4fdb075-faa8-7832-227b-89700e832162@selasky.org> References: <3B922C60-32E5-484E-8AFA-28FF7255CF2C@dons.net.au> <af8dfb40-1d48-d03b-465f-32b4361e91c0@selasky.org> <D73B37BF-8C28-4EE4-8026-5E9BF8B5C4AD@dons.net.au> <e4fdb075-faa8-7832-227b-89700e832162@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 2 May 2019, at 18:06, Hans Petter Selasky <hps@selasky.org> wrote: > On 2019-05-02 10:22, O'Connor, Daniel wrote: >>> On 2 May 2019, at 06:15, Hans Petter Selasky <hps@selasky.org> = 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? >>>=20 >>> Only the XHCI driver supports HW based double buffering of BULK = transfers. >> Ahh interesting - is that a ECHI hardware limitation or a driver one? >=20 > 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. OK, thanks. To be honest I would much prefer to work out why this particular = hardware & software seem to drop the ball for such a long time - 50msec = without the kernel getting to schedule something (on a basically idle = system) is quite perplexing to me. >>> 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). >=20 > If you want reliable data transfer, BULK is the best. OK, yes, has to be reliable :) >> Related to bandwidth - are there any statistics gathered about how = busy a port is? >=20 > No, but I wanted to add a text-graph frontent to usbdump to collect = this info realtime. Else use a USB wire-analyzer. I wondered about this too, probably easier than instrumenting the EHCI = driver I suppose. Sadly I don't have a USB analyser and even if I did the system in = question is in another country :( -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BBA09A08-52F1-413F-861A-D607F91531C1>