[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: |
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
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR), (continued)
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR), David Carr, 2005/06/24
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR), Philip Balister, 2005/06/24
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR), John Gilmore, 2005/06/24
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR), Lamar Owen, 2005/06/25
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR), Marcus D. Leech, 2005/06/25
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR), Eric Blossom, 2005/06/26
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR), Eric Blossom, 2005/06/26
- [Discuss-gnuradio] FIR filter in fsk_tx.py, Sachi, 2005/06/26
- Re: [Discuss-gnuradio] FIR filter in fsk_tx.py, Sachi, 2005/06/27
- Re: [Discuss-gnuradio] FIR filter in fsk_tx.py, Matt Ettus, 2005/06/29
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR),
Stephane Fillod <=