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 (ee.k...@gmail.com) 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 (i...@ionconcepts.com) 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 
<usrp-users@lists.ettus.com> 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
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Attachment: tx_timed_loop.cpp
Description: Binary data

_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to