What is wrong with FreeBSD and USB Support
Markus Rechberger
mrechberger at gmail.com
Mon Mar 6 10:00:35 UTC 2017
DVB-C:
[2017-03-06 10:53:50] Data recovery within: 2981 milliseconds
[2017-03-06 10:53:50] 40960 bytes | 40.00 kb | 0.04 mb
transferred
[2017-03-06 10:53:51] 0 bytes | 0.00 kb | 0.00 mb
transferred
[2017-03-06 10:53:52] 0 bytes | 0.00 kb | 0.00 mb
transferred
[2017-03-06 10:53:54] Data recovery within: 3009 milliseconds
[2017-03-06 10:53:54] 30720 bytes | 30.00 kb | 0.03 mb
transferred
[2017-03-06 10:53:55] 0 bytes | 0.00 kb | 0.00 mb
transferred
[2017-03-06 10:53:56] 0 bytes | 0.00 kb | 0.00 mb
transferred
[2017-03-06 10:53:57] Data recovery within: 2004 milliseconds
[2017-03-06 10:53:57] 30720 bytes | 30.00 kb | 0.03 mb
transferred
[2017-03-06 10:53:58] 0 bytes | 0.00 kb | 0.00 mb
transferred
[2017-03-06 10:53:59] 0 bytes | 0.00 kb | 0.00 mb
transferred
[2017-03-06 10:54:00] 0 bytes | 0.00 kb | 0.00 mb
transferred
[2017-03-06 10:54:02] Data recovery within: 4009 milliseconds
[2017-03-06 10:54:02] 30720 bytes | 30.00 kb | 0.03 mb
transferred
[2017-03-06 10:54:03] 0 bytes | 0.00 kb | 0.00 mb
transferred
[2017-03-06 10:54:04] 0 bytes | 0.00 kb | 0.00 mb
transferred
[2017-03-06 10:54:06] Data recovery within: 3027 milliseconds
[2017-03-06 10:54:06] 30720 bytes | 30.00 kb | 0.03 mb
transferred
[2017-03-06 10:54:07] 0 bytes | 0.00 kb | 0.00 mb
transferred
[2017-03-06 10:54:08] 0 bytes | 0.00 kb | 0.00 mb
transferred
[2017-03-06 10:54:10] Data recovery within: 2988 milliseconds
[2017-03-06 10:54:10] 30720 bytes | 30.00 kb | 0.03 mb
transferred
[2017-03-06 10:54:11] 0 bytes | 0.00 kb | 0.00 mb
transferred
[2017-03-06 10:54:12] 0 bytes | 0.00 kb | 0.00 mb
transferred
[2017-03-06 10:54:14] Data recovery within: 3018 milliseconds
[2017-03-06 10:54:14] 30720 bytes | 30.00 kb | 0.03 mb
transferred
[2017-03-06 10:54:15] 0 bytes | 0.00 kb | 0.00 mb
transferred
[2017-03-06 10:54:16] 0 bytes | 0.00 kb | 0.00 mb
transferred
DVB-T:
[2017-03-06 10:55:11] 983040 bytes | 960.00 kb | 0.94 mb
transferred
[2017-03-06 10:55:12] 1812480 bytes | 1770.00 kb | 1.73 mb
transferred
[2017-03-06 10:55:13] 1085440 bytes | 1060.00 kb | 1.04 mb
transferred
[2017-03-06 10:55:15] 1474560 bytes | 1440.00 kb | 1.41 mb
transferred
[2017-03-06 10:55:16] 1812480 bytes | 1770.00 kb | 1.73 mb
transferred
[2017-03-06 10:55:17] 972800 bytes | 950.00 kb | 0.93 mb
transferred
[2017-03-06 10:55:18] 1812480 bytes | 1770.00 kb | 1.73 mb
transferred
[2017-03-06 10:55:19] 1024000 bytes | 1000.00 kb | 0.98 mb
transferred
[2017-03-06 10:55:20] 1812480 bytes | 1770.00 kb | 1.73 mb
transferred
[2017-03-06 10:55:21] 1003520 bytes | 980.00 kb | 0.96 mb
transferred
[2017-03-06 10:55:22] 1495040 bytes | 1460.00 kb | 1.43 mb
transferred
even though it's going up and down DVB-T is okay due to the lower
bandwidth so something's obviously wrong with the freebsd USB Support.
On Mon, Mar 6, 2017 at 9:53 AM, Markus Rechberger <mrechberger at gmail.com> wrote:
> Just to clarify this issue it's hardware and software related.
>
> In the linux libusb20 wrapper there's some code in it in the bulk
> callback function
>
> libusb20_tr_submit(xfer)
> if (xfer == xfer0)
> xfer = xfer1
> else
> xfer = xfer0
>
> libusb20_tr_start(xfer)
>
> why should someone toggle the other transfer and not the same one that
> is returning or required to set up?
>
> I would like to set up multiple requests at the same time and not only
> 2 of them (since 2 of them are not fast enough in our case).
>
> This is about resolving an active bug and misconception of the freebsd
> userspace usb API usage.
> Some hardware just need a lower latency.
>
>
>
>
>
>
> On Mon, Mar 6, 2017 at 7:05 AM, Markus Rechberger <mrechberger at gmail.com> wrote:
>> libusb20_dev_open() opens an USB device so that setting up USB
>> transfers becomes possible. The number of USB transfers can be zero
>> which means only control transfers are allowed. This function returns
>> zero on success else a LIBUSB20_ERROR value is returned. A return
>> value of LIBUSB20_ERROR_BUSY means that the device is already opened.
>>
>> libusb20_tr_get_pointer() will return a pointer to the allocated USB
>> transfer according to the pdev and tr_index arguments. This function
>> returns NULL in case of failure.
>>
>> what is the definition of a "tr_index"? The documentation does not
>> cover that anywhere, someone can only copy it from the sample sources.
>> Please don't expect that anyone reading the manpage will have an idea
>> how the FreeBSD API works, because all those items simply do not exist
>> with other operating systems, neither is the ep_index calculation
>> needed with other systems.
>>
>> uint8_t ep_index = (((addr & 0x80) / 0x40) | (addr * 4)) % (16 * 4);
>> uhe->bsd_xfer[0] = libusb20_tr_get_pointer(dev->bsd_udev, ep_index + 0);
>> uhe->bsd_xfer[1] = libusb20_tr_get_pointer(dev->bsd_udev, ep_index + 1);
>>
>> So my guess is that the examples are just using 2 urb transfers and
>> freebsd just cannot catch up. However it is still unclear how to
>> correctly initiate more than 2 urb transfers by reading the
>> documentation.
>>
>> Markus
>>
>> On Mon, Mar 6, 2017 at 6:50 AM, Markus Rechberger <mrechberger at gmail.com> wrote:
>>> Hi,
>>>
>>> I got one step further it turns out that the problem is indeed the
>>> FreeBSD Stack, the latency is terrible causing an overflow on the
>>> chipside. Once that happens the transfer has to be restarted (which
>>> requires to toggle a register).
>>> Is there any way to do low latency transfers with FreeBSD?
>>>
>>> Markus
>>>
>>> On Mon, Mar 6, 2017 at 6:19 AM, Markus Rechberger <mrechberger at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I have been trying to port a driver to freebsd for a day now and the
>>>> result is quite negative.
>>>>
>>>> So my feedback about libusb20 and the FreeBSD USB Kernel Stack:
>>>>
>>>> 1. the documentation is not clear how to set up asynchronous bulk
>>>> transfers (please explain the architecture of this API)
>>>>
>>>> 2. the errors returned by libusb20 (and probably from the kernel) are
>>>> not detailed enough (in certain cases I'm able to get libusb20 unknown
>>>> error, to my understanding every error should have some meaning).
>>>>
>>>> 3. the FreeBSD USB Stack messes around with the transfer itself
>>>> damaging the entire result (eg resulting in stalled USB bulk
>>>> transfers).
>>>>
>>>> 4. The FreeBSD data transfer implementation itself is a disaster, I'm
>>>> able to transfer data at a rate of 2 MB/sec, anything higher results
>>>> in a stalled usb transfer?!
>>>>
>>>> 5. USB Control messages are 100% slower than with other operating
>>>> systems (eg. it took 14 seconds to load a driver with FreeBSD while it
>>>> only takes 7 seconds on other systems).
>>>>
>>>> Since I have been using USB stacks with Linux, Mac and some other
>>>> systems I can say that FreeBSD has the most irritating implementation
>>>> of all.
>>>>
>>>> So finally I wonder what is wrong with FreeBSD's USB support?
>>>>
>>>> Best Regards,
>>>> Markus
More information about the freebsd-multimedia
mailing list