Dear all,
I cross-compiled a small C++ application that records some IQ samples and runs
stand-alone on the X410.
I want to use a sampling rate from 7.68e6 up to 15.36e6 samples per second. The
IQ samples are written into the /run directory.
Unfortunately I often get overflows, so that the syste
Hi,
I’m using a USRP B200 mini to receive the GOES Rebroadcast (GRB) signal at
1.6866 GHz. Before recording, I ran a benchmark using the *benchmark_rate*
script at a rate of 13 MHz, which completed without any dropped samples.
The command I used was:
sudo ./benchmark_rate --args "type=b200" --rx_r
Hello,
I am currently running into buffer overflows with the x410 where I am unable to
stream for data rates larger than \~0.32 Gb/s when the CHDR_W is 128. However,
if I stream using a CHDR_W of 64, I am able to push the data rate much
higher(at least 3.2 Gb/s). I compiled a custom image using
Hi all,
I try to use a USRP X300 with a 10G Ethernet link at full speed (200MS/s),
running uhd 3.15.0 and gnuradio 3.8.2.
I followed all the tips from
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks
but I still receive "O"s from time to time.
I don't have these messages at 100MS
Starting to get an idea what is going on with the startup overflows
First, suppose I have a raw UHD application that does the following:
{
instantiate usrp object, set freq, gain, samp_rate
issue stream cmd to start some time in the future (2 sec)
while(1)
{
call _rx_stream->recv()
Same deal - with "num_recv_frames=128,master_clock_rate=" +
str(samp_rate*4) I still get "ODD", just about every time.
On Thu, Nov 19, 2020 at 6:52 AM Ron Economos via USRP-users <
usrp-users@lists.ettus.com> wrote:
> The automatic setting of the master clock seems to be getting in the way
> afte
The automatic setting of the master clock seems to be getting in the way
after the PPS transition. Try explicitly setting the master clock.
"num_recv_frames=128,master_clock_rate=" + str(samp_rate*4)
Ron
On 11/19/20 03:33, Josh via USRP-users wrote:
Marcus,
This is naked hardware - B210 usb
Marcus,
This is naked hardware - B210 usb into a pretty beefy laptop running Ubuntu
20.04, GNU Radio latest master (3.9)
Even with num_recv_frames = 128, still getting "ODD" at startup of the
flowgraph
Any other optimizations I should be tuning? Getting no overruns in the
steady state, just at s
On 11/18/2020 07:27 AM, Josh via USRP-users wrote:
I'm seeing a difference in behavior between gr-uhd and plain uhd c++ api:
Setup:
B210, 2 channels, 5MSPS, master_clock_rate 20MSPS, PPS sync
Receive only flowgraph
With gr-uhd, there is always a "OOD" when the flowgraph first starts
But, if I
I'm seeing a difference in behavior between gr-uhd and plain uhd c++ api:
Setup:
B210, 2 channels, 5MSPS, master_clock_rate 20MSPS, PPS sync
Receive only flowgraph
With gr-uhd, there is always a "OOD" when the flowgraph first starts
But, if I replicate the setup in a simple compiled program usin
On 07/26/2018 01:30 PM, Андрій Хома wrote:
Have you changed your cpu governor to performance?
yes
Have you tuned your network interface profile with ethtool -g?
When I work with a usrp x310 - yes
I found that maxing out that buffer size helped lots.
i playing with it
You ma
Ahh sorry dude. That is what used to happen to me before I tried the stuff
I listed. The only other thing I can thing of is maybe playing around with
MTU. I found my best performance at 4000, but I'm not sure that will help.
On Thu, Jul 26, 2018 at 11:30 AM, Андрій Хома wrote:
> Have you changed
>
> Have you changed your cpu governor to performance?
>
yes
Have you tuned your network interface profile with ethtool -g?
>
When I work with a usrp x310 - yes
I found that maxing out that buffer size helped lots.
>
i playing with it
> You may also have to manually schedule your threads if usi
Have you changed your cpu governor to performance? Have you tuned your
network interface profile with ethtool -g? I found that maxing out that
buffer size helped lots. You may also have to manually schedule your
threads if using isolcpus/numactl/taskset. I noticed that the linux
scheduler did a poo
Yes, thank you, I've tried this before: I allocated 10 or more cores purely
for the USRPs. Overflows are generally less, but when starting any
application, one or two "O" are guaranteed to be printed.
Therefore, I suggested that maybe it's a case of cache or something else.
I was playing with num_
Make sure that you’re increasing the num_recv_frames in the device args as well
Sent from my iPhone
> On Jul 26, 2018, at 11:10 AM, Keith k via USRP-users
> wrote:
>
> How many CPU cores do you have? I've also found this a problem with multiusrp
> and high data rates. The solution for me was
How many CPU cores do you have? I've also found this a problem with
multiusrp and high data rates. The solution for me was to isolate cpu cores
and then use taskset to run my program on the isolated cores. This
drastically reduced the number of overflows to almost none. This however
will probably r
Motherboard Z10PE-D8 WS
Processor Intel Xeon E5-2630V4
Sample rate - 45MHz
In general, overflows are not regular. If the computer is not touched by
any other tasks - then everything is almost fine. But you just have to try
to run some application (for example, a leafpad), but at least just browse
Depending on what your application is doing, and your sampling rate, disk
I/O can also be a major factor too.
--Neel Pandeya
On Thu, Jul 26, 2018, 19:31 Neel Pandeya wrote:
> In general, CPU clock speed is more important.
>
> What sampling rate are you using?
>
> --Neel Pandeya
>
>
>
> On Thu,
In general, CPU clock speed is more important.
What sampling rate are you using?
--Neel Pandeya
On Thu, Jul 26, 2018, 19:27 Андрій Хома via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Perhaps a dumb question: what is more critical in order to avoid buffer
> overflows ("O")? Frequency, c
Perhaps a dumb question: what is more critical in order to avoid buffer
overflows ("O")? Frequency, cache size, or something else?
I dealt with two processors
1: 2.2GHz, 25MB cache
2: 3.5GHz, 15MB cache
In both cases, I observed overflows
4х usrp b205mini, through usb3.0
Thank you, Andrei.
__
this error occur when using my x310s but not when I run the
same code using my B-series hardware?
Thank you,
Adrian
Message: 15
Date: Sat, 15 Jul 2017 15:13:14 +0200
From: Marcus M?ller
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Overflows (D) when receiving nsamps more
r, if I modify it by simply duplicating
> the “recv_to_file” call or put it inside of a fore loop, I get an
> overflow (D) on every consecutive. I saw a previous post,
> “/[USRP-users] Overflows when doing repeated captures with X300
> <http://lists.ettus.com/pipermail/usrp-users_lis
run it with no
problem. However, if I modify it by simply duplicating the "recv_to_file" call
or put it inside of a fore loop, I get an overflow (D) on every consecutive. I
saw a previous post, "[USRP-users] Overflows when doing repeated captures with
X300<http
24 matches
Mail list logo
