[evla-sw-discuss] Delay models to station boards

[Kevin Ryan]

What Barry says, makes sense in that it may seem silly to make the  
MCCC have to go through the work of redistributing the models when  
the Executor could send them directly to the CMIBs.  The purpose of  
the VCI, however, is to allow encapsulation of the implementation  
details of WIDAR.  One of these implementation details is the CMIBs  
including their location, names and IP addresses.  This stuff need  
not and should not be known outside the VCI.

Barry's suggestion of multicast would preserve that encapsulation by  
having the models sent to an address, known by the EVLA, instead of  
to a CMIB's address.

And since Barry says that it is not essential that all the models get  
through than it sounds like this is actually a viable candidate for  
the use of multicast datagrams.

Since Barry's message applies to #1 of his sequence (long term  
direction), we should not commit to this without testing both methods  
(VCI/REST and multicast datagrams) with all 128 Station Board CMIBs  
online (or a simulation of it).  The scientists should pick a value  
for a tolerable number of dropped models and then we'll compare the  
two methods to see how UDP does with this tolerance and how VCI/REST  
does with loading the MCCC.

I am afeared of UDP for uses where the data must 'get through' and  
some testing that I've done affirms this fear.  On the other hand, I  
realize that UDP does have its place where lost data does not impact  
operation.

Kevin

On May 14, 2008, at 10:28 AM, Barry Clark wrote:

> It seems to me that we need to do, in sequence,
> 1.  Reaffirm the long term direction we want to take.
> 2.  Decide how the short term implementation is to proceed.
> 3.  Establish shared use of the code repositories, especially for  
> schema.
> 4.  Determine the details of the records to be passed.
>
> This message applies to #1.
>
> Do we want delay models to cross the VCI?
>
> They have very different properties from other messages.  In  
> particular,
> the data rates are comparatively high.  As I mentioned in an earlier
> message on this exploder, the most difficult case called for in the  
> EVLA
> specs is on-the-fly mapping at high frequency, which requires new  
> delay
> models at least five times per second.  For 27 antennas and 4  
> station boards
> per antenna this runs to about 600 models per second.
>
> Some timing tests I did a year ago indicated that the current mchost
> computer would not quite be able to achieve this, but was not too slow
> by a very large factor.
>
> By looking at the code, it seems to me that the computation in the  
> executor
> will go mainly to CALC and to conversion of data into ASCII messages.
> The CALC part of the code requires three relatively complicated  
> calculations
> of earth orientation and then, for each antenna, three relatively  
> simple
> path calculations.  The ASCII conversions will be a message to the  
> antenna
> MIB for pointing and the XML transmission of the delay models.  I  
> have no
> idea of the relative split of computation between the arithmetic of  
> CALC
> and the ASCII conversions.  It would not surprise me if they were  
> equal
> drains on the CPU.  Decoding the messages will be a comparable  
> effort to
> encoding them.  If indeed we are limited by how fast Executor can  
> produce
> these messages, and all messages go through the VCI, then the MCCC  
> will
> have to spend essentially all of its CPU receiving these messages,  
> decoding
> them, splitting them out and sending them to the REST address of  
> the station
> boards.
>
> Another difference between delay models and other messages to the  
> correlator
> is that it is not very serious if a message is lost.  Another one  
> will be
> along in a few seconds anyway (and, in the middle of an  
> observation, the
> correlator should just coast almost unnoticeably if one is missing).
>
> So an alternative to putting the messages through the VCI is to simply
> multicast them.  It would be easy to arrange that each antenna has its
> own socket to broadcast over, so the receiver on the station board  
> would
> get messages only for itself and for the other three station boards of
> the antenna.  It would be a relatively small job for it to decode and
> use these messages.
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss