[evlatests] Missing Modcomp-Free data

[Pete Whiteis]

I've tried this awhile back without any luck.  Data still got dropped 
when users mucked around.   Is this something which works better under 
2.6?  

Bruce Rowen wrote:

>The kernel allows preemption. You could (and probably should) spawn  
>whatever user side tasks that are running with a 'nice -20' to give  
>them priority.
>
>-Bruce
>
>On Jun 12, 2007, at 3:27 PM, Pete Whiteis wrote:
>
>  
>
>>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
>>>
>>>
>>>      
>>>
>><pwhiteis.vcf>
>>_______________________________________________
>>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/784cdce2/attachment.vcf>