On Mon, Aug 1, 2011 at 6:46 PM, Thomas Tsou
<address@hidden> wrote:
On Mon, Aug 1, 2011 at 1:16 AM, Andre Puschmann
> I am afraid I can't get you the raw latency as we mainly did high-level
> measurements on layer two and seven (using the ping command). So this
> involves much more that just the connection between host and RF
> frontend. For a standard ping test between two devices we look at a RTT
> between 7-8ms (1Msamples/s, BPSK).
It's worth clarifying that the numbers I posted were for quite the
opposite case. The microsecond level USRP latency was a combination of
interrupt latency and one-way USB transfer time for a minimally sized
burst; the elapsed time from the leading edge of a trigger signal to
the leading edge of the response pulse.
What I ultimately concluded was that it was possible to sync multiple
USRP1 transmissions from a single host-based trigger up to a level of
jitter in the 10's of microseconds. Of course there were some
limitations. The transmitted bursts were pre-generated so processing
was minimal. Despite that, the processors were set for maximum
performance so it was hardly an efficient use of resources.
Thomas
So I figured out the main sources of the delay, and I figured I should tell the rest of the community. Thanks for all your inputs and advice, list!!!
For my particular application, I am transmitting and receiving at the same time. As I receive, I will adjust my transmit signal accordingly. HOWEVER, the issue is that GNURadio/UHD (maybe libUSB as well?) maintain a large buffer of stored samples to be sent out to the USRP. GNURadio simply tries to stuff as many samples as possible into this buffer without overflowing it. My use case is a bit weird compared to other SDR applications.
Since this buffer exists outside of the GNURadio land (either UHD or libUSB land) my updated transmit signal always ended up at the back end of it. Hence, the massive delay. I was able to mitigate some of it by increasing the transmit sample rate and decreasing the libUSB block size.
I believe the best solution is be able to insert my samples directly in the front of the libUSB (or UHD) buffer; if I want sub-millisec turn around time. For what I have now, it seems OK for the time being. Eventually I want to hit latency in the order of less than a millisecond.