Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 1 Mar 2007 09:22:35 -0700

Kay,

My understanding is that tNetTask takes care of all network stack labor that
can't be done in the threads calling socket entry points, and is also
inappropriate for execution at interrupt level. 

We have long suspected that there is a flaw in the vxWorks implementation
where its IP kernel can get sick if thread activity running at priorities
higher than tNetTask preempt tNetTask for too long. Hopefully this will
improve over time. For now we have acquiesced to run most of EPICS at a
priority below tNetTask.

What isn't well understood (at least by me) is the maximum duration of a
tNetTask preemption of lower priority threads such as the scan tasks.

> Doesn't a tNettask at a high priority mean that even if we
> otherwise move all the CA tasks to the bottom, network
> traffic will still disturb the scanning?

No question that for proper degradation under load that the CA server needs
to run at a priority below the scan tasks. That design decision is I think
orthogonal to any defects that may or may not exist in the vxWorks
implementation.

Jeff

> -----Original Message-----
> From: Kay-Uwe Kasemir [mailto:[email protected]]
> Sent: Thursday, March 01, 2007 7:44 AM
> To: tech talk
> Subject: Re: task priorities, busy cpu, and timeout
> 
> On Mar 1, 2007, at 06:27 , Benjamin Franksen wrote:
> > I have made a start by quickly compiling teh following table from
> > vxWorks
> > console output and what I found in the sources. It might be incomplete
> > and/or erroneous.
> 
> For what it's worth, I think
> > ipToAsciiPr      189    10=Low            ???
> is the task that CA uses to resolve host names for IP addresses.
> 
> > Apart from filling in missing information (see question marks), it
> > might be
> > sensible to have some sort of rationale for the relative
> > priorities. For
> > instance, it is unclear to me why the timerQueue task has higher
> > priority
> > than cbLow task.
> 
> I'm really unclear about another task where I wonder if it
> disturbs the intended order of things:
> On vxWorks, there's the "tNetTask" at a very high priority.
> At the SNS, we have had problems whenever that task doesn't get
> to run as often as it wants to. When computations that can take
> millisecs run higher than tNetTask, the result is an irrecoverable
> messup of the network stack, at least with our 5.5.1 kernels
> on MVME 2100 CPUs.
> It might make sense that the network chips require to be serviced
> right away, or maybe that's just an imperfection in our version
> of the network code, fixed in more recent vxWorks versions,
> but in any case:
> Doesn't a tNettask at a high priority mean that even if we
> otherwise move all the CA tasks to the bottom, network
> traffic will still disturb the scanning?
> 
> -Kay
> 
> 
> >                             EPICS TASKS
> > ======================================================================
> >
> >     NAME        VX_PRI  OSI_PRI                    DESCRIPTION
> > -------------   ------  -------           ----------------------------
> > ts_Casync        109    90=High           drvTS (apsEvent module)
> > TSwdIncTime      109    90=High           drvTS (apsEvent module)
> > cbHigh           128    71=ScanHigh+1     callback task (prio=high)
> > timerQueue       129    70=ScanHigh       scan task
> > scanOnce         129    70=ScanHigh       scan task
> > scan0.1          133    66=ScanLow+6      scan task
> > scan0.2          134    65=ScanLow+5      scan task
> > cbMedium         135    64=ScanLow+4      callback task (prio=medium)
> > scan0.5          135    64=ScanLow+4      scan task
> > scan1            136    63=ScanLow+3      scan task
> > scan2            137    62=ScanLow+2      scan task
> > scan5            138    61=ScanLow+1      scan task
> > scan10           139    60=ScanLow        scan task
> > timerQueue       139    60=ScanLow        epicsTimer
> > cbLow            140    59=ScanLow-1      callback task (prio=low)
> > asCaTask         142    57=ScanLow-3      access security
> > CAC-UDP          147    52=Medium+2       CA client
> > timerQueue       148    51=Medium+1       epicsTimer
> > CAC-event        148    51=Medium+1       CA client
> > dbCaLink         149    50=Medium         CA links (client? server?)
> > poolPoll         149    50=Medium         ???
> > CAC-event        178    21=CAServerLow+1  CA Server
> > CAS-TCP          181    18=CAServerLow-2  CA Server
> > CAS-beacon       182    17=CAServerLow-3  CA Server
> > CAS-UDP          183    16=CAServerLow-4  CA Server
> > errlog           189    10=Low            errlog
> > taskwd           189    10=Low            task watchdog
> > ipToAsciiPr      189    10=Low            ???
> > CAC-repeate      189    10=Low            CA Client (repeater)
> >
> > Cheers
> > Ben
> > --
> > "Programming = Mathematics + Murphy's Law" (Dijkstra in EWD1008)

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System