Re: [USRP-users] DMA FIFO latency with X310

[Marcus D Leech via USRP-users]

Dear lord. The calculator on my iPhone only goes to 1e8 in portrait mode. I had 
not noticed, so I slipped a decimal place. Doh!!

Sent from my iPhone

> On Dec 30, 2020, at 11:48 AM, EJ Kreinar  wrote:
> 
> 
> Simple math is not working out for me today-- Maybe it's the holidays??
> 
> I think a 9000 *byte* packet would be 9000*8/1e9 = 72 microseconds
> 
> ... However the FFT input needs 8192 *samples* which is 8192*4*8/1e9 = 262 
> microseconds!
> 
> Seems like your latency is driven by sending data over the network here
> 
> EJ
> 
>> On Wed, Dec 30, 2020, 11:37 AM Marcus D Leech  
>> wrote:
>> Simple math. 
>> 
>> A 9000 *byte* packet is 72000 *bits*
>> 
>> At 1.0e9 *bits/sec* that’s a latency of 720usec
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> > On Dec 30, 2020, at 8:55 AM, Jorge Arroyo Giganto via USRP-users 
>> >  wrote:
>> > 
>> > 
>> > Hi EJ,
>> > 
>> > Yes, I tried replacing the DMA FIFO with a normal FIFO and the latency got 
>> > a bit worse and more irregular (I'm guessing that's due to not smoothing 
>> > that burstiness in the Ethernet interface with the DMA FIFO you mentioned).
>> > 
>> > I have just tried your graph suggestion (Host -> FFT -> FIFO -> Host) and 
>> > the latency looks about the same but in the FFT block instead. Also I had 
>> > to use packets with spp=256 in the tx streamer in order to match the spp 
>> > that the FFT block accepts or I would get an error when building the 
>> > streamer. Maybe making the FFT block somehow be able to accept bigger 
>> > packets would decrease the latency?
>> > 
>> > About the theoretical latency for a packet of 8192 bytes you mention, 
>> > shouldn't it be 8192*4 bytes assuming that each sample is a sc16 (2 bytes 
>> > for the real part and 2 bytes for the imaginary part of each sample)? Then 
>> > this latency I am experiencing would make more sense?
>> > 
>> > Thank you so much for your feedback, I will also keep in mind your comment 
>> > about the way I am using RFNoC.
>> > 
>> > Best regards,
>> > 
>> > Jorge
>> > 
>> > ___
>> > USRP-users mailing list
>> > USRP-users@lists.ettus.com
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] DMA FIFO latency with X310

[EJ Kreinar via USRP-users]

Simple math is not working out for me today-- Maybe it's the holidays??

I think a 9000 *byte* packet would be 9000*8/1e9 = 72 microseconds

... However the FFT input needs 8192 *samples* which is 8192*4*8/1e9 = 262
microseconds!

Seems like your latency is driven by sending data over the network here

EJ

On Wed, Dec 30, 2020, 11:37 AM Marcus D Leech 
wrote:

> Simple math.
>
> A 9000 *byte* packet is 72000 *bits*
>
> At 1.0e9 *bits/sec* that’s a latency of 720usec
>
>
>
> Sent from my iPhone
>
> > On Dec 30, 2020, at 8:55 AM, Jorge Arroyo Giganto via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> >
> > 
> > Hi EJ,
> >
> > Yes, I tried replacing the DMA FIFO with a normal FIFO and the latency
> got a bit worse and more irregular (I'm guessing that's due to not
> smoothing that burstiness in the Ethernet interface with the DMA FIFO you
> mentioned).
> >
> > I have just tried your graph suggestion (Host -> FFT -> FIFO -> Host)
> and the latency looks about the same but in the FFT block instead. Also I
> had to use packets with spp=256 in the tx streamer in order to match the
> spp that the FFT block accepts or I would get an error when building the
> streamer. Maybe making the FFT block somehow be able to accept bigger
> packets would decrease the latency?
> >
> > About the theoretical latency for a packet of 8192 bytes you mention,
> shouldn't it be 8192*4 bytes assuming that each sample is a sc16 (2 bytes
> for the real part and 2 bytes for the imaginary part of each sample)? Then
> this latency I am experiencing would make more sense?
> >
> > Thank you so much for your feedback, I will also keep in mind your
> comment about the way I am using RFNoC.
> >
> > Best regards,
> >
> > Jorge
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] DMA FIFO latency with X310

[Marcus D Leech via USRP-users]

Simple math. 

A 9000 *byte* packet is 72000 *bits*

