I'm running the SW directly on the ARM of the X410, so that should rule out
network latency.
When using the UHD API on the ARM does it still go through the MPM?
Is there a way to bypass MPM?
From: Marcus D. Leech <patchvonbr...@gmail.com>
Sent: Thursday, November 16, 2023 1:36 PM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Re: peek32/poke32 slow
External E-mail --- CAUTION: This email originated from outside GDMS. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.
On 16/11/2023 15:11, Alvin.Begaye--- via USRP-users wrote:
Hi I am using an x410, and running through the init_gain_block example, using
the high resolution timer I am getting these results, which seem really slow,
is there a faster way to read/write registers?
I believe that on the X410, operations like that actually end up going through
the MPM process that is running in the Linux PS
slice on the FPGA.
One can expect to pay various "latency tolls". There's app-land-to-kernel
latency on your host, latency of the network stack,
latency of the network media itself, and then all of those things in reverse
order on the X410 side, since MPM is just a piece
of software running as a normal app process in the Linux PS on the X410.
It has never been the case that what amounts to "session parameter" settings
were intended to be super-fast, because in general,
those things happen at a MUCH MUCH slower pace than the signals themselves.
Time 481.835 micro seconds.
Gain value read/write loopback successful!
Here is the code.
t1 = high_resolution_clock::now();
gain_block->set_gain_value(new_gain_value);
const uint32_t gain_value_read = gain_block->get_gain_value();
t2 = high_resolution_clock::now();
delta_time = duration_cast<duration<double>>(t2-t1);
std::cout << std::flush ;//<< std::endl;
std::cout << "Time " << delta_time.count()*1000000.0 << " micro seconds."
<< std::endl;
_______________________________________________
USRP-users mailing list --
usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>
To unsubscribe send an email to
usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
