On 09/29/2012 09:46 AM, Anisha Gorur wrote: > Thanks Josh, that helps quite a bit! Our sampling frequency is not > particularly fast, it will only be around 5 MS/S. Right now the send and > receive frame size are still the defaults, 1472 for receive and 1444 for > send. In the notes, it says "to improve receive latency, configure the > transport for a smaller frame size", will this work for send latency as > well? Also is there an equation I can use to determine what the best frame > sizes would be, or should I just go with trial and error and use > latency_test.cpp to determine if it has shifted? If you change the frame > size, how much improvement in latency do you usually see? > Again, thank you so much. > -Anisha >
The reason that shrinking the receive frame size reduces latency is that the RX DSP chain produces samples at a fixed rate. Therefore, the device cannot release a packet until samples_per_packet / sample_rate. The first sample is a packet is delayed by the time it takes to produce the last sample. However, in the case of transmission/send there is no such issue. Essentially your application is the pacer and producer of samples. So you have total control. -Josh > On Fri, Sep 28, 2012 at 6:57 PM, Josh Blum <j...@ettus.com> wrote: > >> >> >> On 09/28/2012 02:46 PM, Anisha Gorur wrote: >>> Thanks Matt! >>> Do you have any idea for what kind of latency we would expect? Also would >> >> The dominating factor in latency here is the gigabit ethernet, this >> tends to be around 100us. Here are a few notes about that: >> >> >> http://files.ettus.com/uhd_docs/manual/html/transport.html#latency-optimization >> >>> the data be routed through the host? My Radio, We only have a couple >> months >> >> Normally the samples would all go to the host computer that configured >> the USRP. It is possible to configure the USRP with one machine but send >> the samples to an arbitrary network location: >> >> >> http://files.ettus.com/uhd_docs/manual/html/usrp2.html#alternative-stream-destination >> >> For that matter, there is nothing wrong with splitting up the USRP >> configuration among several computers. It all depends how you plan on >> using the data. >> >>> to do this, but we have tried to synchronize USRPs before, so we are >> aware >>> of some of the problems. >> >> Anything in particular that I could help to clarify? >> >> -josh >> >>> Thanks, >>> Anisha >>> >>> On Wed, Sep 26, 2012 at 3:51 PM, My Radio <myradioplatf...@gmail.com> >> wrote: >>> >>>> One should remember the extremes involved in syncing all USRP'S which >> will >>>> lead to developing a new driver for USRP2. >>>> >>>> What about the your APP development time?. Are you interested in >>>> developing new driver or app ? >>>> >>>> >>>> On Thu, Sep 27, 2012 at 12:04 AM, Matt Ettus <m...@ettus.com> wrote: >>>> >>>>> You can use a gigabit ethernet switch and put all the USRPs on there. >>>>> You should be able to make USRPs send data to each other. You will of >>>>> course need to do work to get your algorithms into the FPGA. >>>>> >>>>> Matt >>>>> >>>>> On Wed, Sep 26, 2012 at 12:38 PM, Anisha Gorur <at...@virginia.edu> >>>>> wrote: >>>>>> I have a quick theoretical question. Is there any way to construct an >>>>>> 8-channel receiver using 4 USRPS without data going through the host >>>>>> computer? Basically some kind of way to daisy chain mimo cables >> (though >>>>> I >>>>>> know this is not possible), or at least get the same benefits you >> would >>>>>> receive from daisy chaining mimo cables, without using a switch or >>>>> network >>>>>> connections. >>>>>> >>>>>> Thank you, >>>>>> Anisha >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Discuss-gnuradio mailing list >>>>>> Discuss-gnuradio@gnu.org >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
