discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR)


From: Stephane Fillod
Subject: Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR)
Date: Fri, 24 Jun 2005 15:12:04 +0200
User-agent: Mutt/1.5.8i

On Fri, Jun 24, 2005 at 02:31:41PM +0200, Harald Welte wrote:
> On Thu, Jun 23, 2005 at 08:52:33PM -0700, Eric Blossom wrote:
> > On Wed, Jun 22, 2005 at 12:40:06PM +0200, Harald Welte wrote:
> > > On Tue, Jun 21, 2005 at 04:10:35PM -0700, John Gilmore wrote:
> > > 
> > > But at what expense?  you copy data back and forth between different
> > > address spaces (kernel/user), you have lots of complex code that deals
> > > with retransmissions, protocol demultiplex, ... that is totally
> > > unneccessarry for the gnuradio/USRP kind of application.
> > 
> > Actually, you do need flow control.  And to do this with any kind of
> > throughput, you start needing sliding windows.  At this point, you are
> > pretty close to TCP territory.  The question becomes do I want to
> > build something custom, or do I want to use a standard solution that
> > might be overkill.
> 
> I don't really understand why you would want flow control.

I was about to ask the same question.

> You sample from the ADC with a certain bandwith.  If either your
> communications link or your host computer cannot cope with the amount of
> data, frames will be lost.  There is nothing you can do about that,
> unless you reduce the sampling rate or bits-per-sample depth.
> 
> You can introduce sender-side buffering at the expense of increased
> latency and do retransmissions of lost frames.  But that's not flow
> control, but delivery guarantee ;)

I fully agree.
Maybe Eric was thinking flow control is needed for the presentation time
of the samples with a continuous scale on the arrival endpoint. 
Eric, can you elaborate on the need for flow control?

> You can detect frame loss by using a simple frame number that gets
> incremented with every frame sent from the SDR.  The host PC then
> detects frame loss by gaps in the frame number sequence.  

The frame number can be the Sequence Number(SN) in the RTP header,
c.f. RFC 1889, "RTP: A Transport Protocol for Real-Time Applications".
The SN helps detecting frame loss (after a certain timeout), and
reorder frames if need be.

-- 
Stephane




reply via email to

[Prev in Thread] Current Thread [Next in Thread]