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 > <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> 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 >> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> 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 >>> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> >>> 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, <mle...@ripnet.com >>>> <mailto:mle...@ripnet.com>> 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 >>>>> Discuss-gnuradio@gnu.org >>>>> <mailto:Discuss-gnuradio@gnu.org> >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>> >>> >> >> > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
