Forum: GNU Radio Newbie question on unusually high latency when reading from msgq in oscilloscope example

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Rohan Narayana Murty (Guest)
on 2008-12-05 10:22
(Received via mailing list)
Attachment: usrp_modified_oscope.py (0 Bytes)
Attachment: modified_scopesink.py (0 Bytes)
Hello,

I am am new to the gnuradio system and I have a USRP1 board running
gnuradio-3.0.2 (I have a box that was setup with this older version).

I modified the usrp_oscope.py and scopesink.py code to run without the
gui
(files attached). I then decided to measure the time taken to retrieve a
message from the msgq. I find that the time taken (at a decimrate of
256,
128, or 64) to get a single msg from the msgq (using msgq.delete_head())
to be anywhere between 30 - 60ms. This seems to be particularly high. I
do
have USB 2.0 on my machine. I also tried this with different fusb_nlocks
and fusb_block_size params but I still get the same delay.

I have looked at the mailing list archive and I haven't really a post
with
the same issue.

Would anybody know why I might be seeing this error?

thanks,
Rohan
Johnathan C. (Guest)
on 2008-12-06 20:38
(Received via mailing list)
On Fri, Dec 5, 2008 at 12:22 AM, Rohan Narayana Murty
<removed_email_address@domain.invalid> wrote:

> I am am new to the gnuradio system and I have a USRP1 board running
> gnuradio-3.0.2 (I have a box that was setup with this older version).

There are numerous identified bugs in this release that have been
fixed along the way.  If possible, I'd recommend upgrading to the
latest stable release, 3.1.3.

> I modified the usrp_oscope.py and scopesink.py code to run without the gui
> (files attached). I then decided to measure the time taken to retrieve a
> message from the msgq. I find that the time taken (at a decimrate of 256,
> 128, or 64) to get a single msg from the msgq (using msgq.delete_head()) to
> be anywhere between 30 - 60ms. This seems to be particularly high. I do have
> USB 2.0 on my machine. I also tried this with different fusb_nlocks and
> fusb_block_size params but I still get the same delay.

This is not an error.  The flowgraph generates FFT vectors by default
at 15 frames per second.  This is every 66 ms.  Depending on whether
one is already in the message queue when you query it, you will get a
delay up to this amount of time.

-Johnathan
This topic is locked and can not be replied to.