[evlatests] Missing Modcomp-Free data

[Pete Whiteis]

Its not that the system is fragile in anyway.  Its just that we're 
running LINUX.  LINUX will give all processes running a fair share of 
CPU time.  This means that when someone logs in to poke around when 
vla-bdf-server is collecting data, the OS will pay attention to the 
logged in user, and the data collection task will miss packets coming 
across the wire.   

If you want a system which is capable of robustly collecting data at 
5usec intervals while being able to handle user requests,one needs to 
consider a RTOS w/ preemptible kernel such as VxWorks, Real time Linux, 
Nucleus, etc.  

If one logs into vla-bdf-server, they have to do so knowing they will 
cause data loss and be comfortable with it. 

-Pete-

Bryan Butler wrote:

>i'd like to include somebody actually logging in to it during this operation as 
>part of the test.  seems a fragile system if nobody can touch it while it's running.
>
>	-bryan
>
>
>On 6/12/07 14:12, Walter Brisken wrote:
>  
>
>>So far vispipe has never been found guilty -- more damage has been done 
>>second guessing it.  Perhaps a maximal data rate project should be 
>>observed to see if we can cause it to actually fail.  If this doesn't 
>>happen then we should wait for some really compelling reason to look at it 
>>again.
>>
>>-W
>>
>>On Tue, 12 Jun 2007, Bryan Butler wrote:
>>
>>    
>>
>>>fine - but when i hear statements that vispipe runs at 99% CPU i get worried,
>>>and think that the option of a bigger processor should be considered.
>>>
>>>	-bryan
>>>
>>>
>>>On 6/12/07 14:02, Ken Sowinski wrote:
>>>      
>>>
>>>>On Tue, 12 Jun 2007, Bryan Butler wrote:
>>>>
>>>>        
>>>>
>>>>>we do have the option of replacing the processor for vispipe, don't
>>>>>we?  i
>>>>>vaguely recall that we could upgrade it to the equivalent of one of
>>>>>the CMIB
>>>>>processors pretty trivially.  maybe it's time to look at that.
>>>>>          
>>>>>
>>>>I understand it to be exactly a cmib processor such as the
>>>>ones we are using today.  There is no problem with vispipe.
>>>>Rather we are learning about interactions between the executor,
>>>>correlator, idcaf, vis-pipe and subarrays.  The way to fix the
>>>>problem is to understand the interactions and render them
>>>>harmless; not to look for bigger processors.
>>>>        
>>>>
>>>_______________________________________________
>>>evlatests mailing list
>>>evlatests at listmgr.cv.nrao.edu
>>>http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
>>>
>>>      
>>>
>>_______________________________________________
>>evlatests mailing list
>>evlatests at listmgr.cv.nrao.edu
>>http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
>>    
>>
>_______________________________________________
>evlatests mailing list
>evlatests at listmgr.cv.nrao.edu
>http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
>
>  
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pwhiteis.vcf
Type: text/x-vcard
Size: 144 bytes
Desc: not available
URL: <http://listmgr.nrao.edu/pipermail/evlatests/attachments/20070612/24c932f6/attachment.vcf>