[prev in list] [next in list] [prev in thread] [next in thread] 

List:       usrp-users
Subject:    Re: [USRP-users] Real time continuous streaming - OS settings
From:       Ruben Merz via USRP-users <usrp-users () lists ! ettus ! com>
Date:       2015-02-26 15:12:28
Message-ID: 6735dba1499b4ca2843cb6706ade9d60 () SG001746 ! corproot ! net
[Download RAW message or body]

Hello,
You can also try to install the Ubuntu low-latency kernel. I believe it is directly \
available from the Ubuntu package list. Ruben

> -----Original Message-----
> From: USRP-users [mailto:usrp-users-bounces@lists.ettus.com] On Behalf Of
> LOUF Laurent via USRP-users
> Sent: Wednesday, February 25, 2015 10:47 AM
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] Real time continuous streaming - OS settings
> 
> Hello,
> 
> You should definitely try to patch your Ubuntu with a RT patch. I'm not quite
> sure if there's actually one for your version, but I'm using an old Ubuntu with a
> RT patch and it made all my problems disappear (well, almost all of them at
> least). Doing so, if you set a high priority for your processes performing critical
> stuff, they won't be interrupted by the scheduler, not even for a system
> application. Since using that, I haven't had a problem receiving or sending
> (1250 samples, sc16, every 625µs, and it still works for 2 channels). Hope that
> helps.
> 
> [@@ THALES GROUP INTERNAL @@]
> 
> 
> -----Message d'origine-----
> De : USRP-users [mailto:usrp-users-bounces@lists.ettus.com] De la part de Tom
> Tsou via USRP-users Envoyé : mardi 24 février 2015 22:01 À : Dario Fertonani
> Cc : USRP-users@lists.ettus.com Objet : Re: [USRP-users] Real time continuous
> streaming - OS settings
> 
> On Tue, Feb 24, 2015 at 12:11 PM, Dario Fertonani
> <dario.fertonani@gmail.com> wrote:
> > Eventually we'll want to support 20 MHz LTE, so even 15.36 MHz is a
> > cutback for us. I'm hoping the problem can be fixed by changing some
> > scheduling parameters for the critical threads. Even changing OS to
> > something more RT friendly is ok.
> 
> 2 x 23.04 Msps full-duplex is possible with 12-bit or 8-bit samples.
> The processing for LTE is still challenging, but the I/O should be capable.
> 
> > I left per-core critical OS stuff (watchdog, migration, etc) at their
> > default priority-99 FIFO scheduling params. I raised the USB-related
> > irq/40-xhci_hcd process from its default priority-50 FIFO scheduling
> > params to priority-90 FIFO, so that it has nothing above other than
> > watchdog/migration. The recv() and send() calls are too in a thread
> > with
> > priority-90 FIFO scheduling params. In the basic version used for
> > debugging, the thread does nothing but streaming as shown below.
> > for ( unsigned chunk = 0 ; chunk < Chunks ; chunk++ )
> > {
> > ettusB210.recv( dataPtr_d1 );
> > ettusB210.send( dataPtr_d1 , Delay_s );
> > }
> > Essentially, the recv() wrapper blocks until the 125us packet is
> > received (timeout 625us). Then send() retransmits the same data with
> > over-the-air delay of Delay_s, currently set to 500us w.r.t. the end
> > of the received chunk. The send() wrapper also blocks until the 125us
> > packet has been processed (timeout 625us). Your answer suggests that
> > recv() and send() should not block each other, if I understand correctly.
> 
> UHD is fine with recv() and send() being in separate threads, so you might
> consider splitting send() and recv() threads with a wait() and
> signal() on a condition variable. Actual performance is difficult to predict, but
> that should, at least, remove the possibility of the
> recv() being blocked by the send(). It's worth a try.
> 
> In theory, then, you could drop the priority on the transmit path and let recv()
> loop unconstrainted. That might lead to underruns or late packets on the
> transmit path, but that is still better than the recv() path collapsing and taking
> down the application with it.
> 
> -TT
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


[prev in list] [next in list] [prev in thread] [next in thread]