If I get bored (not likely), I would like to try isosynchronous transfers over USB. My thinking is a dropped packet is no worse than a burst of interference. For radio links, the higher level protocols are already handling error detection and correction.
Philip On Fri, 2005-06-24 at 09:32 -0500, David Carr wrote: > Lets say that we use UDP/RTP. Most non connection-oriented protocols > 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). > > -David Carr > > Eric Blossom wrote: > > >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: > >> > >>I don't really understand why you would want flow control. > >> > >> > >> > > > >Think about the transmit path. > > > >Simplest possible test case: > > > > Software sine wave generator talking to transmit hardware. There is > > nothing throttling the signal generator. It will produce an > > infinite amount of data as quickly as it can. You want the DAC > > clock to control pacing. Any kind of host based pacing will lead to > > trouble (under or overruns). > > > >Eric > > > > > >_______________________________________________ > >Discuss-gnuradio mailing list > >[email protected] > >http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
