[evlatests] Missing Modcomp-Free data
Bruce Rowen
browen at nrao.edu
Tue Jun 12 17:57:08 EDT 2007
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
More information about the evlatests
mailing list