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
