On 11/8/06, Eric Blossom <[EMAIL PROTECTED]> wrote:
On Wed, Nov 08, 2006 at 03:14:01PM -0800, Thomas Schmid wrote: > I set the fusb buffering for the square wave test, additional to > setting real time scheduling. The result is similar. For different > decimation factors I get delays. What I didn't notice before is the > following: Now, the delay increases with higher decimation factor and > it looks almost linear, i.e., if I double the decimation factor, the > delay increases by a factor of two. Does that make sense?Absolutely ;) In your test case the ultimate flow control is the speed of transfer across the USB. This is determined by the decimation factor. The siggen block is going to run as fast as it can and *WILL* fill up all available buffering downstream from it. If your test case is a gr.sig_source followed by the USRP, I would expect that the runtime system would have allocated 32kB of buffering between the sig_source and the usrp sink. gr_complex 32kB * ---------- = 4096 complex samples 8 bytes That's the buffering between the sig_source output and the usrp input. That amount is constant (and known). Note that if the sig_source wasn't flow controlled by the usrp consumption rate, the buffer would not be full. So, you've got a 4096 sample fixed delay (probably actually 4095) between the output of the sig_source. You know your data rate across the USB, and thus can subtract off the constant delay. Also, the usrp.sink_c sets it's output_multiple to 128 samples, so it's always going to wait until there's at least 128 complex samples available before it runs (that's 1 full USB packet).
I am actually using the short sink. But I assume this doesn't change the concept and just changes the amount of samples in the buffers.
> I don't really understand that behavior, since I assumed that the > delay should be constant. It is, in samples. Hope this helps. Note that if you're not flow controlled (the typical case with discontinuous transmission), you'll get a better measure. You could test this with a source that returned 0 for noutput items, except that every N seconds, it toggled the parallel port lines and then produced its burst of output.
Ah, this explains the differences in the delays from the packet source tests I did earlier. It does make sense now.
You'll want to be sure to calibrate out the time to wiggle to parallel port lines. I'm assuming you're doing it with a direct iob to the parallel port control or data registers.
Yes, I am using iob. The parallel port delay is supposedly 1us, i.e., I can toggle the parallel ports at the speed of the bus it is connected to, which is apparently around 1MHz. This delay is so small, compared to the USRP delays, that I didn't factor it in (yet). So, just to make sure that I understood your explanation. The USB bus speed is set by the interpolation factor (sorry, I used decimation before, though this is the case when we receive, not send. My fault...). The buffer before the USB driver is filled all the times by our signal source. And this buffer is emptied at the set USB speed. Thank you very much, Eric. Your explanation was very helpful. Thomas _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
