[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] usrp_basic_rx::stop appears to take a long time,
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] usrp_basic_rx::stop appears to take a long time, and reading after stop always returns > 0 bytes |
Date: |
Tue, 29 May 2007 19:24:22 -0700 |
User-agent: |
Mutt/1.5.9i |
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