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

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
>> 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


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio