Hah. Yes. Sorry for the confusion.
Sent from my iPhone
> On Mar 9, 2021, at 10:36 PM, Doug Blackburn <doug...@gmail.com> wrote:
>
>
> 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
