No, my hypothesis is that backpressure from the USRP (meaning: the OFDM
Mapper block can't write samples to its output) leads to GNU Radio
having to drop messages between OFDM MAC and OFDM Mapper.
That backpressure could simply be caused by you producing more samples
per second than the USRP
The overflow warning occurs when the period parameter is set to 1 for a
pdu_length of 100. The rate is around 1.9e6. I am sorry but I didn't get
the point of this exercise. Were you trying to figure out the optimal value
of the buffer size ?
Abhinav PS Jadon
2012122
Electronics and
Just for clarification: use a new flow graph/disable everything but
these blocks; the point is to test how much we produce with that.
On 31.03.2016 10:13, Marcus Müller wrote:
> Hi Abhinav,
>
> On 31.03.2016 02:42, Abhinav Jadon wrote:
>> I ran the volk_profile just after the installation so that
Hi Abhinav,
On 31.03.2016 02:42, Abhinav Jadon wrote:
> I ran the volk_profile just after the installation so that is not an
> issue i guess. Also, I played around with the parameters of the
> message strobe ( the period parameter), it did have an effect on the
> underruns and the async message
I ran the volk_profile just after the installation so that is not an issue
i guess. Also, I played around with the parameters of the message strobe (
the period parameter), it did have an effect on the underruns and the async
message buffer overflow warning. Low values of the period parameter
Did you run volk_profile? That one tries out all volk kernels, and notes
down which one works best on your PC, so they'll be used automatically
the next time. Maybe that increases performance!
On 29.03.2016 22:24, Abhinav Jadon wrote:
> gcc version is 4.8.4
> cpuinfo output :
> flags: fpu
gcc version is 4.8.4
cpuinfo output :
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf eagerfpu pni
Abhinav,
I am not certain what to make of the asynch message buffer overflowing.
The __SSE2_MATH__, __SSE_MATH__, __SSE2__, __SSE__ defines are the SIMD
preprocessor defines. Can you run gcc --version and do cat /proc/cpuinfo |
grep flags? The former will indicate the gcc version number. The
Hi Alex ,
The output in the console was all 'U's before I disabled the WX/GUI blocks.
Now, it seems to run fine initially before throwing this message :
"WARN: asynchronous message buffer overflowing, dropping message"
>
The output of gcc -dM -E - < /dev/null | grep -e "SE" -e "AVX" was :
Abhinav,
When you run the flowgraph, can you look at system monitor? This will give
some indication whether the problem is that all the cores are pegged or if
RAM is filling up.
A couple of other things to look at:
1) Is there any text being printed to the console?
2) What happens if you disable
That's pretty much impossible to say.
My prime suspect would be the WX Gui visualization sink. Really, a
couple of 64 FFTs aren't that terrible performance-wise.
On 29.03.2016 20:53, Abhinav Jadon wrote:
> Marcus,
> Thanks for all the help.
> But Is my system underpowered ?
> Also, I just
Marcus,
Thanks for all the help.
But Is my system underpowered ?
Also, I just observed that if I bunch few blocks in the tx flowgraph in a
similar way as phy_hier block in the wifi_loopback flowgraph, I dont
receive any more underruns.
Regards
Abhinav PS Jadon
2012122
Electronics and
When you set the length tag field in the USRP sink, it starts looking
for that stream tag, which contains number of samples in the starting burst.
Technically, that starts a uhd::tx_streamer for a finite number of
samples, which means different things for different hardware.
Best regards,
Marcus
Hi Marcus,
I am working on a Core i7 8GB system, I dont know if its underpowered, if
it is I have access to another Corei5 16 GB station.
I know this is going to sound dumb but,
how does the USRP sink go into burst mode, I was under the impression that
USRP could only transmit data continuously.
Hi Abhinav,
my instantaneous diagnosis would be that your PC is simply too slow at
supplying samples. Incresing the rate of the strobe doesn't help -- the
USRP sink is in burst mode and as such, will not complain if it's
currently not sending samples. Underruns only happen if you're currently
Hi ,
I was working on the transmitter of gr-ieee80211. I will first explain my
setup and then go on to detail the problem.
Setup :
X310 (transmitter) -> SMA cable -> Attenuator -> SMA cable -> X310
(receiver)
The transmitter runs the wifi_tx.grc. The receiver runs the wifi_rx.grc
The tx gain was
16 matches
Mail list logo
