discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] FIFO latency


From: Alexander Chemeris
Subject: Re: [Discuss-gnuradio] FIFO latency
Date: Mon, 30 May 2011 20:43:30 +0400

On Mon, May 30, 2011 at 18:30, Andre Puschmann
<address@hidden> wrote:
> On 05/30/2011 03:55 PM, Marcus D. Leech wrote:
>> On 30/05/2011 9:51 AM, Alexander Chemeris wrote:
>>>
>>>> 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.
>>>
>> I'm dubious of such a claim--the core mechanisms between Unix-domain
>> sockets and FIFOs are very similar.
>>
>> While it's true that it *used* to be the case that pipes/FIFOs were
>> handled as disk files, that's no longer true--they
>>   just implement ring-buffer objects within the kernel, and Unix-domain
>> sockets are also quite similar--in fact, they
>>   are likely higher overhead, because they have to go through the
>> labyrinthine socket stack, which FIFOs don't.
>>
>> I did my part to put together a FIFO test, so if someone wants to do a
>> Unix-domain socket benchmark we could settle
>>   that question.
>
> There are various papers out there dealing with IPC mechanisms in Linux.
> There is at least one [1] that indicates that IPC is performing quite
> good. On the other hand, I've seen others claiming the opposite.
> Unfortunately, I don't have any recent performance measurements
> available personally. But I agree, would be interesting to see some
> up-to-date benchmark results.

It would be even more interesting to have a set of tests which one
could run on its very own hardware. GnuRadio may be used from high-end
x86 to all flavors of ARMs with a variety of kernel versions and
options and it's hard to say once for all.

>
>
> [1] http://osnet.cs.binghamton.edu/publications/TR-20070820.pdf
>
>
>



-- 
Regards,
Alexander Chemeris.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]