discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: Latency out of Stream Mux block with unequal input lengths


From: Michael Dickens
Subject: Re: Latency out of Stream Mux block with unequal input lengths
Date: Mon, 28 Oct 2019 10:44:54 -0400

Hi Adam - Check out this presentation from GRCon19 < https://www.gnuradio.org/grcon/grcon19/presentations/managing_latency/ >. The basic issue is that the FIFO buffer between the source and next block will fill up with data, so any change to the source value will be at the end of the FIFO & require all of the data in the buffer to be read out before that value comes up. The FIFO buffer with 50 items will be updated more quickly ... as in 49:1 more quickly! Hope this is useful! - MLD

On Mon, Oct 28, 2019 at 9:49 AM Gannon, Adam M. (GRC-LCI0) <address@hidden> wrote:
Hi List,

I'm trying to understand the latency behavior of the Stream Mux block when two streams of unequal lengths are being multiplexed together. Attached is a minimal flow graph that illustrates the point.

In the example, two streams are multiplexed: one Vector Source of length 50 and one of length 1 whose value is adjusted while running. It takes several seconds at 1Msps for the change in the value of the shorter (L=1) stream to be reflected in the muxed stream. The reverse is not true - a change in the longer stream (L=50) is immediately reflected in the muxed stream. I believe this is because both Vector Sources are producing samples at the same rate but are being muxed at a ratio of 50:1. So when the value of the L=1 stream changes it has to empty the existing samples from its output buffer before the new samples start to be muxed.

In my application, I am formatting data from an external source into the header of my packet. There are several stream multiplexers after that to form the packet (adding payload, trailer, etc). I'd like to minimize the latency before new data is reflected in the entire formatted packet. I was considering writing one block to create the entire packet, but wanted to ask for advice on if there is a better / more modular solution.


Much appreciated,
Adam


--
Michael Dickens
Ettus Research Technical Support
Email: address@hidden
Web: https://ettus.com/

reply via email to

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