Marcus,
Thanks for your response; I believe I am. The math is spread over two
lines:
uhd::time_spec_t expectedTime = startTime + (double) ( num_tx_samps )
/ (double)usrp->get_tx_rate();
Best,
Doug
On Tue, Mar 9, 2021 at 10:20 PM Marcus D Leech <patchvonbr...@gmail.com>
wrote:
> Shouldn’t you be scaling your num_tx_samples by the time per sample when
> calculating the expectedTime?
>
> Sent from my iPhone
>
> On Mar 9, 2021, at 10:03 PM, Doug Blackburn via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>
> Hello --
>
> I've got some questions re: latency with the x300 over the 10GigE
> interface.
>
> If I use the latency_test example operating at a rate of 50 MSPS, I have
> no issues with a latency of 1ms. The latency test receives data, examines
> the time stamp, and transmits a single packet.
>
> I have an application where I'd like to run the transmitter continuously,
> and I got curious about the latency involved in that operation. My
> application is similar to the benchmark_rate example. I added the
> following lines to the benchmark_rate example at line 256 after the line.
>
> md.has_time_spec = false;
>
> ====
> if ( (num_tx_samps % 50000000) < 4*max_samps_per_packet )
> {
> uhd::time_spec_t expectedTime = startTime + (double) ( num_tx_samps )
> / (double)usrp->get_tx_rate();
> uhd::time_spec_t timeAtLog = usrp->get_time_now();
> timeAtLog = usrp->get_time_now();
> std::cerr << "==== Actual time ====" << std::endl;
> std::cerr << " " << timeAtLog.get_full_secs() << " / "
> << timeAtLog.get_frac_secs() << std::endl;
> std::cerr << "==== Expected time ====" << std::endl;
> std::cerr << " " << expectedTime.get_full_secs() << " / "
> << expectedTime.get_frac_secs() << std::endl;
> }
> ====
>
> The intent of this insertion is to log the time at which we return from
> tx_stream->send() and the time at which the first sample of that sent data
> should be transmitted -- at approximately once per second when running at
> 50 MSPS.
>
> After the first second, I consistently saw the following results:
>
> ==== Actual time ====
> 1 / 0.10517
> ==== Expected time ====
> 1 / 0.27253
>
> ==== Actual time ====
> 1 / 0.105419
> ==== Expected time ====
> 1 / 0.27255
>
> Which indicates to me that there is a latency of approximately 167ms when
> transmitting data. That is, the send() function is returning 167ms earlier
> than I expect the data to actually be transmitted. If I halve the sample
> rate to 25 MSPS, the latency doubles.
>
> What is the source of the latency when running in a continuous mode?
> Initially, I had thought that this might be related to the
> send_buffer_size, but making changes to send_buffer_size seem to not have
> an effect. FWIW, 167ms at 50 MSPS is suspiciously close to the value for
> wmem_max (33554432) suggested in the x300 system configuration ... but
> neither changing that value or send_buffer_size seems to make a difference.
>
> Is this latency tunable?
>
> Thank you for your help!
>
> Best Regards,
> Doug Blackburn
>
> _______________________________________________
> 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
