For the next generation of the eldora network, all of the applications on the 4u eldora control host (control gui and minicom vx consoles), the cappi laptop, and the redundant 1u archivers are consolidated onto the single 1u linux host, alpha.
Access to the vx serial consoles on alpha is through a USB serial hub, since alpha lacks enough serial ports.
The duper process still receives the data unicast from fore and aft, just as for the previous eldora deployment. However, rather than multicasting that data back over an external interface, the data are multicast to the loopback interface (127.0.0.1). Each of the data consumer processes receive data independently from the multicast data stream. The snarfer component receives the multicast stream, and a swapper component swaps the data if necessary. This is exactly how sabl currently runs. For eldora, there are several potential consumer processes: two archivers, two displays, cappi, ascope, and cal_sum.
The CAPPI gridder program will run on alpha instead of on a separate, dedicated laptop.
Archiving runs on alpha. Two archiver processes each write to separate removable scsi disks, again, just like sabl has been doing. Even if beta must run to generate the second display, both archiver instances will run on alpha.
The linux 1u has two ethernet interfaces. One interface is dedicated to the data network, while the second is connected to the plane. That leaves the boot/status network for the aft, fore, and hskp vxworks hosts. The plan is to consolidate that network onto the plane network. Or, it's still possible that the status traffic can run over the data network without interfering with the data traffic. (I think this is especially likely with a 10/100 switch and the eth29 interfaces unicasting to the 1u, since the data traffic can run over a 100Mb switched path.) We won't impose status traffic on the data net unless testing can verify no data loss. Putting the status net on the airplane net is most appealing, and that option is easy if the vx hosts IP addresses can be reconfigured easily. If the vxworks hosts' IP addresses cannot be changed, then it's still possible to connect them to alpha over the plane net using a router with 2-way NAT.
The Dell PowerConnect 2708 has Class-of-Service features, priority queueing, and virtual LAN support that should help isolate the vxworks status and control network from the radar multicast traffic, if that should be necessary.
There's talk of needing DHCP. The DHCP server could run on alpha, or it might be easiest to add a small router appliance to serve exclusively as a DHCP server. That way DHCP can be available whenever and as soon as the rack is powered, even when alpha is off or still booting.
The hope is to drive the dual radar displays (called left and right) with dual-head video card. If dual-head video output cannot be made to work reliably, then beta will generate the second display. In this scenario, alpha's duper process will multicast the radar data both onto the loopback interface and onto the plane network. A snarfer/display process on beta will pick up the data there. Unfortunately this means the operator must use the KVM to switch back and forth between alpha and beta to control the second display, unless synaptic can be made to work.
The Radeon 7500 dual-head video card is dual analog. Right now we only have KVM switches and video amps for analog video. This is not a problem even for newer video cards with analog/digital output, since there are adapters which convert from digital to analog.
The alpha system software is installed on a single scsi disk and replicated. A second, identical, spare 1u stays in the rack. In the event of a failure of the first 1u, the spare 1u can be booted in its place by moving the cable connections. Some connections, ie, networking, can always be plugged into both, as long as only one 1u is powered at one time. A KVM switch and an A/B switch, shown in the second digram, can be used to failover to the spare 1u by switching both of them to beta.
That leaves the USB connection to the vxworks serial consoles. That will have to be unplugged and plugged into beta.
This is not so simple if both alpha and beta are running and generating separate displays. In that case, each must have their own network address. In order for beta to take over for alpha, it must switch to alpha's IP address so the vxworks hosts can boot from it.
For now, there are no plans to multicast radar data onto the plane network for the sake of the science station. The left and right displays available at the science station will suffice.
Background: With alpha directly connected to the plane network, it is possible to relay the radar data onto the plane network. This would allow the science station laptop to receive radar beams and run the same realtime processes and displays as run on alpha. This means the science stations gets its own, fully interactive realtime radar displays. Another option for getting an interactive display at the science station is to use synaptic. synaptic allows one host's terminal to control a remote display. So a synaptic client on the science laptop can connect to a synaptic server on alpha (over the plane net) to control the 'operator right display' installed at the science station. The science laptop realtime processes could include an archiver instance, to record a portion of the realtime data and easily carry that data off the plane. I understand RAINEX needs something like this to check data between flights when the P3 is not in FL.