[Top][All Lists]

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

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

From: Harald Welte
Subject: Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR)
Date: Fri, 24 Jun 2005 14:31:41 +0200
User-agent: Mutt/1.5.9i

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.

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 ;)

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.  

If the application is intelligent enough (and would still work on lower
sampling rates), it could react to frame loss by instructing the SDR to
lower the sample rate.

- Harald Welte <address@hidden>                         http://gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Attachment: signature.asc
Description: Digital signature

reply via email to

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