Re: [Discuss-gnuradio] USRP N200 Overflow (printing D) when using a new Intel NUC

[Marcus D. Leech]

On 07/27/2018 12:15 AM, Ting Wu wrote:
> Hi Marcus,
>
> Thank you for your prompt response.
>
> I had a look at the datasheet of the new NUC 
> (https://www.intel.com/content/dam/support/us/en/documents/boardsandkits/NUC7i5BN_NUC7i7BN_TechProdSpec.pdf), 
> and it seems that it uses Intel I219V Ethernet controller rather than 
> 82579LM as you mentioned.
>
> I also looked at the datasheet of the old NUC which worked fine, and 
> it was using Intel I218-V Ethernet controller.
>
> Does this mean the I219V is also bad as the 82579LM?
Certainly possible.

Have you followed the recommendations about tweaking network-stack 
buffer sizes, shown here:

https://files.ettus.com/manual/page_transport.html#transport_udp


> Ting
>
>
> On 2018/07/27 12:00, Marcus D. Leech wrote:
> > On 07/26/2018 10:53 PM, Ting Wu wrote:
> > > Hi!
> > >
> > > I have been using USRP N200 (with LFRX daughterboard) with an Intel 
> > > NUC (BOXNUC5I5RYH) for quite a long time, and everything has been 
> > > working well.
> > >
> > > Recently I purchased a new NUC of a recent version (BOXNUC7I5BNK), 
> > > and the overflow problem (printing D) occurred.
> > >
> > > So I made a test. I installed Ubuntu 17.10 on both the old and the 
> > > new NUCs, and installed exactly the same software. Then I tested 
> > > these two NUCs with the same USRP and confirmed that the overflow 
> > > problem only occurs with the new NUC.
> > >
> > > I made a simple script for the test as shown in the attached figure. 
> > > With the new NUC, the letter D is printed once in a while as shown 
> > > below:
> > >
> > > -----------------------------------Output-------------------------------------------- 
> > >
> > > linux; GNU C++ version 6.2.0 20161027; Boost_106200; 
> > > UHD_003.009.005-0-unknown
> > >
> > > -- Opening a USRP2/N-Series device...
> > > -- Current recv frame size: 1472 bytes
> > > -- Current send frame size: 1472 bytes
> > > -- Detecting internal GPSDO.... Found an internal GPSDO: 
> > > Jackson-Labs, FireFly , Firmware Rev 0.929
> > > -- Setting references to the internal GPSDO
> > > 1532658018 3595
> > > 1532658019 3362
> > > 1532658020 2861
> > > D1532658021 666
> > > 1532658022 587
> > > 1532658023 722
> > > 1532658024 780
> > > 1532658025 477
> > > 1532658026 703
> > > DD1532658027 759
> > > 1532658028 553
> > > 1532658029 618
> > > 1532658030 581
> > > 1532658031 474
> > > ----------------------------------------------------------------------------------------------- 
> > >
> > >
> > > With the old NUC, there is no overflow at all.
> > >
> > > So it seems the overflow problem is associated with the hardware of 
> > > the new NUC (BOXNUC7I5BNK). My question is that is there any method 
> > > to avoid this overflow problem? If I have to drop this new NUC, what 
> > > part of the NUC is causing this problem and what types of PCs may 
> > > have the same problem and I should avoid in the future?
> > >
> > > Thanks in advance!
> > >
> > > Ting Wu
> > The Intel 82579LM Ethernet chip is known to have serious issues with 
> > dropping frames from time to time, and we've seen this type of behavior
> >   with 82579LM on motherboards.
> >
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio