discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Gig-E alternatives


From: Lamar Owen
Subject: Re: [Discuss-gnuradio] Gig-E alternatives
Date: Thu, 23 Jun 2005 07:38:01 -0400
User-agent: KMail/1.8.1

On Wednesday 22 June 2005 20:36, David P. Reed wrote:
> Though GigE sounds like a good idea to pursue, has anyone thought about
> using 2 or more USB 2 interfaces as an alternative?   I don't know what
> the typical controller interfaces can handle, but I see three on my
> AMD64-based laptop, plus a firewire interface - that's potentially about
> 1.6 Gb/sec combined, but I only have a 100 Mb/s Ethernet interface.

Typically all the USB ports on a PC are tied to a single host controller 
channel, although there are exceptions.  The entire bus is limited in 
bandwidth, and adding another channel into a single controller isn't going to 
help the throughput.

The biggest problem with GigE is the potential for interference in RF spectra 
that we might want to receive.

As to throughput,  you are still limited in IO bandwidth at the PC level, 
particularly in the HD interface.  While the interface itself might be 
substantially faster than the necessary throughput (ATA133 supposedly can 
transfer 133MB/s, SATA 150 can do 150MB/s) in reality the HD platter transfer 
rate is typically much lower: my ATA100 drive in my laptop, for instance:
address@hidden ~]# hdparm -t /dev/hda

/dev/hda:
 Timing buffered disk reads:   70 MB in  3.05 seconds =  22.95 MB/sec
address@hidden ~]# hdparm -i /dev/hda
 
This means that there is no way I can store data at the current USB rates.  My 
faster server could:
address@hidden ~]# hdparm -t /dev/hda

/dev/hda:
 Timing buffered disk reads:  172 MB in  3.02 seconds =  57.04 MB/sec
address@hidden ~]#

But even then it would be hard pressed to keep up for long.  The server has a 
fast ATA133 Maxtor 250GB drive as /dev/hda, and is one of the faster ones 
around.  EVEN THEN I could not keep up with full-bore GigE.

Next, to fully take advantage of GigE, you have to have multiple PCI buses in 
your system, if you have 32 bit PCI especially.  32 bit PCI at 33MHz rate is 
capable of 133MB/s max;  GigE at full rate is very close to this.  Many if 
not most GigE cards have a 64 bit PCI-X interface;  66MHz or better 133MHz 
PCI-X at 64 bits is capable of up to ten times the 32 bit PCI rate, and is 
typically only available in servers.

Next, as the USRP USB page states, finding a GigE chip that can be handled 
with the fab process being used is a challenge, and finding one with open 
docs (from the hardware design point of view) is even harder.  Prototyping 
BGA package based designs is exceeding difficult unless you have very special 
equipment or produce high enough volume to justify the expense of the 
necessary equipment (like motherboard manufacturers can afford to have, for 
instance).   GigE would likely more than double the cost.

> The other thought is that if you are considering putting the peripheral
> remotely close to an outdoor antenna, perhaps an optical fiber solution
> would be better - why risk frying your CPU or your body?

At PARI, we have gone the gamut from thinking about a full fledged embedded PC 
in the feedbox to bringing the RF down fiber.  RF down fiber has its own 
challenges; fiber transmitters and receivers that can handle the low signal 
levels in a linear fashion are very expensive.  But having all the frequency 
hash of the PC and USRP at the feedbox (close to the focal plane!) presents 
its own challenge, not the least of which is lightning protection.  The fiber 
itself is cheap; troll eBay looking for single mode fiber pigtails in the 225 
foot length range; they can be had very inexpensively: I have seen 225 foot 8 
fiber pigtails with one end terminated in the $25 neighborhood.  The 
equipment to drive this fiber is where you will run into cost.  We at PARI 
have 12 strands of good quality singlemode fiber run to each of the two 26m 
antennas' feedboxes.  I get around 1dB of loss for the shorter of the two 
runs, and around 2dB for the longer.  With transmit lasers approaching 30mW, 
I may very well have to put fiber attenuators in the line to prevent the 
receiver from being blinded.  See, lasers can't just be turned down; they 
won't 'lase' if they're not fed enough power.  But then receivers have their 
own distortion curves to worry about, and too much light is just as bad as 
not enough light.

In many ways bringing RF down is easier, and in many other ways putting the PC 
and USRP in the feedbox is easier, and like all engineering decisions, there 
are significant tradeoffs.  Fiber transceivers for ethernet, even in the 
singlemode variety, are much less expensive and much easier to deal with than 
RF transmitters/receivers.  But the RF transmitter doesn't need as much 
shielding to keep its hash out of the front-end.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu




reply via email to

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