Experimental Physics and
Industrial Control System

Jeff Hill <[email protected]> · Tue, 17 Dec 1996 16:07:48 -0700

Chip wrote:

> 
> >1) The scan tasks consume enough CPU so that the server is
> >starved for CPU.
> >       SOLUTION=> split into two IOCs or buy new CPU
> 
> The starvation is random and not sustained, and it is wasteful to
> double the CPU power of the entire system to deal with this problem.
> Approximate cost for this solution: $200,000.

Systems that respond to asynchronous events typically have 
periods of inactivity followed by intense periods of 
activity. IMHO CEBAF is a large facility - what is $200,000 
compared to daily labor costs. 

It would be more flexible to have high priority clients (or a
high priority server) which can "break through" during periods of 
high activity. Nevertheless, the system designer will not be relieved of
the burden of determining how the system is to degrade when there
is not enough CPU (ie which scan tasks are allowed to go lacking 
for CPU when a high priority client "breaks through").

> 
> >Another problem: If we make socket calls from the scan tasks
> >then their maximum stack consumption may increase. Do a tt()
> >on one of the event tasks while it is running a few times
> >if you would like to see how many subroutines deep the
> >IP kernel goes.
> 
> This is not a serious problem.  We use this technique in our high
> bandwidth data acquisition systems (>1MB/sec over ethernet), and our
> stack sizes are not that large.  Also, since I am proposing greatly
> reducing the number of stacks, even doubling it is not an issue.

Yes, but can we afford to incur the latency required to send
to N clients from the scan tasks (when N is essentially unbounded).
Also, if the client is busy then we have only a one deep queue
and we are more likely to loose intermediate events.

Note that we intend to let the clients pick the event queue depth 
(up to some configured maximum) in the future. OPI clients
will no-doubt prefer a queue depth of one. Archival clients may 
opt for a maximum queue depth (perhaps the default). This
is simply a matter of adding another client call (the server
internals already support it).

> 
> >Con: No preemptive multi-tasking. ie the alarm client is not allowed to be
> >serviced at a higher priority than some of the scan tasks etc. We dont do
> >this now but perhaps we would like to.
> 
> We could deal with this by having multiple servers, i.e. a known port for
> high priority, another for medium, another for low.

This is an interesting option - but all of those extra tasks
are so messy :)

Jeff

-- 
______________________________________________________________________
Jeffrey O. Hill                 Internet        [email protected]
LANL MS H820                    Voice           505 665 1831
Los Alamos, NM 87545 USA        FAX             505 665 5107

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System