# Skew change exeeds limit

## Jaglover

I'm getting this

```
Mar 26 04:24:52 sipp ntpd[1581]: adjusting local clock by -0.357014s

Mar 26 04:24:52 sipp ntpd[1581]: skew change -112.925 exceeds limit

Mar 26 04:30:01 sipp cron[31258]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

Mar 26 04:32:24 sipp ntpd[1581]: adjusting local clock by -0.258572s

Mar 26 04:32:24 sipp ntpd[1583]: clock is now unsynced

Mar 26 04:36:35 sipp ntpd[1581]: adjusting local clock by -0.197251s

Mar 26 04:40:01 sipp cron[4671]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

Mar 26 04:44:20 sipp ntpd[1581]: adjusting local clock by -0.154029s

Mar 26 04:44:20 sipp ntpd[1581]: skew change -330.911 exceeds limit

Mar 26 04:44:20 sipp ntpd[1583]: clock is now synced

```

Anybody knows what's going on? The kernel is 38.

----------

## BradN

These messages aren't specifically from the kernel - it's actually from ntpd, a program that sets your clock from a time source on the internet, and cron, an automatic program scheduling thing that looks unrelated.

I'm not exactly sure what's happening with the skew change messages, but if you start reading into how ntpd operates, it might be explained somewhere.

I think for practical purposes, as long as your system clock is staying approximately correct the whole time, there won't be big problems to worry about.  Gentoo in general will experience problems, especially with program compilation if the system clock jumps around to the point of things not making sense.  For example, if you start a program compiling and then set the clock backwards an hour, programs will begin to complain about generated files that have a date in the future (which shouldn't be possible).  As long as ntpd isn't making the clock jump backwards randomly, it should be ok.

----------

## Jaglover

Thanks for reply.

I was actually worried about kernel clocksource or whatever causes this kind of jumping, messages are from ntpd indeed. And I do have problems, not sure if related or not. Actually I looked at messages because I was troubleshooting mysterious MythTV crashes, I'm not sure how well the time has to be synced between frontend and backend but I think precise clock is rather important.

----------

## Anon-E-moose

I have this set in /etc/conf.d/ntpd

```
NTPD_OPTS="-g"
```

check the man page for ntpd options ( -g and -x)

----------

## Jaglover

Thanks for that ... I wonder what man page you were looking at ... my Gentoo boxes do not have these of options in man pages ... but another OS has better man page for ntpd and ntpd.conf. I wonder why we do not have these options in Gentoo [man pages].

----------

## Anon-E-moose

I'm running net-misc/ntp-4.2.4_p7-r1, not sure what you're running, if it's openntpd then they probably have different options.

----------

## Jaglover

This explains it alright. I'm running openntpd in my desktops.

Anyhow, I wasn't really worried about those messages, I was wondering if this is the source of my MythTV troubles.

----------

## BradN

If the kernel detects time sources not acting properly, I believe it throws up a message and disables that time source, but I suppose it's possible it gets confused and uses a timesource that's wrong then.  These problems came up because of a few different problems - bad synchronization of timestamp counter feature on CPU when more than one CPU is used (the CPUs timestamps start to differ), and the timestamp counter rate changing in cases where the CPU frequency is adjusted (usually by power-saving features).  So these types of things might disqualify that particular time source, if I remember there were some problems with HPET bugs that prevented that from working (don't remember the details).

I think you can check earlier dmesg output from around boot time and see what source it's actually using.  Usually it seems to pop up some number of seconds after the kernel's been running, or possibly at a point CPU frequency scaling starts taking effect which may be during or after the main kernel startup.

Once you know what source it's really using, then you can try forcing use of others and maybe it will help.

----------

## Anon-E-moose

 *Jaglover wrote:*   

> This explains it alright. I'm running openntpd in my desktops.
> 
> Anyhow, I wasn't really worried about those messages, I was wondering if this is the source of my MythTV troubles.

 

If the system time is not kept accurate, then it's likely to affect many things that depend on it, 

and it'll show up more with things like MythTV, as stop and start times for programs might be off.

----------

## Jaglover

```
Fast TSC calibration using PIT

Detected 1500.125 MHz processor.

Calibrating delay loop (skipped), value calculated using timer frequency.. 3000.25 BogoMIPS (lpj=1500125)

```

Single VIA C7 CPU, no frequency scaling. There is a patch from VIA to do that, I believe, but I never tried it.

This is about all I see, full dmesg is http://paste.pocoo.org/show/360169/

BTW, if you see anything in that dmesg that needs to be corrected/fixed - comments are welcome.

----------

## Anon-E-moose

What I meant was that if ntpd is not setting the time properly, then it can affect things like MythTV. 

ntpd sets the system time, MythTV uses the system time against the published 

start/stop times for programs to record all of an episode properly

I do not know why you are getting such large amounts of changes in the time. 

It could be something in the kernel, it could be something to do with ntpd, it could be your hardware.

If things were working fine with a previous kernel, you might boot that and run it for a day or so

and check the logs to see if you're still getting all the skew/adjusting clock messages.

----------

