Try adjusting the MTU as well to 1500
Sent from my iPhone > On Jul 26, 2019, at 9:36 PM, 汤 飞 <retina...@hotmail.com> wrote: > > FYI > > ifconfig > enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 8000 > inet 192.168.10.1 netmask 255.255.255.0 broadcast 192.168.10.255 > inet6 fe80::96c6:91ff:febd:e8bb prefixlen 64 scopeid 0x20<link> > ether 94:c6:91:bd:e8:bb txqueuelen 1000 (Ethernet) > RX packets 3352 bytes 2274650 (2.2 MB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 2926 bytes 246527 (246.5 KB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 > inet 127.0.0.1 netmask 255.0.0.0 > inet6 ::1 prefixlen 128 scopeid 0x10<host> > loop txqueuelen 1000 (Local Loopback) > RX packets 369 bytes 29489 (29.4 KB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 369 bytes 29489 (29.4 KB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > wlx3c46d8d7c86c: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > inet 192.168.0.208 netmask 255.255.254.0 broadcast 192.168.1.255 > inet6 fe80::b8b3:bda6:dd2a:206f prefixlen 64 scopeid 0x20<link> > ether 3c:46:d8:d7:c8:6c txqueuelen 1000 (Ethernet) > RX packets 1043 bytes 822132 (822.1 KB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 873 bytes 119925 (119.9 KB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >> On 2019/7/27 上午1:17, Sam Reiter wrote: >> Can you post the output of ifconfig on your system? >> >> Sam Reiter >> SDR Support Engineer >> Ettus Research >> >> >>> On Thu, Jul 25, 2019 at 7:40 PM 汤 飞 <retina...@hotmail.com> wrote: >>> Thanks! >>> >>> I am learning to use RFNOC to integrate a baseband. So I used PyBOMBS to >>> create the environment. The automatically installed UHD version is as >>> follows >>> >>> uhd_find_devices >>> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; >>> UHD_3.15.0.git-19-g7e1b567d >>> -------------------------------------------------- >>> -- UHD Device 0 >>> -------------------------------------------------- >>> Device Address: >>> serial: 3182B09 >>> addr: 192.168.10.2 >>> claimed: False >>> mgmt_addr: 192.168.1.151 >>> mgmt_addr: 192.168.10.2 >>> product: n310 >>> type: n3xx >>> >>> But how to add to the device arguments? I tried like this but not working >>> >>> /usr/local/lib/uhd/examples/rx_ascii_art_dft --args >>> "master_clock_rate=125e6,mgmt_addr=192.168.1.151,recv_frame_size=1476,addr=192.168.10.2" >>> --freq 98.5e6 --rate 2.5e6 --gain 50 --ref-lvl="-50" --dyn-rng 90 --ant >>> "RX2" --subdev "A:0" >>> >>> >>> >>> >>>> On 2019/7/26 上午5:17, Sam Reiter wrote: >>>> Found the offending commit and reported the issue. It also looks like >>>> adding recv_frame_size=1476 explicitly to the device arguments cleared >>>> things up on my N310 running 3.14.1.0. Let me know if this does / doesn't >>>> work for anyone. >>>> >>>> Sam Reiter >>>> SDR Support Engineer >>>> Ettus Research >>>> >>>> >>>>> On Thu, Jul 25, 2019 at 3:04 PM Marcus D. Leech <patchvonbr...@gmail.com> >>>>> wrote: >>>>>> On 07/25/2019 03:56 PM, Sam Reiter wrote: >>>>>> Follow up on this thread. I ran my N310 with a 1GbE link and was able to >>>>>> reproduce the "Bad CHDR or packet fragment issue". It seems specific to >>>>>> N3xx RX over a 1GbE link on 3.14.1.0. I didn't spend a ton of time >>>>>> trying to find a workaround on 3.14.1.0, but rolling back to 3.14.0.0 >>>>>> cleared the issue for me. >>>>>> >>>>>> I'll spend some time finding the offending commit and see what I can't >>>>>> do to get a fix / workaround figured out for 3.14.1.0. >>>>>> >>>>>> Sam Reiter >>>>>> SDR Support Engineer >>>>>> Ettus Research >>>>>> >>>>> Thanks, Sam. When I go into the lab later, I can probably confirm this >>>>> as well, I haven't seen it before, but I think I'm runing 3.14.0.0 >>>>> >>>>> >>>>>>> On Tue, Jul 23, 2019 at 10:13 PM Marcus D Leech >>>>>>> <patchvonbr...@gmail.com> wrote: >>>>>>> Normally Intel controllers have better performance but even a RealTek >>>>>>> chip should have no problem at those data rates. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>> On Jul 23, 2019, at 10:01 PM, 汤 飞 <retina...@hotmail.com> wrote: >>>>>>> >>>>>>>> Actually my pc’s Ethernet card chip is from Realtek. >>>>>>>> >>>>>>>> I’ve tried all possible MTU sizes of auto, 1000, 1500, 2000, and up to >>>>>>>> 9000. Always the same errors. >>>>>>>> >>>>>>>> Is it the inherent problem with the Realtek chip? >>>>>>>> >>>>>>>> If that, is there any workaround? eg. Changing the default Linux >>>>>>>> driver, >>>>>>>> >>>>>>>> or the last solution, ie. I have to try install a PCIE network card. >>>>>>>> Which brand ethernet card is compatible, one from Intel? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 发件人: Marcus D Leech <patchvonbr...@gmail.com> >>>>>>>> 发送时间: Wednesday, July 24, 2019 7:34:13 AM >>>>>>>> 收件人: 汤 飞 <retina...@hotmail.com> >>>>>>>> 抄送: Sam Reiter <sam.rei...@ettus.com>; usrp-users@lists.ettus.com >>>>>>>> <usrp-users@lists.ettus.com> >>>>>>>> 主题: Re: [USRP-users] 答复: N310 "Bad CHDR or packet fragment" Problem >>>>>>>> >>>>>>>> Some Ethernet 1g controllers won’t actually do MTUs greater than 1500 >>>>>>>> despite ethnology telling them to. Some Realtek for example. >>>>>>>> >>>>>>>> If it’s just 1G try default MTU of 1500 and work your way up to see >>>>>>>> where it fails. >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Jul 23, 2019, at 7:15 PM, 汤 飞 via USRP-users >>>>>>>> <usrp-users@lists.ettus.com> wrote: >>>>>>>> >>>>>>>>> It’s a 1g SFP0 link. I set MTU to 8000 according to the Application >>>>>>>>> Note. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 发 件人: Sam Reiter <sam.rei...@ettus.com> >>>>>>>>> 发送时间: Wednesday, July 24, 2019 4:56:21 AM >>>>>>>>> 收件人: 汤 飞 <retina...@hotmail.com> >>>>>>>>> 抄送: usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> >>>>>>>>> 主题: Re: [USRP-users] N310 "Bad CHDR or packet fragment" Problem >>>>>>>>> >>>>>>>>> If you're connected over a 10GbE link, make sure to set your host's >>>>>>>>> MTU appropriately. I set mine to 9000. >>>>>>>>> >>>>>>>>> Sam Reiter >>>>>>>>> SDR Support Engineer >>>>>>>>> Ettus Research >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Fri, Jul 19, 2019 at 2:21 AM 汤 飞 via USRP-users >>>>>>>>>> <usrp-users@lists.ettus.com> wrote: >>>>>>>>>> Hi, all, >>>>>>>>>> >>>>>>>>>> When benchmarking my N310, I keep getting such [RX FLOW CTRL] >>>>>>>>>> errors. >>>>>>>>>> What causes this and how to solve it? >>>>>>>>>> >>>>>>>>>> Thanks in advance! >>>>>>>>>> >>>>>>>>>> FT >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> /usr/local/lib/uhd/examples/benchmark_rate \ >>>>>>>>>> > --args >>>>>>>>>> > "type=n3xx,mgmt_addr=192.168.10.2,addr=192.168.10.2,master_clock_rate=122.88e6" >>>>>>>>>> > \ >>>>>>>>>> > --duration 60 \ >>>>>>>>>> > --channels "0" \ >>>>>>>>>> > --rx_rate 3.84e6 \ >>>>>>>>>> > --rx_subdev "A:0" \ >>>>>>>>>> > --tx_rate 3.84e6 \ >>>>>>>>>> > --tx_subdev "A:0" >>>>>>>>>> >>>>>>>>>> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; >>>>>>>>>> UHD_3.14.1.HEAD-0-gbfb9c1c7 >>>>>>>>>> [00:00:00.000014] Creating the usrp device with: >>>>>>>>>> type=n3xx,mgmt_addr=192.168.10.2,addr=192.168.10.2,master_clock_rate=122.88e6... >>>>>>>>>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: >>>>>>>>>> mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=3182B09,claimed=False,addr=192.168.10.2,master_clock_rate=122.88e6 >>>>>>>>>> [INFO] [MPM.PeriphManager] init() called with device args >>>>>>>>>> `master_clock_rate=122.88e6,time_source=internal,clock_source=internal,mgmt_addr=192.168.10.2,product=n310'. >>>>>>>>>> [INFO] [0/Replay_0] Initializing block control (NOC ID: >>>>>>>>>> 0x4E91A00000000004) >>>>>>>>>> [INFO] [0/Radio_0] Initializing block control (NOC ID: >>>>>>>>>> 0x12AD100000011312) >>>>>>>>>> [INFO] [0/Radio_1] Initializing block control (NOC ID: >>>>>>>>>> 0x12AD100000011312) >>>>>>>>>> [INFO] [0/DDC_0] Initializing block control (NOC ID: >>>>>>>>>> 0xDDC0000000000000) >>>>>>>>>> [INFO] [0/DDC_1] Initializing block control (NOC ID: >>>>>>>>>> 0xDDC0000000000000) >>>>>>>>>> [INFO] [0/DUC_0] Initializing block control (NOC ID: >>>>>>>>>> 0xD0C0000000000002) >>>>>>>>>> [INFO] [0/DUC_1] Initializing block control (NOC ID: >>>>>>>>>> 0xD0C0000000000002) >>>>>>>>>> [INFO] [0/FIFO_0] Initializing block control (NOC ID: >>>>>>>>>> 0xF1F0000000000000) >>>>>>>>>> [INFO] [0/FIFO_1] Initializing block control (NOC ID: >>>>>>>>>> 0xF1F0000000000000) >>>>>>>>>> [INFO] [0/FIFO_2] Initializing block control (NOC ID: >>>>>>>>>> 0xF1F0000000000000) >>>>>>>>>> [INFO] [0/FIFO_3] Initializing block control (NOC ID: >>>>>>>>>> 0xF1F0000000000000) >>>>>>>>>> Using Device: Single USRP: >>>>>>>>>> Device: N300-Series Device >>>>>>>>>> Mboard 0: ni-n3xx-3182B09 >>>>>>>>>> RX Channel: 0 >>>>>>>>>> RX DSP: 0 >>>>>>>>>> RX Dboard: A >>>>>>>>>> RX Subdev: Magnesium >>>>>>>>>> TX Channel: 0 >>>>>>>>>> TX DSP: 0 >>>>>>>>>> TX Dboard: A >>>>>>>>>> TX Subdev: Magnesium >>>>>>>>>> >>>>>>>>>> [00:00:17.353184] Setting device timestamp to 0... >>>>>>>>>> [00:00:17.412187] Testing receive rate 3.840000 Msps on 1 channels >>>>>>>>>> [00:00:17.414164] Receiver error: ERROR_CODE_BAD_PACKET >>>>>>>>>> [[ERROR] [RX FLOW CTRL] Error unpacking packet: ValueError: Bad CHDR >>>>>>>>>> or packet fragment >>>>>>>>>> >>>>>>>>>> [ERROR] [STREAMER] The receive packet handler caught a value >>>>>>>>>> exception. >>>>>>>>>> ValueError: Bad CHDR or packet fragment >>>>>>>>>> 00:00:17.414180] Unexpected error on recv, continuing... >>>>>>>>>> [00:00:17.514258] Receiver error: ERROR_CODE_TIMEOUT, continuing... >>>>>>>>>> [00:00:17.514312] Receiver error: ERROR_CODE_BAD_PACKET >>>>>>>>>> [00:00:17.514317] Unexpected error on recv, continuing... >>>>>>>>>> [ERROR] [RX FLOW CTRL] Error unpacking packet: ValueError: Bad CHDR >>>>>>>>>> or packet fragment >>>>>>>>>> >>>>>>>>>> [ERROR] [STREAMER] The receive packet handler caught a value >>>>>>>>>> exception. >>>>>>>>>> ValueError: Bad CHDR or packet fragment >>>>>>>>>> [00:00:17.532991] Testing transmit rate 3.840000 Msps on 1 channels >>>>>>>>>> [00:00:17.614329] Receiver error: ERROR_CODE_TIMEOUT, continuing... >>>>>>>>>> [00:00:17.614372] Receiver error: ERROR_CODE_BAD_PACKET >>>>>>>>>> [00:00:17.614377] Unexpected error on recv, continuing... >>>>>>>>>> _______________________________________________ >>>>>>>>>> USRP-users mailing list >>>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>> _______________________________________________ >>>>>>>>> USRP-users mailing list >>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
