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
