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: Marcus D. Leech
Subject: Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR)
Date: Sat, 25 Jun 2005 15:36:01 -0400

Lamar Owen wrote:
> 
> On Friday 24 June 2005 18:31, John Gilmore wrote:
> > You've just reinvented the first ten instructions of TCP packet
> > processing.
> 
> I for one am very familiar with the work of 'address@hidden' and have been in
> awe of your work for some time.  I have not been at this nearly as long as
> you, but I'm glad you remind people that there really is a history here, and
> reinventing already working wheels is counterproductive in a manner.
> Sometimes it can be educational, but that's a different story.
> 
> Yet the computing landscape is riddled with wheels that have been reinvented
> dozens of times; simply because it is impossible for any one person to be
> familiar with all the different wheels out there.  But in the age of Google,
> simply searching for what you need is better than going off on your own.
> That is why I waited on the USRP availability; I have needed this
> functionality for at least five years, but the tech wasn't there yet, and,
> quite honestly, the effort is large.  I waited with bated breath for Matt to
> announce that USRP's could be bought, and bought one as soon as I could
> afford to do so.  And am enjoying it immensely!
> 
> I think the next logical step is either PCI-e (which could scale to outside
> the box), some form of SATA, or Infiniband or one of its variants.   But
> honestly USB2 is not a bad solution and is great for what the USRP does
> today.
> 
> IPv6 with QoS might be able to deal with what hard realtime applications like
> data acquisition and software radio need; but quite honestly it is a lot of
> overhead for the application.  IPv4 is insufficient for hard realtime;
> dropping packets in software radio really isn't an option, otherwise
> out-of-band emissions could result, and our friendly neighborhood EIC at the
> FCC's EB won't like that (and neither will your wallet when you get the NAL
> for $10,000 for unlicensed operation!).  The problem there is the currently
> regulated nature of spectrum usage; maybe one day cognitive radios will be
> able to deal with wide-open spectrum usage; but, even then, the protocols and
> software of the cognitive SDR (and the developers of this software and
> firmware!) are responsible at that point for staying within regulatory
> bounds.
> 

Given that we're mostly talking (I thought) about a *local* network
connection--without
  routers, and likely without L2 switches, none of the stuff in IPV6 about QoS
will
  be of any use at all, as far as I can tell.  QoS is *mostly* about changing
queueing
  behaviour in *routers*, and perhaps doing a bit of resource reservation.

In a purely-local connection consisting of computer--L2 hub/switch--USRP, none
of the
  big 'I' internet stuff really comes into play.  I don't think that anyone is
suggesting
  that you could reasonably do SDR *over the Internet*--just leveraging the
  existing Internet protocol stack (like TCP) to provide some reliable-delivery
  services.  And if you're dealing mostly with the dedicated piece of GigE
  scenario, even TCP *might* be a bit of overkill.

> But, back to Ethernet, I'd simply reference what Gibson (as in guitars) is
> doing with Ethernet.  See
> http://www.wired.com/wired/archive/12.01/guitar.html and
> http://www.macworld.com/news/2005/01/24/gibson/index.php and
> http://www.networkworld.com/net.worker/columnists/2003/0602kistner.html for a
> brief introduction.  Or google for 'gibson guitar ethernet' and read the
> hundreds of pages yourself. :-)  Power over Ethernet; in a guitar of all
> things.  Priceless.

Saw some of their stuff demoed at an IEEE 802 standards meeting in Hawaii a few
  years back--or was it San Francisco?  Can't keep the meetings straight in my
  head...

-- 
Marcus Leech                            Mail:   Dept 1A12, M/S: 04352P16
Security Standards Advisor        Phone: (ESN) 393-9145  +1 613 763 9145
Advanced Technology Research
Nortel Networks                          address@hidden




reply via email to

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