<div dir="ltr"><div><div><div>Yes, 50MB is the default size for N200.<br><br></div><div>I do not believe you will see any benefit by increasing the recv_frame_size, but you increasing the num_recv_frames and recv_buff_size may help.<br></div><br></div>I really think the problem you are having is that all interrupts are being handled by a single core.  If that is the case, enabling Receive Side Scaling will probably make the biggest difference.  Keep in mind that Receive Side Scaling needs to be enabled in the OS, the NIC needs to support it, and it needs to be enabled on the NIC.<br><br></div>Regards,<br>Michael<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 10, 2014 at 1:10 AM, Damien Serant <span dir="ltr"><<a href="mailto:damien.serant@gmail.com" target="_blank">damien.serant@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><p dir="ltr">Many thanks for the quick response.<br>
 Which value do you suggest me for the recv_buff_size ? I read that the default value was 50Mo, do you confirm ?<br></p>Is there an interest to change also with the recv_frame_size value ?<br><br><p dir="ltr">Thanks</p><span class="HOEnZb"><font color="#888888">
<p dir="ltr">Damien</p></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2014-12-10 1:20 GMT+01:00 Michael West <span dir="ltr"><<a href="mailto:michael.west@ettus.com" target="_blank">michael.west@ettus.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>That sounds like an OS issue to me.  A few things to try:<br><br>- Enable Receive Side Scaling (if not already enabled)<br>- Increase the size of the receive socket buffer<br></div></div>- Disable all power management (may be throttling CPU cores)<br></div><div>- Use a single Ethernet connection (reduce the number of network interrupts)<br></div><div><br></div><div>Hardware interrupts trump all software, so changing priority will not matter if there are more hardware interrupts to process than can be processed (i.e. from the NIC and mouse).  A good test is to see how much kernel activity there is on each core when shaking the console window and running UHD.  If there is a concentrated kernel load on a single core, that is a good indication that all interrupts are being handled by a single core and that is why packet processing is being delayed.  Enabling Receive Side Scaling will spread the network interrupts among the cores and increasing the socket buffer will give more time to process the interrupts.<br></div><div><div><div><br>Regards,<br>Michael E. West<br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Dec 9, 2014 at 2:59 PM, Damien Serant via USRP-users <span dir="ltr"><<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div><div><div><div><div>Hi list,<br><br></div>I'm trying to push the USRPN200 to the limit in throughput and I experienced a quite strange underflow behavior.<br></div>Here is my configuration : <br><ul><li>2USRPN200 with Mimo cable, 25MHz and 8 bit on each with 2 Ethernet to avoid saturation of the link<br></li><li>Intel Xeon processor with 6 core (12 Threads)</li><li>Windows 7 Pro 64 bit<br></li></ul>My UHD program is only reading samples without any processing (not even disk writing). If i do nothing else on the PC, the program work without any packet loss with a very limited CPU charge of about 5% (about 20% on two cores) according to the task manager and for at least 30 minutes (the longest test that i made). As soon as i start soliciting a bit the CPU (e.g. opening another application, or simply by moving the scroll bar of the console up and down or shaking the console window) underflows and packet losses arise. I tried to play with the process priority but the result is the same.<br></div><div><br>The underflows are apparently due to an increased CPU charge but with only 5% of CPU usage for my UHD program i should not expect that, no ? <br></div>Does anyone already experienced that ?<br></div>Is there some tricks in the OS configuration or in UHD configuration to avoid that ?<br><br></div>Thanks in advance,<br><br></div>Damien<br></div>
<br></div></div>_______________________________________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>