> On Sun, May 29, 2011 at 1:22 AM, Alexander Chemeris
> <alexander.chemeris@gmail.com> wrote:
>> On Sun, May 29, 2011 at 03:05, Marcus D. Leech <mleech@ripnet.com> 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
>> Discuss-gnuradio@gnu.org
>> 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.
IANAL, but AFAIK this was possible with GPLv2 is this usage was
considered "an intended usage". Like running applications is an
intended usage of a kernel. I admit I'm not sure whether this works
with GPLv3 or not.
--
Regards,
Alexander Chemeris.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment