[evla-sw-discuss] Simple subarrays: a modest proposal

[Barry Clark]

I hate to waste time on what is almost certainly a non-productive
comment, but I can't resist grumbling a bit.

Much of the subarray turmoil arises from the different definition
of subarray in the correlator and executor.  In the correlator, a
Subarray is part of a configuration.  In Executor, a subarray is a
defined collection of hardware.  In the latter case, the subarray
can do what it wants with its hardware without bothering anybody
else.  The correlator, regarding a Subarray as part of a configuration,
must know about what all Subarrays are doing before it can define
a configuration.

If the 'collection of hardware' definition could be implemented in
the correlator, it would make things much simpler.  The defined
collection of hardware would include station boards, CCs, CBE nodes,
and, probably, paths through the crossbars.

I agree that such an implementation is much less flexible than the
current approach, but would argue that such flexibility is pretty
empty - only in rather contrived cases would one want to trade
correlator resources between subarrays.  I cannot think of a
substantive use case.

On 04/02/2014 08:48 AM, Michael Rupen wrote:
> On Wed, 2 Apr 2014, Ken Sowinski wrote:
>
>> On Tue, 1 Apr 2014, Vrcic, Sonja wrote:
>>
>>>   Hi Michael, it just occurred to me that there is one more possible
>>>   solution: vci parameter "mapping time" could be used to delay the mapping
>>>   of subarrays until all are received by CM.
>>>
>>>   Parameter mappingTime has been implemented to allow messages transmitted
>>>   from different sources to be mapped as a single configuration, and to
>>>   provide deterministic mapping in general. Mapping time has not been used
>>>   so far, but I tested it long ago and to my knowledge it works.
>>>
>>>   Executor could transmit Activation Trigger for each subarray, as it does
>>>   now, and use different Activation ID for each, as it does now;  the only
>>>   change would be to add a parameter mappingTime to the Activation Triggers
>>>   to postpone the mapping of vci messages until all subarrays that should
>>>   start at the same time are received by CM. The necessary delay could be
>>>   determined empirically (by testing). Also, the Executor would have to be
>>>   aware that subarrays (Scheduling Blocks) belong to the same observation
>>>   (and should be mapped at the same time). If that is not already the case,
>>>   perhaps an indication (a parameter 'delayMapping') could be passed to it,
>>>   to let it know. This would still require changes in the Executor, but
>>>   perhaps smaller. Sonja
>>
>> The better approach might be to include this in the .vci files
>> generatd by m2s.  Knowledge of subarrays and their interrelations
>> exists (or will exist) there (or in OPT), but does not in the executor.
>
> This is a good thought, but is probably too much for the sort of quick&
> dirty initial implementation I'm thinking of.  I _would_ like to try some of
> these possibilities as tests though, to see whether they fix our problems.
> If the use of activation triggers works that could be really sweet...
>
>          Michael
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss