Actually I have tried 1500, same errors. Is there a way to use PyBOMBS to create the RFNOC environment with a specified UHD version(3.14.0.0) instead of the default latest version (3.15)?
发件人: Marcus D Leech<mailto:patchvonbr...@gmail.com> 发送时间: 2019年7月28日 3:02 收件人: 汤 飞<mailto:retina...@hotmail.com> 抄送: Sam Reiter<mailto:sam.rei...@ettus.com>; usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> 主题: Re: 答复: [USRP-users] 答复: N310 "Bad CHDR or packet fragment" Problem Try adjusting the MTU as well to 1500. Sent from my iPhone On Jul 26, 2019, at 9:36 PM, 汤 飞 <retina...@hotmail.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:patchvonbr...@gmail.com>> 发送时间: Wednesday, July 24, 2019 7:34:13 AM 收件人: 汤 飞 <retina...@hotmail.com<mailto:retina...@hotmail.com>> 抄送: Sam Reiter <sam.rei...@ettus.com<mailto:sam.rei...@ettus.com>>; usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> <usrp-users@lists.ettus.com<mailto: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<mailto: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<mailto:sam.rei...@ettus.com>> 发送时间: Wednesday, July 24, 2019 4:56:21 AM 收件人: 汤 飞 <retina...@hotmail.com<mailto:retina...@hotmail.com>> 抄送: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> <usrp-users@lists.ettus.com<mailto: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<mailto: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<mailto: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<mailto: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
