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 '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED] _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
