Tim Pearce wrote:
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,
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 Geiger
Code 5545
U.S. Naval Research Laboratory
Washington, DC 20375
(202) 767-9048
[email protected]
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
