Hi Marcus,
thank your for your answer and sorry for the late reply.
Yes, I mean host CPU frequency. I was wondering how I can get the
<inherent-complexity-per-sample>. Do you have any hints on this or
provide me with an example?
If we consider an application that simply gather/transmit the data
from/to USRP without adding any particular processing (something like a
loopback application), what is the complexity to play with the samples?
May ARM processors, with low frequency such as 1.4GHz, handle the stream
without showing RT issues?
Thanks a lot.
Best Regards,
Federico
On 17/03/23 18:03, Marcus D. Leech wrote:
On 17/03/2023 06:47, Federico Civerchia wrote:
Dear community,
I am working with a N310 in a 2x2 MIMO setup. What I noticed is that
if I consider a processor with a base frequency lower than 3.5GHz, I
have several real-time problems with many late packets (LLLLs).
However, if I consider processor with 3.5GHz or higher base
frequency, this issue disappears (or I may have few LLLs very rarely).
Have you already observed a behavior like this? What is the reason
that links processor frequency with real-time issues?
Thank you.
Best Regards,
Federico
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
You mean your host CPU frequency?
Actual sample-processing performance is dependent on a BUNCH of
factors, including CPU clock rates, memory bandwidth,
I/O bandwidth, etc.
In general, at a high level, the processing power required scales with:
<inherent-complexity-per-sample> X <sample-rate>
So, the more complex "things" you do to a sample stream at the input
sample rate, the more CPU/memory-bandwidth/IO-bandwidth
you need to get the task done without dropping anything.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to 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