[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: |
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
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR), (continued)
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR), Marcus D. Leech, 2005/06/22
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR), Stephane Fillod, 2005/06/22
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR), David Young, 2005/06/22
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR), Eric Blossom, 2005/06/23
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR), Harald Welte, 2005/06/24
- Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR), Eric Blossom, 2005/06/24
- 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 <=
- 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, 2005/06/24