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

Michael Rupen mrupen at nrao.edu
Wed Apr 2 13:04:57 EDT 2014


> 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.

If you go to the CC level I'm not sure this is much less flexible.
The CBE nodes (actually NICs) probably must be shared, given the
way the CBE arranges things at the moment, but that's a detail.
Unfortunately such an overall change of philosophy would probably
need a fair bit of work. But it would be fun to think this through
a bit further.

    Michael



More information about the evla-sw-discuss mailing list