[LinuxPPS] So far, so good

[Hal V. Engel]

On Tuesday 10 August 2010 01:29:39 am Miroslav Lichvar wrote:
> On Mon, Aug 09, 2010 at 03:11:59PM -0700, Hal V. Engel wrote:
> > > Isn't that a change in frequency caused by increased temperature
> > > rather than increased latency?
> >
> > Both probably come into play.  If it were mostly temperature it would
> > take a little while for the oscillator to be affected but I find that my
> > system will start showing increased offsets with in a few seconds of the
> > change in system load and then stabilize in a few minutes.  If the
> > primary issue was temperature related then I would expect it to take
> > several minutes for the temperature of the oscillator to change enough to
> > cause this but since it is almost instantaneous I think it is mostly
> > caused by the increased latency of the interrupt handler.   Also if I do
> > a single threaded build on my dual core system I don't see the quick
> > change in the offset that I do with a multi- threaded build.  Of course
> > the single threaded build generates less heat but it also will have much
> > less impact on the latency of the interrupt handler since one core is
> > sitting idle and can service the interrupt very quickly.
> 
> Interesting. What sign has the offset you see? If it was an increase
> in the latency I'd expect it to be in the opposite direction than the
> change caused by increased temperature.


If I remember correctly (I just moved and don't have my refclock set up yet) 
the offset went negative when I loaded the machine and then positive when the 
machine was unloaded.  But it's been a while since I ran these tests so my 
memory may be faulty.

> 
> > Of course we can do little more than speculate on this since we don't
> > have any way to measure the interrupt handler latency.  About the only
> > way to test this would be to use a machine with a temperature controlled
> > oscillator as a test bed.  If loading such a machine causes significant
> > changes to the offset then that affect can probably be attributed to
> > latency rather than temperatures. But I don't have a machine like this to
> > test with.
> 
> It should be also possible to get an upper bound by flipping a bit on
> parallel port in the interrupt handler and measuring the delay on a
> scope.
>