At 1.0e9 *bits/sec* that’s a latency of 720usec



Sent from my iPhone

> On Dec 30, 2020, at 8:55 AM, Jorge Arroyo Giganto via USRP-users 
>  wrote:
> 
> 
> Hi EJ,
> 
> Yes, I tried replacing the DMA FIFO with a normal FIFO and the latency got a 
> bit worse and more irregular (I'm guessing that's due to not smoothing that 
> burstiness in the Ethernet interface with the DMA FIFO you mentioned).
> 
> I have just tried your graph suggestion (Host -> FFT -> FIFO -> Host) and the 
> latency looks about the same but in the FFT block instead. Also I had to use 
> packets with spp=256 in the tx streamer in order to match the spp that the 
> FFT block accepts or I would get an error when building the streamer. Maybe 
> making the FFT block somehow be able to accept bigger packets would decrease 
> the latency?
> 
> About the theoretical latency for a packet of 8192 bytes you mention, 
> shouldn't it be 8192*4 bytes assuming that each sample is a sc16 (2 bytes for 
> the real part and 2 bytes for the imaginary part of each sample)? Then this 
> latency I am experiencing would make more sense?
> 
> Thank you so much for your feedback, I will also keep in mind your comment 
> about the way I am using RFNoC.
> 
> Best regards,
> 
> Jorge
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] DMA FIFO latency with X310

[Jorge Arroyo Giganto via USRP-users]

Hi EJ,

Yes, I tried replacing the DMA FIFO with a normal FIFO and the latency got
a bit worse and more irregular (I'm guessing that's due to not smoothing
that burstiness in the Ethernet interface with the DMA FIFO you mentioned).

I have just tried your graph suggestion (Host -> FFT -> FIFO -> Host) and
the latency looks about the same but in the FFT block instead. Also I had
to use packets with spp=256 in the tx streamer in order to match the spp
that the FFT block accepts or I would get an error when building the
streamer. Maybe making the FFT block somehow be able to accept bigger
packets would decrease the latency?

About the theoretical latency for a packet of 8192 bytes you mention,
shouldn't it be 8192*4 bytes assuming that each sample is a sc16 (2 bytes
for the real part and 2 bytes for the imaginary part of each sample)? Then
this latency I am experiencing would make more sense?

Thank you so much for your feedback, I will also keep in mind your comment
about the way I am using RFNoC.

Best regards,

Jorge
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] DMA FIFO latency with X310

[EJ Kreinar via USRP-users]

Can you replace the DMA FIFO with a normal FIFO? The DMA FIFO is mostly
used for continuous streaming-- it provides a data buffer using off-chip
DRAM that smooths out any burstiness in the ethernet interface so there's
no overflows/underruns-- but it should not be needed for your application.

You might try the following rfnoc graph: Host -> FFT -> FIFO -> Host

With that graph you'll be able to directly observe the latency presented to
the FFT block by the ethernet transport only. Using a 1G interface for a
packet of 8192 bytes gives a theoretical best one way latency of 65 us...
It is a long way from 200 us-- but already higher than the FFT compute
time.

Finally, I will add... in my opinion using rfnoc explicitly as a
network-attached coprocessor is probably not an ideal use case. I will
often set up loopback tests like you are doing here, but mostly this is to
validate custom compute blocks and I don't care about latency. Afterwards I
will embed the blocks into stream processing that's attached directly to a
radio.

Best regards,
EJ

On Wed, Dec 30, 2020, 4:15 AM Jorge Arroyo Giganto via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Nick,
>
> I am running the X310 interface at 1Gbit using the SFP Adapter that came
> with the X310.
>
> At first I fowollowed the advice from Ettus USRP Manual
> 
> of setting the MTU to 1500 and _frame_size=1472 when running at
> 1Gbit, however I actually got better results in terms of latency setting
> the MTU to 9000 and _frame_size=8000. I also tried using other
> intermediate and smaller values but the results didn't get any better.
>
> Best regards,
>
> Jorge
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] DMA FIFO latency with X310

[Jorge Arroyo Giganto via USRP-users]

Hi Nick,

I am running the X310 interface at 1Gbit using the SFP Adapter that came
with the X310.

At first I fowollowed the advice from Ettus USRP Manual

of setting the MTU to 1500 and _frame_size=1472 when running at
1Gbit, however I actually got better results in terms of latency setting
the MTU to 9000 and _frame_size=8000. I also tried using other
intermediate and smaller values but the results didn't get any better.

Best regards,

Jorge
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com