<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 04/01/2014 01:52 PM, Michael Rupen
wrote:<br>
</div>
<blockquote
cite="mid:Pine.LNX.4.64.1404011445250.25240@scamper.aoc.nrao.edu"
type="cite">
<pre wrap="">Hi Sonja --
wow, thanks for the quick read! A few comments on comments...
</pre>
<blockquote type="cite">
<pre wrap="">Example: VCI documents (messages) for a set of three subarrays, where
master SB uses subarray A, while 'slave' SBs 1 and 2 use subarrays B and
C.
Please correct me if I am wrong, but I believe that the Executor now
transmits the following:
1. subArray-A-Obs123-Master, ActivationID=startSubA
2. actTrigger, activationID=startSubA, actTime=12:30:00
3. subArray-B-Obs123-Slave1, ActivationID=startSubB
4. actTrigger, activationID=startSubB, actTime=12:30:00
5. subArray-C-Obs123-Slave2, ActivationID=startSubC
6. actTrigger, activationID=startSubC, actTime=12:30:00
(actually activation time is staggered by 30sec or so to avoid
problems).
If I am right, that there is a way around this problem, but I am not sure
how difficult it would be to make changes in the Executor to use a single
Activation Trigger for all SBs in a set (master + slaves) and to transmit
this:
1. subArray-A-Obs123-Master, ActivationID=startObs123
2. subArray-B-Obs123-Slave1, ActivationID=startObs123
3. subArray-C-Obs123-Slave2, ActivationID=startObs123
4. actTrigger, activationID=startObs123, actTime=12:30:00
CM places received configuration messages (create/delete subarray) in the
configuration queue.
Configuration messages are removed from the queue (and processed) when
Activation Trigger is received.
To process all 3 messages as a single configuration, Executor would have
to assign the same Activation ID to all SBs (configuration messages)
that should be activated at the same time, and transmit a single
Activation Trigger with that Activation ID after all messages are
transmitted (master + slaves).
Note: the order in which messages 'create subarray' are transmitted does
not matter, but the Activation Trigger must be transmitted last, to
ensure that CM has received all subarrays before Activation Trigger is
received.
In this case, CM would process all three subarrays one after the other,
forward configuration to CBE for all three subarrays one after the
other; but this should not cause the type of problems that we see now
(or should at least minimize them).
</pre>
</blockquote>
<pre wrap="">
I fear that there are upstream (Executor) reasons which would make this
difficult, but I agree that it sounds lovely in principle!
Ken/Barry/Bryan should comment on that aspect.
I could imagine using the subarray name (as you have in the example
above) in such a way that CM would know these are related subarrays and
"stack" them together as you suggest, even without the Executor doing
it. That would involve tweaking the Activation Trigger. I suspect you
& Kevin will make similar arguments against this as those Ken et al.
will raise to doing this in the Executor ;)
</pre>
</blockquote>
<br>
The main issue with transmitting the following: <br>
<pre wrap=""> 1. subArray-A-Obs123-Master, ActivationID=startSubA
2. actTrigger, activationID=startSubA, actTime=12:30:00
3. subArray-B-Obs123-Slave1, ActivationID=startSubB
4. actTrigger, activationID=startSubB, actTime=12:30:00
5. subArray-C-Obs123-Slave2, ActivationID=startSubC
6. actTrigger, activationID=startSubC, actTime=12:30:00
Is that messages are added to the CM queue as they are received; independently of that, the CM periodical timer wakes up (software interrupt), checks the queue looking for messages for which the Activation Trigger has been received. The only way to guarantee that two messages (or more) will be processed as a single configuration, is to assign the same Activation ID.
Example:
</pre>
<pre wrap=""> 1. subArray-A-Obs123-Master, ActivationID=startA
2. actTrigger, activationID=startA, actTime=12:30:00
3. subArray-B-Obs123-Slave1, ActivationID=startB
4. actTrigger, activationID=startB, actTime=12:30:00
CM timer expires, CM removes messages from the queue, processes them and forwards configuration to the CBE.
5. subArray-C-Obs123-Slave2, ActivationID=startC
6. actTrigger, activationID=startC, actTime=12:30:00
</pre>
<pre wrap="">CM timer expires, finds the 3rd subarray. This configuration has the same activation time as the previously transmitted configuration, CM revokes previously transmitted configuration, processes all three messages together and transmits the new configuration (all three subarrays). That's what causes the problems you see ! CM is oblivious to the fact that subarrays A and B did not change ! For configurations that are <i>not</i> scheduled at the same time CM knows how to send the 'delta' (the difference). For configurations that <i>are</i> scheduled <i>at the same time </i>CM does not keep the delta. It has not been design to do so. That's why the Activation Trigger message was added (in the beginning, long time ago, when the main concern was how to activate several messages as a single configuration).
Also note that CMIB can have only one configuration with the same activation time in the input queue. If we transmit the second configuration with the same act. time, it will replace previously received one.
CM could be modified to have more than one CorrModel in the activation queue with the same activation time. Not sure how much work that would be. Not a trivial change. But given that we encounter this issue over and over again, it could be worth while to make that change.
Not sure what is easier change to change the Executor or to change CM.
Sonja
</pre>
<blockquote
cite="mid:Pine.LNX.4.64.1404011445250.25240@scamper.aoc.nrao.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">When you refer to "the limited number of DUMPTRIGs" isn't that the
number of DUMPTRIGs per Station Board, i.e. per antenna.
Nominally 16, but CMIB is not able to support that many. But that just
limits the nummber of different DUMPTRIGS for the subbands of the same
antenna.
Not sure what are the restrictions on routing the DUMPTRIGs.
Perhaps I forgot.
</pre>
</blockquote>
<pre wrap="">
There are limitations on the complexity of the individual DUMPTRIGs
based on the size of the HES they can hold, and some DUMPTRIGs are more
equal than others (i.e., the first two can be more complex). So you
can't really have 16 equally complex DUMPTRIGs. Further, I thought I
remembered some restrictions on DUMPTRIG routing, though now that you
mention it those may only apply when you're trying for >16 DUMPTRIGs
for a single set of stations. Which would be very pleasant :)
Cheers,
Michael</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Sonja Vrcic
Team Lead Software
National Research Council Of Canada
Dominion Radio Astrophysical Observatory
<a class="moz-txt-link-abbreviated" href="mailto:Sonja.Vrcic@nrc-cnrc.gc.ca">Sonja.Vrcic@nrc-cnrc.gc.ca</a>
(250)497-2309 or (250)497-2300 ext.309
<a class="moz-txt-link-freetext" href="http://www.nrc-cnrc.gc.ca/">http://www.nrc-cnrc.gc.ca/</a>
</pre>
</body>
</html>