Hello,
Why does a GPS as time source (with ntpd) perform so much worse with 2.6.18?
Udo
On Tue, 2006-10-17 at 17:25 +0200, Udo van den Heuvel wrote:
> Hello,
>
> Why does a GPS as time source (with ntpd) perform so much worse with 2.6.18?
Um... you don't give nearly enough information to even begin to know
what you're talking about.
Lee
Lee Revell wrote:
> On Tue, 2006-10-17 at 17:25 +0200, Udo van den Heuvel wrote:
>> Hello,
>>
>> Why does a GPS as time source (with ntpd) perform so much worse with 2.6.18?
>
> Um... you don't give nearly enough information to even begin to know
> what you're talking about.
?
Offset, error and jitter are higher. That's the performance.
I guess that users of a GPS as clock source understand.
Lee Revell wrote:
> On Tue, 2006-10-17 at 17:25 +0200, Udo van den Heuvel wrote:
>>
>> Why does a GPS as time source (with ntpd) perform so much worse with 2.6.18?
>
> Um... you don't give nearly enough information to even begin to know
> what you're talking about.
No one here with a vague idea about the cause for the bad performance?
I am sure I not the only one experiencing this.
On Wed, 2006-10-18 at 17:20 +0200, Udo van den Heuvel wrote:
> Lee Revell wrote:
> > On Tue, 2006-10-17 at 17:25 +0200, Udo van den Heuvel wrote:
> >>
> >> Why does a GPS as time source (with ntpd) perform so much worse with 2.6.18?
> >
> > Um... you don't give nearly enough information to even begin to know
> > what you're talking about.
>
> No one here with a vague idea about the cause for the bad performance?
> I am sure I not the only one experiencing this.
No, the issue is that a one-sentence bug report is not helpful. You
don't give enough information to debug it. Kernel config, steps to
reproduce, etc, etc.
Please look at LKML archives for some examples of the type of bug report
that does get a response.
Lee
Lee Revell wrote:
> On Wed, 2006-10-18 at 17:20 +0200, Udo van den Heuvel wrote:
>> Lee Revell wrote:
>>> On Tue, 2006-10-17 at 17:25 +0200, Udo van den Heuvel wrote:
>>>> Why does a GPS as time source (with ntpd) perform so much worse with 2.6.18?
>>> Um... you don't give nearly enough information to even begin to know
>>> what you're talking about.
>> No one here with a vague idea about the cause for the bad performance?
>> I am sure I not the only one experiencing this.
>
> No, the issue is that a one-sentence bug report is not helpful. You
> don't give enough information to debug it. Kernel config, steps to
> reproduce, etc, etc.
>
> Please look at LKML archives for some examples of the type of bug report
> that does get a response.
Get the latest kernel.
Compile for your system
Get ntpd.
Configure for your PPS/NMEA source.
Run ntpd.
Watch performance.
Repeat watching of performance.
It is not a crash. Not an oops.
It is stuff that is visible by watching ntpq -pn output, by letting mrtg
graph stuff, etc. Watch the offset and jitter collumns.
Check /usr/sbin/ntpdc -c kerninfo output. Graph that stuff.
Over the monhts you see changes. Some of them you can explain. Some you
can't.
I can understand this is not you everyday bug but this *is* an issue.
On Wed, 18 Oct 2006 18:44:59 +0200, Udo van den Heuvel said:
>
> It is stuff that is visible by watching ntpq -pn output, by letting mrtg
> graph stuff, etc. Watch the offset and jitter collumns.
> Check /usr/sbin/ntpdc -c kerninfo output. Graph that stuff.
So... you've presumably done that while identifying there is an issue.
Please share the results. Have you tried booting back into a 2.6.17
or so and seen offset/jitter improve? etc etc etc.
[added John Stultz to cc]
On Wed, 2006-10-18 at 15:57 -0400, [email protected] wrote:
> On Wed, 18 Oct 2006 18:44:59 +0200, Udo van den Heuvel said:
> >
> > It is stuff that is visible by watching ntpq -pn output, by letting mrtg
> > graph stuff, etc. Watch the offset and jitter collumns.
> > Check /usr/sbin/ntpdc -c kerninfo output. Graph that stuff.
>
> So... you've presumably done that while identifying there is an issue.
> Please share the results. Have you tried booting back into a 2.6.17
> or so and seen offset/jitter improve? etc etc etc.
Udo,
My crystal ball says this is related to the clocksource changes. But at
the very least dmesg and kernel .config is required for debugging.
Also, don't trim CC lists - always use Reply-To-All for LKML threads.
Lee
On Wed, 2006-10-18 at 17:46 -0400, Lee Revell wrote:
> [added John Stultz to cc]
>
> On Wed, 2006-10-18 at 15:57 -0400, [email protected] wrote:
> > On Wed, 18 Oct 2006 18:44:59 +0200, Udo van den Heuvel said:
> > >
> > > It is stuff that is visible by watching ntpq -pn output, by letting mrtg
> > > graph stuff, etc. Watch the offset and jitter collumns.
> > > Check /usr/sbin/ntpdc -c kerninfo output. Graph that stuff.
> >
> > So... you've presumably done that while identifying there is an issue.
> > Please share the results. Have you tried booting back into a 2.6.17
> > or so and seen offset/jitter improve? etc etc etc.
Udo:
Are you running the linuxpps patches, or is this vanilla 2.6.18 without
any additional patches? Mind sending your dmesg and some "ntpdc -c
kerninfo" output? Any of those graphs you mention above would be great
as well.
thanks
-john
john stultz wrote:
> On Wed, 2006-10-18 at 17:46 -0400, Lee Revell wrote:
>> [added John Stultz to cc]
>>
>> On Wed, 2006-10-18 at 15:57 -0400, [email protected] wrote:
>>> On Wed, 18 Oct 2006 18:44:59 +0200, Udo van den Heuvel said:
>>>> It is stuff that is visible by watching ntpq -pn output, by letting mrtg
>>>> graph stuff, etc. Watch the offset and jitter collumns.
>>>> Check /usr/sbin/ntpdc -c kerninfo output. Graph that stuff.
>>> So... you've presumably done that while identifying there is an issue.
>>> Please share the results. Have you tried booting back into a 2.6.17
>>> or so and seen offset/jitter improve? etc etc etc.
>
> Udo:
> Are you running the linuxpps patches, or is this vanilla 2.6.18 without
> any additional patches? Mind sending your dmesg and some "ntpdc -c
> kerninfo" output? Any of those graphs you mention above would be great
> as well.
I am running the latest LinuxPPS patch from Rodolfo Giometti.
# /usr/sbin/ntpdc -c kerninfo
pll offset: -0.002536 s
pll frequency: 20.610 ppm
maximum error: 0.007567 s
estimated error: 0.00046 s
status: 0001 pll
pll time constant: 2
precision: 1e-06 s
frequency tolerance: 512 ppm
# ntpq -pn
remote refid st t when poll reach delay offset
jitter
==============================================================================
127.127.1.0 .LOCL. 10 l 7 64 377 0.000 0.000
0.002
*127.127.20.0 .GPS. 0 l 1 16 377 0.000 -0.268
0.102
-194.109.22.18 193.79.237.14 2 u 257 512 377 5.511 0.951
1.444
+193.67.79.202 .GPS. 1 u 250 512 377 16.862 0.398
4.701
+193.79.237.14 .GPS. 1 u 251 512 377 13.306 -0.001
[cut]
I don't have a dmesg for 2.6.18.1 on this machine (did not save it).
Will do when there is a next reboot of this VIA CL6000E board.
When the machine was idle offset and jitter would be in the 0.00X range.
Now it is more in the 0.XXX range or worse.
Performance for these figures has at least deteriorated a factor of
about 10.
The mrtg graphs are of no use since in the month graph the 'good' part
just moved off the screen and in the year graph the resolution is too
low. :-(
Udo
[email protected] wrote:
> On Wed, 18 Oct 2006 18:44:59 +0200, Udo van den Heuvel said:
>> It is stuff that is visible by watching ntpq -pn output, by letting mrtg
>> graph stuff, etc. Watch the offset and jitter collumns.
>> Check /usr/sbin/ntpdc -c kerninfo output. Graph that stuff.
>
> So... you've presumably done that while identifying there is an issue.
> Please share the results. Have you tried booting back into a 2.6.17
> or so and seen offset/jitter improve? etc etc etc.
Did not yet try 2.6.17 again since I only shortly have been looking into
this issue.
Other people also see worse performance with 2.6.18 so the need to do
the 2.6.17 thing is a bit less.