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

[Brent Carlson]

It seems to me that if multicast/UDP/IP is used, that each station CMIB 
needs to keep track of when and for how long it is fly-wheeling on a 
model.  At some point missing models will impact the data, and this 
information needs to be known if the true applied delay model is to be 
kept track of.  I assume this has been thought of.

Brent

Sonja Vrcic wrote:

> I completely agree that there is no need to send Delay Models via MCCC.
>
> The multicast address for Delay Models could be specified as a part of 
> VCI subarray configuration (a different multicast address can be 
> specified for each station).
>
> If we can agree that there is no need to send Delay Models via MCCC, 
> we should implement things that way from the beginning. In the absence 
> of the "real" VCI and MCCC, the multicast address for the Delay Models 
> can be specified using Station Board GUI.
>
> Regarding the identifiers : Delay Model can specify either "abstract" 
> identifiers *Station ID / Baseband ID / Subband ID* or physical 
> identifiers *Station Board ID / Data Path ID / Filter ID*.
> Observation preparation tool assigns Station ID and Baseband ID to the 
> actual Station Board Data Path; while, in general, MCCC Configuration 
> Mapper decides which Filter is used for which Subband. That's why I 
> believe that Delay Model should specify Station/Baseband/Subband IDs 
> and not the physical identifiers.
>
> Sonja
>
> 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
>>  
>>
>
>-- 
>Sonja Vrcic
>Software Engineer
>National Research Council
>Herzberg Institute of Astrophysics
>Dominion Radio Astrophysical Observatory,
>Penticton, BC, Canada
>Tel:(250)490-4309/(250)493-2277ext.309
>Sonja.Vrcic at nrc-cnrc.gc.ca
>http://www.drao-ofr.hia-iha.nrc-cnrc.gc.ca/
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>evla-sw-discuss mailing list
>evla-sw-discuss at listmgr.cv.nrao.edu
>http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
>  
>

-- 
Brent R. Carlson
Brent.Carlson at nrc-cnrc.gc.ca
Tel/Tél: (250) 493-2277 (ext. 346) |  Fax: (250) 493-7767
Design Engineer                    |  Ingenieur Concepteur
National Research Council Canada   |  Conseil national de recherches Canada
Dominion Radio Astrophysical Obs.  |  Observatoire federal de radioastrophysique
P.O. Box 248, 717 White Lake Rd    |  C.P. 248, 717 Rue White Lake
Penticton, BC, Canada V2A 6K3      |  Penticton, (C.-B.), Canada V2A 6K3
Government of Canada               |  Gouvernement du Canada

"If you seek truth, and the evidence conflicts with your beliefs,
        then you must adjust your beliefs; not the other way around."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/evla-sw-discuss/attachments/20080514/20acc4c7/attachment.html>