Hi all, I think I may have identified the problem. See what you think.
I added a bit more info output to the tx_timed_loop.cpp test program (see attached) and made note of the time a packet is scheduled to go out versus the time the send loop completes. Keeping in mind that the loop runs as fast as it can, that is, it does not sleep for 10 ms, wake up, schedule a packet for 10 ms in the future, then sleep again, it’s interesting to see how fast it can schedule packets. If you look at the code in the attached, new version, specifically in the loop at the bottom, you can see I output the scheduled packet time at line 152, send the packet, then send a zero-length ending packet to signal the end of the burst. Then, depending on whether burstACK has been set, I read in the async message and process it according to status. Finally, at line 198 I get the current USRP time and output it. The packet is sent with a scheduled time which we assume is after the current USRP time. Thus, you’d expect the scheduled packet time to be larger than the current USRP time printed at line 198. For a sample rate of 20 MSps, here are the results burstACK device nsamps scheduled time - end of loop time (from USRP) false B200mini 10000 50,000 us (ahead) false B200mini 50000 8,000 us (ahead) true B200mini 10000 50,000 us (ahead) true B200mini 50000 8,000 us (ahead) false X310 10000 program dies with ’U’s false X310 50000 program dies with ’U’s true X310 10000 –800 us (behind) true X310 50000 –2700 us (behind) Just to be clear, “ahead” means that the loop finished before the packet’s scheduled Tx time. There are at least two take-aways: 1. The USB interface allows the B200mini to get packet data really quickly (50000 samples is 2.5 times longer than the longest packet I test with normally). Getting the async streamer message back from the B200mini effectively takes no time at all. It also appears that you don’t have to read the async streamer message for the B200mini to function properly. Compare that to what is noted below for the X310. 2. The X310, when the async message is read back (burstACK is true) lags badly. Even for 10,000 samples it only finishes the loop after the packet starts to go out. 50,000 samples should take 2.5 milliseconds to transmit at 20 MSps, but the loop only finishes 2.7 ms after transmission starts! Turning off the burstACK for the X310 just kills it. It never gets going and only a handful of packets appear on my scope. I have to assume that the X310 must need to have the async message read to reset something or other. Bear in mind all this is done with a normal, not-sync’d-to-gps Linux host, so the accuracy of the clock is not the issue. The X310 and B200mini are keeping relative time only. With the above in mind, seemed like a good idea to visit again the benchmark_rate example program. I ran it for the X310 and even with the tx rate set to 20 MSps I got an underflow. Bump up to 26 MSps and got several more. Had to drop all the way down to 10 MSps before no underflow happened. And this is for tx-only! The over the wire mode for benchmark_rate is sc16, so 32 bits per sample. So, with a 1GigE interface, you’d expect no better than 31.25 MSps. Indeed, benchmark_rate receive passes for 28.157 MSps, but not 33 MSps (clock dividers forces those two numbers). But like I say above, for Tx it seems there are always a couple of underflows just when it starts up. And that’s for continuous transmit, not bursts like I need to do. So, at least for my test setup, it appears that there is a significant communications bottleneck for the X310. The NIC appears to be working properly so I don’t think that’s the problem (i.e., the benchmark_rate works pretty much as expected). I am starting to wonder if the the X310 via Ethernet is just not able to support a burst packet-based system. Steven Knudsen, Ph.D., P.Eng. www. techconficio.ca www.linkedin.com/in/knudstevenknudsen All the wires are cut, my friends Live beyond the severed ends. Louis MacNeice On February 9, 2018 at 00:56:27, Steven Knudsen ([email protected]) wrote: Thanks, Ian. I appreciate the explanation. Certainly I’ve understood the idea of late as it was inevitable that while developing and testing my TDMA MAC I made mistakes and scheduled packets for transmission in the past :0) The underflow is a little more mysterious. At the request of Nate, a sensible person, I’ve created a program to illustrate the problem; see attached. Running it with the X310 connected to an Octoclock G for 1 PPS and 10 MHz, I have it transmit a 20000 sample packet every 10 ms at 20 MSps. It manages to do that for about 1727 seconds before underflow happens and then it basically blocks. Running it with a B200mini and all the same conditions/parameters, it has been going now for more than 8800 seconds. It is purely speculative on my part, but I have to wonder if somehow there is a time problem, say where the clock discipline algorithm of the X310 induces a jump in time. However, I made another test program where I get host and USRP time once every second and compare. Over the course of an hour for the X310 the time difference was pretty much constant, about the difference in time it takes to execute the get_time_now() command for the X310. So, that kind of suggests the clock is pretty stable, or maybe I didn’t wait long enough... I am kind of confident that the B200mini will keep going because, as mentioned below, it ran with the full Tx-Rx version of the program for more than 5 hours before I killed the program. Maybe you will be able to suggest something to help me get to the bottom of this :0) thanks! steven On February 8, 2018 at 23:57:57, Ian Buckley ([email protected]) wrote: Steven Underflow is a TX error phenomena, not an RX one. It is signaled when the local buffering of TX data in the USRP becomes empty whilst the USRP tries to continue to transmit. Late, on the other hand, is signaled when a TX command contains a time that is later than the USRP’s local clock when it is executed. Hope this is helpful, -Ian On Feb 8, 2018, at 1:33 PM, Steven Knudsen via USRP-users <[email protected]> wrote: Hi, I have been scratching my head for a while on this one… I have made a TDMA radio that has a simple 4 slot cycle with a relatively low duty cycle (slots are 40% and the remaining 60% of the cycle the USRP is idle). A radio transmits in it’s “owned” slot and receives in all others (3 of them). The transmit is timed as are the receptions in each slot. Transmit is schedule 10 ms in advance (at the start of a cycle) and the receives are scheduled at least 6 ms in advance (at the end of the last receive slot). When I test with a B200mini connected to an Octoclock G for 1 PPS reference, it runs flawlessly for hours (5 is the longest). When, on the exact same Linux host I run with an X310 connected to the same Octoclock G for 1 PPS and 10 MHz, it stops working after not too long with a slew of ’U’s and ’L’s Trying to narrow things down, I created a version fo the radio that only transmits. Reception is completely disabled and I confirm that no receive commands are ever scheduled and rxStreamer->recv() is never called. So, imagine my surprise when after a fairly long time of transmitting successfully (evidenced by using an oscilloscope to view packets), the transmit-only version fails!?! Below is a copy o the log showing the first evidence of failure, namely ’L’s indicating transmits were too late. But, what is the ‘U’ doing there? As I mentioned, no reception functionality is in the program, so what is going on? Anyone else see this kind of thing? I never see it with the B200mini, but see it consistently with the X310. thanks very much for your time and consideration, steven ULLsendFrame() MPDU #719935 mpdu size = 488 bytes at 1518123481s 890000 us ULLLsendFrame() MPDU #719936 mpdu size = 488 bytes at 1518123481s 900000 us ULLLLsendFrame() MPDU #719937 mpdu size = 488 bytes at 1518123481s 910000 us ULLLLLsendFrame() MPDU #719938 mpdu size = 488 bytes at 1518123481s 920000 us ULLLLLLsendFrame() MPDU #719939 mpdu size = 488 bytes at 1518123481s 930000 us ULLLLLLLsendFrame() MPDU #719940 mpdu size = 488 bytes at 1518123481s 940000 us ULLLLLLLLsendFrame() MPDU #719941 mpdu size = 488 bytes at 1518123481s 950000 us ULLLLLLLLLsendFrame() MPDU #719942 mpdu size = 488 bytes at 1518123481s 960000 us ULLLLLLLLLLsendFrame() MPDU #719943 mpdu size = 488 bytes at 1518123481s 970000 us ULLLLLLLLLLLsendFrame() MPDU #719944 mpdu size = 488 bytes at 1518123481s 980000 us ULLLLLLLLLLLLsendFrame() MPDU #719945 mpdu size = 488 bytes at 1518123481s 990000 us ULLLLLLLLLLLLLsendFrame() MPDU #719946 mpdu size = 488 bytes at 1518123482s 0 us ULLLLLLLLLLLLLsendFrame() MPDU #719947 mpdu size = 488 bytes at 1518123482s 10000 us ULLLLLLLLLLLLLLsendFrame() MPDU #719948 mpdu size = 488 bytes at 1518123482s 20000 us ULLLLLLLLLLLLLLLsendFrame() MPDU #719949 mpdu size = 488 bytes at 1518123482s 30000 us ULLLLLLLLLLLLLLLLsendFrame() MPDU #719950 mpdu size = 488 bytes at 1518123482s 40000 us ULLLLLLLLLLLLLLLLLsendFrame() MPDU #719951 mpdu size = 488 bytes at 1518123482s 50000 us ULLLLLLLLLLLLLLLLLLsendFrame() MPDU #719952 mpdu size = 488 bytes at 1518123482s 60000 us ULLLLLLLLLLLLLLLLLLLsendFrame() MPDU #719953 mpdu size = 488 bytes at 1518123482s 70000 us Steven Knudsen, Ph.D., P.Eng. www. techconficio.ca www.linkedin.com/in/knudstevenknudsen All the wires are cut, my friends Live beyond the severed ends. Louis MacNeice _______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
tx_timed_loop.cpp
Description: Binary data
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
