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: John Gilmore
Subject: Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR)
Date: Fri, 24 Jun 2005 15:31:34 -0700

> involve an application layer connection control scheme.  For TX, each
> packet has a number and the device NACKs a packet if it is received when
> the buffer is full.  The host then retries NACKed packets at a given
> interval and gives up if not successful after N tries.  This is still a
> lot lighter than a TCP stack (and could be done in an FPGA).

You've just reinvented the first ten instructions of TCP packet
processing.  The kernel code already does (roughly) that.  What is
also there in TCP is code to handle the case when that "fast path"
fails (e.g. when a packet was garbled on the wire and you instead
receive the next packet, and you buffer it and keep looking for that
first packet to be retransmitted, but meanwhile more later packets are
coming in, but you aren't out of buffer space yet, or maybe you are,
and the radio transmitter is getting close to needing that missing
data, or maybe it isn't, etc).

I've been designing protocols like this since 1979 (PCNet).  It's real
work.  TCP was designed on the back of an envelope, but it was
designed by guys who had lived under NCP (its predecessor) for a
decade, and had watched it go into catastrophic network-wide failure
under overload.  They threw it away, discarded its most basic
assumption (guaranteed delivery of data by the network), and started
over with the assumption that the network could throw away your data
at any time (the endpoints need to be responsible for guaranteed
delivery).  Their second effort, TCP, has scaled up to billions of
users and trillions of bits per second.  But it took them many months
to get TCP working, and many years of research and tuning to make it
deliver reasonable bandwidth in the face of bandwidth limits
(congestion).

Bandwidth limits are why we are even considering replacing our current
simple USB2 protocol.  Our next interface and protocol WILL be
sampling signals that are at the hairy edge of what the hardware and
software can handle -- just like today.  Our appetites grow over time.
Our flow control protocol will work better if it's been modeled and
implemented and studied and deployed and fixed by thousands of other
people, in real world use.

Maybe we should table this discussion until someone actually proposes
to build a fast AtoD with an ethernet interface.  I reopened it so the
last word wouldn't be "Don't ever do that".  When someone eventually
does it, I think we'll learn a lot from the experience.  Maybe what
we'll learn is "Don't do that", but I think it will be a much more
subtle and interesting answer (which will then help us scale to the
next level of bandwidth, 10-gigabit Ethernet, "InfernoWire", USB17, or
whatever).

        John




reply via email to

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