Thanks for the feedback. I tried 3.13.0.2 this afternoon but still the same Rx timeout issues.
I’ll take a look at allocating more memory for the ethernet drivers. But the wireshark results still puzzle me. I’m getting timeouts even on low bandwidth collects (just as a test case of course). It seems like the FPGA is not sending all the packets to the 10Gbit IP or the IP is losing a packet somewhere. I took a look through the FPGA code but nothing jumped out – it all looked like it should work. Maybe there’s a race condition between some of the blocks? Unfortunately a lot of code has changed and been refactored since 3.10 so it’s hard to see where things went wrong. The number of releases in the last four months is more than what has been released in the last three years… From: Ali Dormiani <sdorm...@eng.ucsd.edu> Sent: Tuesday, September 4, 2018 10:17 PM To: Max Scharrenbroich <m...@sazetech.com> Cc: usrp-users@lists.ettus.com; rkoss...@nd.edu Subject: Re: [USRP-users] N310 timeouts on Rx... Which UHD version will make my N310 work? Here is my Lab's N310 experiance: 3.12 had your issue (2) 3.13.0.0 had bizarre TX behavior and lock ups that required a reboot or re-image. Our RX noise floor was also suspiciously high. 3.13.0.1 was no better 3.13.0.2 fixed all our problems. As long as we tell linux to allocate plenty of ram to the Ethernet driver we can transmit and receive with two channels simultaneously. I have not had the chance yet to test 4 TX to 4 RX yet. Over the past several months I have come to the conclusion that getting UHD or GNUradio from a package manager is more trouble than it is worth. If you compile UHD 3.13.0.2 from source and still have these RX timeout problems then I suppose this issue is out of reach for non-Ettus folks. On Tue, Sep 4, 2018 at 6:45 PM, Max Scharrenbroich via USRP-users <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote: This message is a continuation of the thread that Rob Kossler last added to regarding the timeouts on Rx for the N310 when using version 3.13 of the UHD. Note that we have not tested our X310s with this version - version 3.10 of the UHD works well with our system of X310s and we don’t see a need in changing. We found the same Rx timeout issues that Rob did while testing custom executables that have been robust using UHD version 3.10 for well over a year. We noticed that the problem occurs when receiving samples from multiple channels – a single channel seems to work as expected. As Rob pointed out the error can be easily replicated with the stock UHD examples. In our case we saw the errors when running rx_multi_samples with more than one channel. To dig into the underlying cause we installed WireShark and captured packets from the SDR<->host interface. Based on the collects it appears that there is always exactly one data packet missing. Setting the number of receive samples to something small (less than or equal to a packet size) results in N-1 packets being received on the interface, where N is the number of Rx channels specified. In an effort to work around the problem we tried hacking at super_recv_packet_handler.hpp to tell the SDR to send more packets than we actually want and ignore the timeout condition. This seems to work when receiving the first burst of samples (STREAM_MODE_NUM_SAMPS_AND_DONE) but subsequent issuing of stream commands turns the rx_stream into a train wreck. The ultimate problem we are having is that we cannot get our N310 to work with any of the versions of the UHD. Here are the issues: (1) Version 3.11 has an sdcard image that is corrupted and won’t allow our N310 to boot. (2) Version 3.12 does not accept the PID for the AD9371s (3) Version 3.13 has the Rx timeout issue. Questions: Can someone please recommend an exact version number that will allow us to use our N310 as we should expect it to? Or If the Rx timeout is a known issue can someone point us to a bug fix that we can implement locally? Thanks, Max Scharrenbroich Senior Principal Scientist SAZE Technologies, LLC _______________________________________________ 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
