Hi Stefan, so I've talked to our main software sustainance hero, and we rather quickly came to the conclusion that it's pretty likely you should move on to the head of the 3.13 branch (remotes/origin/UHD-3.13). Are you building from source, or are you using binary packages?
Best regards, Marcus On Mon, 2018-09-24 at 20:04 +0200, Marcus Müller wrote: > Hi Stefan, > > I know it's not of great comfort when an engineer finds a problem to > be > /interesting/, but yours certainly is. > So, first things first: if the computational power and memory of the > host that your USRP is connected to allows, it might be good to have > a > packet capture in some kind of a ring buffer, so that you can infer a > bit on the state at the point where things go wrong: > > tcpdump -n # no DNS lookups > -i <your network device here> > -s 0 # don't stop after a finite amount of packets > -C 400 # 400 million bytes per capture file > -W 2 # rotate through three files of capturs > -w /tmp/rotate.pcap # make sure that you're using a file that's on an > RAM filesystem; if in doubt, make one with `mount -t tmpfs tmpfs > /path` > > So, yes, using an MTU of 8000 would be the first thing that the Ettus > hivemind would recommend, too, but if you say things still go wrong, > we > might need to dig deeper. > > I do know that we've improved the bus clocking, and that had impact > on > the X300 firmware. Is trying the last 3.10 release an option for you? > > Best regards, > Marcus > > On Mon, 2018-09-24 at 09:23 +0200, Stefan van der Linden via USRP- > users > wrote: > > Hi, > > > > We are in the process of prototyping a setup using an X300 with two > > UBX-40 daughterboards to be used in the validation of an externally > > provided signal source. The daughterboards are each dedicated to > > one > > of two tasks: transmitting a pre-recorded reference signal in a > > loop > > at 50 MSps, and capturing that same signal again after passing > > through a chain of devices under test at 25MSps. This is to run > > continuously up to 24 hours. > > > > The X300 is connected to the (dedicated) host computer via a 10Gbps > > connection to an Intel X520-DA2 NAC over SFP+. On the host, we are > > currently using the kitchen_sink utility included with UHD to run > > the > > system in multi-channel mode. We are using UHD 3.11.0.1. > > > > The system works flawlessly when performing short measurements > > (say, > > up to an hour or so). However, having recently started setting up > > the > > system for long 24 hour tests, we are seeing timeouts from which > > UHD > > is unable to recover. These timeouts occur randomly: sometimes they > > occur after ~1 hours, other times they occur after ~18 hours and > > everywhere in between. Naturally, this random behaviour makes it > > difficult to debug. > > > > The error message retrieved from UHD is as follows: > > > > As previous messages on this list have mentioned varying the MTU > > settings (for example: > > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/039561.html > > ), this was the first thing we tried. Unfortunately, these timeouts > > occur more often at lower MTU values. > > > > Hopefully someone is able to point us in the right direction. > > Perhaps > > we are dealing with hardware issues here, but I'd I hope we are > > able > > to solve this through software. > > > > Thanks, > > Stefan van der Linden > > _______________________________________________ > > USRP-users mailing list > > [email protected] > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > _______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
