[evla-sw-discuss] model propagation idea

[Kevin Ryan]

I'm sorry, but I don't understand the need for file descriptors with  
regard to sending a datagram over 1 of a choice of 128 ports.


On May 19, 2008, at 11:46 AM, Barry Clark wrote:

> 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
>>
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss