Re: [Xenomai-help] About HARD real time... and USB

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]

Antoine Nourry wrote:
> 
>> The current roadmap is to let Xenomai 3 come in two flavors: one based
>> on PREEMPT-RT (Xenomai/Solo), the other (Xenomai/Duo) using Adeos/I-pipe
>> and a second scheduler like Xenomai 2 does, but supporting much less
>> legacy than the latter (no kernel 2.4, no in-kernel RT applications
>> etc.). So depending on your requirements and PREEMPT-RT's progress,
>> you'll be able to chose the fitting platform or even switch between them
>> without too much effort.
>>
>> Jan
>>
>>   
> Thanks again Jan.
> 
> Another point; for RT USB developers, do you think we could use Linux
> native USB stack with PREEMPT_RT in the same way as Xenomai / USB4RT ?

I haven't reviewed the code path of a typical urb in mainline recently,
but I bet the usual two issues exist:

 - Shared (soft-)IRQ and/or workqueue threads with uncritical code
   (either other USB drivers or even totally unrelated kernel
   subsystems). In order to achieve reasonable latencies, you need to
   boost their prios, but that can quickly cause priority inversion,
   thus other latencies.

 - No resource isolation, ie. dynamic buffer allocation which can hit
   temporary shortages or contentions, raising latencies or even
   letting some requests fail.

Moreover you may face troubles as mainline USB is (reasonably) concerned
about hotplug, thus may perform management jobs while you try to acquire
some data at high frequencies and react on the data in real-time.

> 
> I'm pleased with this last solution but the USB4RT bug (need to send a
> command twice) is a real problem for performances (i'd like to increase
> my acquisition rate within a fixed cycle). My only approach to real time
> for the moment is USB driver, and in the Open world i cannot find what
> could be the "right" or "best" solution...

It's a pity, this bug now exists for, hmm, 3 years? But as long as no
one feels the need to dive into it, understand and fix it, this won't
change. Maybe one could even analyze this inside QEMU/KVM, also looking
at the virtual host controller state when the problems shows up. But it
still takes someone to /do/ this.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]