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

[Bruce Rowen]

compounding on what Kevin says....

Each 'vciStbDelayModel' contains one station boards model (2 base  
bands and 36 subbands). Given the maximum model (all subbands, 6  
coefficients each), I get a ballpark maximum XML message of about  
14KB. Basically the delay model applies to a single IF pair but could  
get weird with VLBI/VSI input setups (should that ever happen).
The delay model schema could be modified to carry all 4 IF pairs but  
if each of the station boards assigned to an antenna receives this  
XML message, there would be a fair amount of 'waste' as each board  
would discard 75% of the message (after doing all the parsing).
Any scheme to provide the models to the station boards should work at  
the level of addressing IF pairs to eliminate the waste (i.e. keep to  
the current 2-base band schema).

If the MCCC is bypassed in delay model routing, the utility of the  
'boardId' element in the model schema also becomes redundant. The  
station board ignores this information anyway.

To further clean up the schema, I think we can eliminate some of the  
other redundant information. I placed an example beta schema at:

http://www.aoc.nrao.edu/asg/widar/schemata/cmib/models/ 
vciDelayModelBeta.html

Summary of the proposed changes:
The base band and sub band identifiers supplied in the model are  
logical. that is the cmib figures out that delays for logical base  
band #6 map to physical base band #1 based on the embedded  
identifiers supplied by the MCCC. Of course the model generator will  
need to know what mapping the MCCC intends or another base band ID  
mapping scheme could be deployed.
Same thing for the sub bands.

The number of coefficients has been changed to 'unlimited' and  
determined solely by the number of coefficient elements received at  
the station board (no need for a coefficient count).

I moved the sub band models under the base band (18 max each) since  
the hardware is divided up this way. For the case where both base  
bands are being fed the same data to effectively allow for 36 sub  
bands, each base band is still separate and requires a model to be  
specified (i.e. the station board doesn't really care that both base  
bands are identical aside from mapping the inputs)

Epoch is in station board obsClock time (UT). This tells the station  
board when the enclosed model is to be transitioned to and used. t0  
is in a form best suited for model expansion (possibly MJD or other  
count of time units internal to the correlator). I have it declared  
as a float but if UT is used then it would become a timeDate type.

On May 14, 2008, at 12:46 PM, Kevin Ryan wrote:
> 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
>
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss