Re: [Discuss-gnuradio] FIFO latency

[Colby Boyer]

On Sun, May 29, 2011 at 1:22 AM, Alexander Chemeris
<address@hidden> wrote:
> On Sun, May 29, 2011 at 03:05, Marcus D. Leech <address@hidden> wrote:
>> On 05/28/2011 04:28 PM, Alexander Chemeris wrote:
>>>>
>>>> So, while this method is simple and good for non-realtime
>>>> applications, it doesn't fit our needs. It may be usable for PHY<->MAC
>>>> interaction, but even here I'm not sure it would work well.
>>>>
>>>> PS I test on Core 2 Duo 1.6 GHz with all the GUI stuff running.
>>>
>>> Ok, setting CPU affinity and cutting off startup artifacts definitely
>>> helps.
>>> Results are in attachment.
>>> Still you can see quite some uncertainty.
>>>
>> OK, so a roughly 3:1 improvement in peak latency, and somewhat better
>> predicability.
>>
>> But I'd still counter-assert, to your assertion, that latencies in the
>> 10s-of-usec are entirely acceptable for
>>  a wide-range of "real-time" applications, even with occasional latency
>> excursions that increase the variability
>>  by 50:1 or so.
>>
>> I can well imagine that they aren't acceptable for *your* application.  I
>> mean, if all applications were the same, it would
>>  be a very boring world, with most of us working at fast-food restaurants
>> :-)
>>
>> But I'll stand by my original suggestion that use of FIFOs are an acceptable
>> technique for a wide variety of applications, including
>>  "real-time" applications, depending on constraints and requirements.
>
> Sure, I don't say that no one should use queues :)
> I just want to say that it may not be suitable for applications with
> more tight requirements - i.e. some alternative may be needed.
>
> But to say truth - I'm surprised by their performance, I thought it
> would be much worse. So it may be a good starting point from which we
> could refine later.
>
> --
> Regards,
> Alexander Chemeris.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

Would it be possible (legally) for the closed source and open source
threads to share the same "memory space", and use interrupts (or
semaphores) to trigger arrivals and departure of information. The only
aspect the two systems share is how to package and format the
information. This should work similar to DMA for software-hardware
interfaces.

?

--Colby