[evlatests] Missing Modcomp-Free data

[Bryan Butler]

i was just going to suggest this.  or "reverse nice" the main tasks to give them 
higher than normal priority (% nice -n -20)...

	-bryan


On 6/12/07 15:57, 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