Re: [Discuss-gnuradio] usrp_basic_rx::stop appears to take a long time, and reading after stop always returns > 0 bytes

[Eric Blossom]

On Tue, May 29, 2007 at 07:04:26PM -0700, Dave Gotwisner wrote:
> Eric Blossom wrote:
> 
> The software is running ubuntu linux with the hard drive being an NFS 
> mount.  I am not writing any of the data to disk, so the disk I/O / 
> network I/O should essentially be limited to output across telnet back 
> to my host (another linux running VNC), and any demand paging that the 
> program is doing.  Running or not running oprofile makes no difference, 
> the load average hovers between 0.00 and 0.10.  My program consumes at 
> most 20% of the cpu.

> The ext2/3 stuff was with respect to someone elses query, not mine.  I 
> spent today trying to get to the bottom of start/stop timings and only 
> spent about an hour on the overruns.  If you think putting the code on a 
> EXT2 fs vs a network fs will make a difference, I will do so, but, I 
> doubt it, since I am not writing to disk.

OK, sorry, confused two sets of issues.

> >That's what real time scheduling is for.  Increasing the total buffersize
> >increases the worst case latency that you have to account for if you
> >leave everything running.  Hence our choice of smaller values.
> >
> >   # Attempt to enable realtime scheduling
> >   r = gr.enable_realtime_scheduling()
> >   if r == gr.RT_OK:
> >       realtime = True
> >   else:
> >       realtime = False
> >       print "Note: failed to enable realtime scheduling"
> >
> >In C++ it's called gr_enable_realtime_scheduling().
> >See gr_realtime.h
> > 
> >
> I'll pursue this more tomorrow.

Good.  That should keep the usrp from being shut out by the X-server, etc.

> >>The amount of CPU resource we need should be out of the 
> >>available CPU after other things run, rather than as the highest 
> >>priority task.  From calculations based upon your proposed buffering, I 
> >>get (4096*16)/32 MB/s) = ~2 milliseconds of buffering, we feel we need a 
> >>minimum of about 50 milliseconds of buffering, hence the large numbers 
> >>for fusb_block_size.
> >>
> >>FYI, I tried building the trunk code on my ubuntu box, and when I did 
> >>the "./configure" command,
> >>   
> >>
> >
> >did you do a ./bootstrap first?
> > 
> >
> 
> Yes.  I did everything as me, not as root, though, if that makes a 
> difference.

Nope.  FWIW, I compile and install everything as my normal user.
Principle of least priviledge.

Eric