On 29/11/2023 08:30, alvin.beg...@gd-ms.com wrote:
I would like to do the following, to figure out what is being tweaked
on the HW.
1) Update X410 with a mender image (via mender install)
2) git clone the UHD repo, rebuild it with -g and install over what
was mender.
Is there a recommended way to do this? I would like to see the call
flow with GDB to figure out what register is being written to when I
access a register to an rfnoc block.
I'm not sure that -g will help that much, since most of MPM is written
in Python, the source-code of which is in the UHD codebase.
*From:* Marcus D. Leech <patchvonbr...@gmail.com>
*Sent:* Thursday, November 16, 2023 1:55 PM
*To:* Begaye, Alvin A <alvin.beg...@gd-ms.com>; usrp-users@lists.ettus.com
*Subject:* Re: [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:50, alvin.beg...@gd-ms.com wrote:
I’m running the SW directly on the ARM of the X410, so that should
rule out network latency.
The ARM on the X410 is (AFAIR) dual-core, and not very speedy. Even
when you're talking locally, you
still go through the network stack (localhost). So even though
there's no actual network *hardware*
involved, you're still paying the network stack costs.
When using the UHD API on the ARM does it still go through the MPM?
Yes, as far as I know.
Is there a way to bypass MPM?
Well, all the source code is freely available--so you could figure out
how MPM turns those calls into actual "knobs"
being tweaked on the hardware, and tweak those knobs yourself in
your own code.
*From:* Marcus D. Leech <patchvonbr...@gmail.com>
<mailto: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
To unsubscribe send an email tousrp-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
