<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
Brent<br>
<br>
Sonja Vrcic wrote:
<blockquote cite="mid482B40D2.8080208@nrc.gc.ca" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
<tt>I completely agree that there is no need to send Delay Models via
MCCC. <br>
<br>
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). <br>
<br>
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. <br>
<br>
Regarding the identifiers : Delay Model can specify either "abstract"
identifiers <b>Station ID / Baseband ID / Subband ID</b> or physical
identifiers <b>Station Board ID / Data Path ID / Filter ID</b>.<br>
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. <br>
<br>
Sonja<br>
</tt><br>
Barry Clark wrote:
<blockquote cite="mid:200805141628.KAA02413@bclark.aoc.nrao.edu"
type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated"
href="mailto:evla-sw-discuss@listmgr.cv.nrao.edu">evla-sw-discuss@listmgr.cv.nrao.edu</a>
<a class="moz-txt-link-freetext"
href="http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss">http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="90">--
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
<a class="moz-txt-link-abbreviated"
href="mailto:Sonja.Vrcic@nrc-cnrc.gc.ca">Sonja.Vrcic@nrc-cnrc.gc.ca</a>
<a class="moz-txt-link-freetext"
href="http://www.drao-ofr.hia-iha.nrc-cnrc.gc.ca/">http://www.drao-ofr.hia-iha.nrc-cnrc.gc.ca/</a>
</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
evla-sw-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:evla-sw-discuss@listmgr.cv.nrao.edu">evla-sw-discuss@listmgr.cv.nrao.edu</a>
<a class="moz-txt-link-freetext" href="http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss">http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Brent R. Carlson
<a class="moz-txt-link-abbreviated" href="mailto:Brent.Carlson@nrc-cnrc.gc.ca">Brent.Carlson@nrc-cnrc.gc.ca</a>
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."</pre>
</body>
</html>