Hello,
I have an application that schedules transmissions/receives on a short time
scale (order of tens of microseconds). I'm attempting to gauge the feasibility
of using a x310 with UBX-160 daughterboards and 10Gb ethernet for the
application.
I wrote a quick test to see approximately how long it would take to schedule a
bunch of DSP retunes:
for (int i = 0; i < packets_to_send; i += batch_size)
{
start = std::chrono::system_clock::now();
for (int j = 0; j < batch_size; j++)
{
// Hop at a scheduled time
usrp->set_tx_freq(tune_request.getNextTuneRequest());
usrp->clear_command_time();
cmd_time += schedule_increment;
usrp->set_command_time(cmd_time);
}
stop = std::chrono::system_clock::now();
elapsed = std::chrono::duration_cast<std::chrono::microseconds>(stop -
start).count();
if (elapsed < batch_latency)
{
busyCheck(batch_latency - elapsed);
}
else
{
long_elapsed++;
std::cout << elapsed << ", ";
}
}
The behavior is slightly different than I would expect. I know the USRP has a
command FIFO with approximately 16 slots to queue up commands. I would expect
that the first chunk of commands would execute quickly, and then the
set_tx_freq call would start blocking as it waits for the queue to have space.
Instead I see that the first handful of commands take on the order of 1000 us,
and it steadily decreases in time until hitting a steady state where it takes
250 - 300 us to schedule a command.
Are there any obvious mistakes in my test setup? Can I reduce my retune command
times to under 100 us?
Thanks,
Richard
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
