Re: [Discuss-gnuradio] Ethernet concerns, non-bandwidth

[Lamar Owen]

On Wednesday 22 June 2005 21:45, John Gilmore wrote:
> Copper GigE is sufficiently cheap and ubiquitous that a DAC/ADC board
> should use it.  But for the people who want to mount the whole thing
> on a tower and run a nonconducting fiber back to their processing
> shack, a converter from copper GigE to fiber GigE is small, low power,
> and only costs a few hundred dollars.

Put a GBIC slot on the card; best of both worlds.  Then you can do short haul 
multimode SX as well as longwave longhaul (1000Base-LX/LH depending upon the 
laser can go 40km).  And you can get copper GBIC's for UTP runs.

Now, there are a few things about the Ethernet interface possibilities that 
I've not seen addressed. Let's first drop the assumption that a 
point-to-point ethernet would be the only way such a device would be used; I 
know for a fact that people would try to use them on a switched network.  The 
next assumption that would need to be dropped is that only one PC could send 
a packet to the board; in fact, it would be highly desireable for the board 
to support multiple hosts.  After all, it's ethernet, right?

So, my first concern would be triple-A (Authentication, Authorization, and 
Accounting); if we have a transmitter that is ethernet attached we really 
must make sure that the only signals that are transmitted are authorized to 
be transmitted.  So a 'login' procedure to the board would be required.  We 
can't really lock out to only allow a single client access at any given time 
(I know that an ethernet-connected SDR here would be needed to be used by 
multiple client machines; I'd love to attach one machine per input channel to 
spread the load when needed).  So at that point you need an embedded 
controller with a little more intelligence than the FX2 has; something like 
an Xscale or StrongARM would be powerful enough to handle, say, an embedded 
Linux that could handle this.  Why rewrite a working TCP/IP implementation 
when there's a good one already that is getting lots of eyes; uCLinux is 
quite mature on ARM or MIPS (ARM being the core of things like the Linksys 
WRV54G (VPN wireless router), and MIPS being at the core of the WRT54G, both 
of which use Linux).

Then, depending upon the data being carried by the interface, you might want 
the stream to be encrypted; IPsec or SSL (SSH) would be useful.  If you have 
a Linux running on an ARM9 controlling things, you can run a radius server, 
syslog, etc, on the board to get the pieces of AAA that you need.  Intel has 
network processors that can do this in hardware; unfortunately the library to 
use the hardware encryption engine is not open source.  Support for something 
like Kerberos would be nice, since that interface is very well defined and 
works very well.

Then I could theoretically have eight clients connected at once; one for each 
ADC and one for each DAC (not counting auxiliary).  The LabJack UE9, for 
instance, allows multiple machines to query the box, but doesn't do AAA, 
which, in a control situation on a switched ethernet, is very bad.

There are significant non-bandwidth issues to using ethernet, and multiuser 
operation is one of them.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu