[Discuss-gnuradio] Gig-E alternatives
I attended several Intel platform and embedded systemsconferences last week and they made it clear Intel will moverapidly into dual/multi core cpu's for power and heat reasons.Systems will appear by late this year.They will also be moving to eliminate parallel connectivitymethods like isa, pci; replacing them with serial ata slots(4x faster than pci) and and HD drive connectors for full size and embedded systems.While it is close range in feet, a USRP board connected via sata cable would have considerable through-put. I don't know the current rates ( ~133 to 150mb/s) but the roadmap puts the upper end at 600mb/s.Board connector traces required for sata are greatly reduced from a parallel architecture.KimseyOn Jun 23, 2005, at 10:12 PM, [EMAIL PROTECTED] wrote:--Message: 4Date: Fri, 24 Jun 2005 11:22:15 +0930From: "Rob Schenk" [EMAIL PROTECTED]Subject: RE: [Discuss-gnuradio] Gig-E alternativesTo: Discuss-gnuradio@gnu.orgMessage-ID: [EMAIL PROTECTED]Content-Type: text/plain; charset="iso-8859-1"I'm new to this group/discussion so I apologise if this has already beendiscussed..."Virtex-4 FX12 Mini-Modules are available from Memec..."This is small and could be fitted as a daughterboard.Adds GigE link at reasonably low cost, i.e. for those appns that need it?See attached flyer... or visit: http://legacy.memec.com/devkits/americas.shtmlHas this module been considered/evaluated?Also interested in hearing from anyone who has had issues/problems using theGigEinterface for this module (eg MAC layer implementation).Rob.-- next part --A non-text attachment was scrubbed...Name: V4_FX_Mini_Module.pdfType: application/pdfSize: 310195 bytesDesc: not availableUrl : http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20050624/e7c4b06a/V4_FX_Mini_Module.pdf--___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttp://lists.gnu.org/mailman/listinfo/discuss-gnuradioEnd of Discuss-gnuradio Digest, Vol 31, Issue 34 Kimsey Pollard Microelectronics Research Center Georgia Institute of Technology 404-894-4207 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR)
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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR)
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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to stop FFT from going uOuOuO?
Hello everybody, Is there a way to stop the FFTs from going uOuOuO all over my stdout? I haven't looked at the guts so far, but it seems a rather odd (and on my side, rather unwanted) behaviour. I'm currently writing a few decoders where the decoded stuff is dumped to stdout, so the uOuO stuff is starting to bother me a bit ;) Thanks Urs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Release, website, and other notes.
With all the changes and bugfixes that have percolated down CVS, do we think we might be getting close to a 2.6 release? Along those lines, I have not as yet had a chance to work any on the website; I have not forgotten about it, and intend to work with it. On other notes, one of my projects with the USRP is as a time-domain-reflectometer and vector network analyzer. I will post progress as I have progress (none yet, other than hardware being purchased). -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR)
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
