[evla-sw-discuss] model propagation idea

[Barry Clark]

I have a vague worry about this scheme in that in the executor we have
been having trouble lately with "Too many open file descriptors."  Yes,
I have a file descriptor leak, which I should be able to find, but I can't.
Yes, the permissible number of open file descriptors is a system generation
parameter, but I would very much like to stay as much as possible with a
generic system for mchost.  Therefore, I am a bit worried about allocating
108 file descriptors.  I would prefer to allocate 27, one per antenna.  
Is the station board MIB too busy to ignore the other three messages it would
get?

> From evla-sw-discuss-bounces at donar.cv.nrao.edu  Mon May 19 11:13:38 2008
> 
> Barry's worst-case scenario for sending delay models to the  
> correlator specified about 5 models/sec per Station Board.  I did  
> some testing on Friday with a CMIB here in the office and found that  
> it could handle a good 50 models/sec even using the REST/TCP  
> interface so that should be no problem.
> 
> Where we are concerned is with the MCCC re-distributing these 600  
> models/sec.  Barry's testing indicated that processing at that rate  
> taxed his machine quite a bit.  This processing would be of the form  
> of parsing model XML, reading an Antenna/Baseband id, mapping that to  
> a rack/crate/slot, and then sending it off to it.
> 
> Bruce and I discussed a possible way to re-distribute the models  
> without the MCCC having to parse the XML and I would like to get your  
> thoughts about it (especially Barry's).
> 
> The idea is to map port numbers to antenna and baseband numbers.  We  
> would use a block of 128 ports, each one mapped to a particular  
> antenna/baseband.  The MCCC would listen on all 128 ports and know  
> which station board to send the delay to based on which port it was  
> received on.  In other words, the outside of the VCI would see the  
> ports as antennas and basebands and the inside would see them as rack/ 
> crate/slot destinations.
> 
> Since Barry would ignore any responses from the VCI for delay models  
> anyway, and since he and Ken indicated that it is no big deal if a  
> few models are dropped, then I suggest that we just keep it unicast  
> UDP between the Executor and the VCI.  I'll probably continue with  
> the REST/TCP that is currently in use with the CMIBS unless we see a  
> need to change it.
> 
> Does anybody have issues with this port mapping scheme or the unicast  
> UDP between Executor and the VCI for the delay models ?
> 
> 
> Kevin
>   
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
>