[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRC max sample rate

From: Koyel Das (Vehere)
Subject: Re: GRC max sample rate
Date: Sun, 26 Jul 2020 19:15:07 +0000

Hi Marcus,

Good that you replied my email. Since you work on Radio Astronomy as I heard from Neel, I want to ask you something. By using USRP I saw that without any special configuration the phases of any two channels of USRP 2955 are phase coherent and the phase difference value is constant for a stationary source in one run of the application. However, for phase aligned operation that is instrumental phase difference between two channels to be zero we need LO sharing and time commands. So suppose I don’t phase align the system and find delay- rate spectrum then what impact the instrumental phase offset between two channels will have on the delays of sources in the DR spectrum. Will the offset add an additional delay to every source by a fixed amount or this will have some random effects on the delays of the sources in DR spectrum. You may be knowing but still, in delay-rate, rate stands for Doppler shift.


From: Discuss-gnuradio <discuss-gnuradio-bounces+koyel.das=vehere.com@gnu.org> on behalf of Marcus D. Leech <patchvonbraun@gmail.com>
Sent: Monday, July 27, 2020 12:18:01 AM
To: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
Subject: Re: GRC max sample rate
On 07/26/2020 02:10 AM, Koyel Das (Vehere) wrote:
Hi Kyeong,

Since you have received at 200 MSPS data from usrp, I am asking this to you. What were your system parameters to receive at 200 MSPS like clock speed of processor, did you have DDR4 ram with ssd? And 10 gbps nic card? What clock speed of processor is needed? And what other things are needed?

I am asking this to compare with the parameters told to me by one of my friends. Since you have handled this data rate yourself you will be able to tell exactly.

So please help.


Let us for a moment pretend that we aren't talking about SDRs and USRPs and DSP.

Let us cast the problem more generally as "I need my computer to do 200 million 'things' every second--can my computer do this?".

The answer to that question is categorically NOT simple and well characterized.  It really isn't.

The analysis breaks down along a number of different dimensions, including:

  o What are the 'things' you want to do at 200e6 'things per second'--how many CPU instructions does 'thing' decompose into, on average?
  o What is your CPU architecture?  Can it even handle that many instructions/second?
      o Is your CPU heavily or lightly pipelined?
      o Is it RISC or CISC?
      o Is there meaningful branch prediction and cache pre-fill?
      o Are there more than one CPUs in a given system
      o Does the CPU architecture have internal parallelism--multiple execution units for common operations like basic arithmetic
      o Are there multiple instruction-decode units in a single CPU?
      o Are floating-math units shared among CPUs on the chip, or are there dedicated FPUs?   Is there inherent parallelism in the FPU?
      o Are there vector execution units available, and does the software take advantage of them
      o What is the memory architecture? How fast is it?
      o What is the cache size--are there separate I and D caches?  How is cache managed?
      o What is the basic clock-rate of the CPU, and how does that decompose into memory bandwidth and instruction-fetch and other sub-cycles?
   o What is the I/O architecture, and how fast are the relevant buses--are there multiple buses?
   o Do I have enough RAM so that there's never any pressure on it so that large working-set sizes can be maintained?
   o What of the application?   What is the average code-path length for each 'thing' that needs to be done?
   o Are there opportunities for parallelism in the application?  Have they been taken advantage of?
   o Does the operating system schedule CPU-bound jobs appropriately?  Can this be tweaked?

This is a fairly-standard "capacity planning" exercise that is, at a high level, unrelated to USRPs or SDRs or DSP.

Being robustly successful with SDR requires knowledge and experience in a number of disciplines including:

  RF and analog design
  Sometimes FPGA development and design
  Digital signal processing
  Computer system design and capacity planning
  Software development methodologies
  Non-trivial algorithm comprehension and development

If you, as an individual, or in aggregate as a development team, are missing too many of these, robust success will be a much longer time
  coming.  That's just an inherent property of doing SDR development, and deploying SDR-based systems.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]