II_POLLDELAY

Description of II_POLLDELAY
---------------------------

	II_POLLDELAY is used to affect the INGRES event system and the event 
systems job is to act as central waiting point for all possible operations 
for a which a server must wait to complete. There are two class of events 


   - Memory Events
	Events signalled through shared memory...
   - OS Events
	Events signalled through some operating system mechanism...


II_POLLDELAY directly effects the OS events system so the following is a 
description of this system...


	The central waiting point is a routine called 'iiCLpoll', which 
is a wrapper for one of the following system calls 'select' or 'poll'.
Hence when you run 'truss' etc... on the server you see it wating one of 
these system calls, specifically 'poll' on the DRS6000.

OS events are setup by calls to a routine called 'iiCLfdreg' which 
registers a file descriptor with 'iiCLpoll' so that when operations are 
possible on that FD the server can perform them, usually these 
operations are peformed in completion routines passed to 'iiCLfdreg'.

So communications over pipes, FE to BE, will wake 'iiCLpoll', also the 
slave processes wake 'iiCLpoll' by sending a single byte on a pipe which 
has been registered via 'iiCLpoll' this is event is used to abort 
'iiCLpoll' as the slave then communicates through shared memory.

The idle loop of the server calls 'CS_find_events' before callling 
'iiCLpoll' and the 'CS_find_events' call will discover any memory events 
by examining shared memory.

>'Now we get to the interesting bit...ie the bit which explains why when 
>the server is busy it takes along time for a user to connect'


When a server is busy, 'CS_find_events' is called between every thread 
switch to poll for memory events BUT 'iiCLpoll' is called occasionaly 
to poll for OS events ie such as FE/BE communications...the reason being 
is that it is an expenisive call, peformance wise...

>So how does II_POLLDELAY effect the calling of 'iiCLpoll' ?.....

The events system keeps track of time by the following process the 
DMFRCP process has a timer, II_RCP_TIMER,  that expires regulary for its 
own need, i assume group commit timer, this timer is used to increment a
shared memory counter.
	This counter is used to avoid calling 'iiCLpoll' between every 
thread switch, for the reason stated above, the event system examines 
this timer to determine on which thread switch to call 'iiCLpoll'. The 
symbol 'II_POLLDELAY' can bet set to determine the number of 
milliseconds between each call to 'iiCLpoll'.

So if you decrease 'II_POLLDELAY' the default is 500 milliseconds 
'iiCLpoll' is called more often and any user who is sending information 
to the server will be seen much quicker...the overhead being that 
anywork done by the server will take longer to complete as more of the 
machines time is spent in 'system' and not 'user' mode.


All the above is thanks to Rich Muth
Ingres Q & A
Back to William's Home Page
Email William