# SLES 10.3 NTP offset

**URL:** <https://forums.suse.com/t/sles-10-3-ntp-offset/22972>\
**Category:** SLES Configure-Administer\
**Created:** [August 15, 2012, 3:36pm UTC](https://forums.suse.com/t/sles-10-3-ntp-offset/22972 "2012-08-15T15:36:49Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![tbrinkmann](https://avatars.discourse-cdn.com/v4/letter/t/e99b99/32.png) [@tbrinkmann](https://forums.suse.com/u/tbrinkmann)\
**Post date:** [August 15, 2012, 3:36pm UTC](https://forums.suse.com/t/sles-10-3-ntp-offset/22972/1 "2012-08-15T15:36:49Z")

</div>

Hi all,  
could anyone help me understanding NTP offset problem.

We have several servers with SLES and NTP running. On many systems there are no problems with NTP. But at two or three systems the  
NTP offset runs crazy.

If you can see here the ntpq -np command lists the offset in -4989.8.

# #\> ntpq -np remote refid st t when poll reach delay offset jitter

10.115.204.1 192.53.103.104 2 u 304 512 377 0.393 -4989.8 2816.26

As I find somewhere in the documentation the offset is a measured time between the last 8 requests and the system time.  
But if I use date the system time is running fine. There is no offset the time is the exact the time within the timeserver.

Why does the offset is so high on this machine ?

Thanks for advice.

---

<div class="post-metadata">

**Author:** ![tbrinkmann](https://avatars.discourse-cdn.com/v4/letter/t/e99b99/32.png) [@tbrinkmann](https://forums.suse.com/u/tbrinkmann)\
**Post date:** [August 15, 2012, 4:05pm UTC](https://forums.suse.com/t/sles-10-3-ntp-offset/22972/2 "2012-08-15T16:05:33Z")

</div>

WoW ! It looks like that only the SLES-10.3 systems have this problem.

---

<div class="post-metadata">

**Author:** ![Willem1](https://avatars.discourse-cdn.com/v4/letter/w/c57346/32.png) [@Willem1](https://forums.suse.com/u/Willem1)\
**Post date:** [August 15, 2012, 5:05pm UTC](https://forums.suse.com/t/sles-10-3-ntp-offset/22972/3 "2012-08-15T17:05:40Z")

</div>

> [@tbrinkmann;6259](#):
>
> WoW ! It looks like that only the SLES-10.3 systems have this problem.

Hi,

Is this on virtual or physical servers?  
Could you list the kernel and ntp packages that are installed on the system (to determinate patchlevels)?

Also you mention this in only on SLES 10.3… what other systems/versions are you running where you are not seeing this?

Cheers,  
Willem

---

<div class="post-metadata">

**Author:** ![malcolmlewis](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/malcolmlewis/32/11375_2.png) [@malcolmlewis](https://forums.suse.com/u/malcolmlewis)\
**Post date:** [August 15, 2012, 5:05pm UTC](https://forums.suse.com/t/sles-10-3-ntp-offset/22972/4 "2012-08-15T17:05:59Z")

</div>

> [@tbrinkmann](#):
>
> Hi all,  
> could anyone help me understanding NTP offset problem.
> 
> We have several servers with SLES and NTP running. On many systems  
> there are no problems with NTP. But at two or three systems the  
> NTP offset runs crazy.
> 
> If you can see here the ntpq -np command lists the offset in -4989.8.
> 
> # #\> ntpq -np remote refid st t when poll reach delay offset jitter
> 
> 10.115.204.1 192.53.103.104 2 u 304 512 377 0.393 -4989.8  
> 2816.26
> 
> As I find somewhere in the documentation the offset is a measured time  
> between the last 8 requests and the system time.  
> But if I use date the system time is running fine. There is no offset  
> the time is the exact the time within the timeserver.
> 
> Why does the offset is so high on this machine ?
> 
> Thanks for advice.

Hi  
Maybe it’s loosing touch with the ntp server it’s syncing too?

Have you checked to logs for any further info, maybe the daemon is  
dying?

What if you watch the process and maybe run tcpdump (filter for ntp),  
for example

```auto
watch ntpq -np

tcpdump -i eth0 udp port 123
```

–  
Cheers Malcolm Â°Â¿Â° (Linux Counter #276890)  
SUSE Linux Enterprise Desktop 11 (x86\_64) Kernel 3.0.34-0.7-default  
up 17 days 10:26, 3 users, load average: 0.31, 0.31, 0.33  
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU
