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

Reply via email to