Re: [Discuss-gnuradio] Overflow error in benchmark receiver side "DDDD"

[Marcus Müller]

Hi Monika,

that is a very ubiquitous chipset, and it works well – if I remember correctly, it can't do interrupt coalescing, though, so your CPU might take quite a hit at high rates. Still, you should see Overflows before your system drops packets.
Have you tried to enlarge the RX buffers as mentioned on our transport manual page?

Another thing to try: disabling firewalling on the USRP interface. I don't recommend this regularly, because I don't like to meddle with people's security mechanisms, but if you are careful, there's no danger in trying:

<disconnect all but the USRP, in order not to expose an un-firewalled system to a network>
sudo iptables-save > backup
sudo iptables -F ## This flushes all tables, i.e. all packets are passed through unfiltered.
<do your testing>
sudo iptables-restore < backup ## old settings


Best regards,
Marcus

On 04/18/2016 06:53 PM, monika bansal wrote:

Hi Marcus,

Exact model is RTL8111/8168/8411 and vendor is Realtek Semiconductor Co., ltd.

OS: Ubuntu 14.04

Regards,

Monika

On Sat, Apr 16, 2016 at 10:27 PM, Marcus Müller <address@hidden> wrote:

Hm, those are usually good. What's the exact model ("lspci" will tell)? What's your OS?

On 16.04.2016 18:10, monika bansal wrote:

Hi Marcus

The network card is PCI Express Gigabit Ethernet Controller with 1Gbps capacity.

Thanks,

Monika

On Fri, Apr 15, 2016 at 6:38 PM, Marcus Müller <address@hidden> wrote:

No harm done :) So the point is that DDDD is still pretty bad, and usually shouldn't happen, unless your PC is *much* too slow, and usually would be preceeded by a couple of "O".
There's two cases where this doesn't happen:
* Too small network buffers
* strangely misbehaving network hardware.

So: what is your network card?

Best regards,
Marcus

On 15.04.2016 14:32, monika bansal wrote:

Yes my mistake :). Sorry for that. I just did not think of the python block at that time and then after i realized.

Regards,

Monika

On Fri, Apr 15, 2016 at 5:17 PM, Marcus Müller <address@hidden> wrote:

Monika,

no offense, but when you report a problem with software, it's pretty crucial you point out whether you've modified the software or not :)

Best regards,
Marcus

On 15.04.2016 06:28, monika bansal wrote:

Hii,

Thank you for your help. 

That "DDDD" issue is not coming with original benchmark files.

I added one python block in between the chain in benchmark code. I think due to which it was not fast enough to process the incoming data resulting "DDDD" issue.

Regards,

Monika

On Tue, Apr 5, 2016 at 11:51 PM, <address@hidden> wrote:

What if you make the file "/dev/null" -- does this still happen?

 

 

 

On 2016-04-05 14:12, monika bansal wrote:

Hii,

I am running benchmark code and on the receiver side after receiving some number of packets(8000 so), it starts showing overflow errors ("DDDD") on terminal.
Following is the system configuration

python benchmark_rx.py -f 1100M --args "addr=10.32.38.163" --to-file=/home/ashokbandi/GNU/a_rx.txt --bandwidth=500000

Decreasing the bandwidth delays the error.

 

I tried changing buffer size by setting net.core.rmem_max and net.core.wmem_max to 33445532 but to no avail.

Following is the screen shot of terminal

DDok: True      pktno: 24116      n_rcvd: 9730      n_right: 9723
DDDDDDDDok: True      pktno: 24182      n_rcvd: 9731      n_right: 9724
DDDDDDDDDDDDDDok: True      pktno: 24319      n_rcvd: 9732      n_right: 9725
DDDDDDDDDDDDDDDDok: True      pktno: 24442      n_rcvd: 9733      n_right: 9726
DDDok: True      pktno: 24477      n_rcvd: 9734      n_right: 9727
DDDDDDDDDok: True      pktno: 24568      n_rcvd: 9735      n_right: 9728
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDok: False      pktno: 22729      n_rcvd: 9736      n_right: 9728

Thanks

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio