Hi All,
I’ve modified the source to generate timesamples (as a seperate stream)
from
the USRP2 source blocks and noticed an issue - if the PC is struggling
some
frames have a timesample dated before the timesample of a frame
processed
before it.
It’s possible I’ve done something wrong modifying the code but I think
this
is a host issue as the problem is reduced (i.e it only happens at lower
decimation rates) on faster machines.
Has this been seen before? Are there any kernel options etc that might
improve this? I’d assumed the ethernet bit was a FIFO buffer of some
sort
but guess this isnt working quite right.
Tested on Ubuntu 9.04 (Jaunty).
Cheers,
Tim
Tim P. wrote:
Has this been seen before? Are there any kernel options etc that might
improve this? I’d assumed the ethernet bit was a FIFO buffer of some
sort but guess this isnt working quite right.
Tested on Ubuntu 9.04 (Jaunty).
Cheers,
Tim
Tim,
You’re taking the source and outputting a timestamp for each sample?
Are you taking the timestamp for the frame, and then just incrementing
according to decimation, until you get to a new frame then?
I haven’t noticed such peculiarities when I look at my timestamps - but
thus far I’m mainly looking just at the frame-by-frame timestamp.
Doug
–
Douglas G.
Code 5545
U.S. Naval Research Laboratory
Washington, DC 20375
(202) 767-9048
[email protected]
Hi Doug,
Yes for each sample its calculating the new sample value by adding the
decimation rate.
I’ll try this without the addition as it might reduce the processor load
and
can easily be post processed for the application I’m working on.
Cheers,
Tim
We’re checking timestamps on ethernet frames and everything seems fine
all the way up to 25 MHz over many hours of continuous data streaming.
At lower rates we’ve done several days of streaming without dropped
frames or conflicting timestamps.
juha