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

Reply via email to