On Mon, May 30, 2011 at 12:54, Andre Puschmann <[email protected]> wrote: > On 05/29/2011 10:22 AM, Alexander Chemeris wrote: >> On Sun, May 29, 2011 at 03:05, Marcus D. Leech <[email protected]> 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. >> > > Linux' pipe implementation is known to be quite slow. I would suggest to > use UNIX sockets instead. They should perform much better in terms of > latency and performance.
Good idea. -- Regards, Alexander Chemeris. _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
