[LinuxPPS] RT vs process sched tuning?

[Hal V. Engel]

On Tuesday 14 April 2009 11:52:16 pm Bernhard Schiffner wrote:
> On Wednesday 15 April 2009 04:16:10 Steve Logue wrote:
> > Hi,
> >
> > Has anyone with a working RT kernel compared the performance of the RT
> > patched vs. running ntpd in an elevated scheduling class/priority?
> >
> > Eg:  sudo chrt -f 99 /usr/local/bin/ntpd -c /etc/ntp.conf
> >
> > Wouldn't this accomplish nearly the same consistency?
> >
> > -STEVEl
>
> No, I don't have by hand.
>
> Nevertheless I don't expect to see any difference regarding PPS.
> PPS is in the kernel. So tuning NTPD may improve some behavior of ntpd,
> but not the "database".
>
> Bernhard

In fact where the consistency is needed is with the interrupt handler that is 
part of the kernel and variable latency of ntpd likely has no affect on this 
at all.  The PPS related architecture is divided into two parts the first is 
the part in the kernel that handles the PPS interrupt and for the most part 
all it does is grabs the system time stamp and then stores it off for use by 
ntpd when there is a PPS interrupt.  This is the part that is sensitive to 
latency.  The second part is ntpd and it run after the PPS interrupt handler 
has run.  All it does is gets the time stamp stored by the kernel PPS 
interrupt handler and uses that information to make clock adjustments.  The 
only timing requirement for the second set of actions is that they happen 
before the next PPS interrupt and this does not require real time priority.

On my machine the process that contains the PPS interrupt handler is named 
"serial" and this is the process that I have been running with high real time 
priority.  But I think it would also work (perhaps even better - I have not 
tested it) to bump IRQ-3 (in my cases this is the IRQ of the serial port where 
I have PPS) up to very high rt priority since that would increase the priority 
of the interrupt handler directly.  But this might be logically the same as 
setting the priority of "serial" to the same level since the system knows that 
"serial" is the interrupt handler for irq 3. 

/etc/init.d/rtirq restart
 * Service rtirq stopping                                                                             
 * Service rtirq stopped                                                                              
 * Service rtirq starting                                                                             
Setting IRQ priorities: start [serial] irq=3 pid=4633 prio=85: OK.                                    
 * Service rtirq started 

Hal