NTP settings on overload network

Hi,

I am using NTPd on overloaded network where delay is going between 7ms
- 1300ms and sometimes NTP wrongly synchronize time +-800s. Is that a
way to properly set up ntp to work on this circumstances.

A log is below:
30 Jun 11:21:45 ntpd[13450]: time reset -0.422695 s
30 Jun 11:21:45 ntpd[13450]: synchronisation lost
30 Jun 11:21:45 ntpd[13450]: system event 'event_clock_reset' (0x05)
status 'leap_none, sync_unspec, 5 events, event_peer/strat_chg' (0x54)
30 Jun 11:21:45 ntpd[13450]: system event 'event_peer/strat_chg' (0x04)
status 'leap_none, sync_unspec, 6 events, event_clock_reset' (0x65)
30 Jun 11:21:57 ntpd[13450]: peer 10.10.0.11 event 'event_reach' (0x84)
status 'unreach, conf, 2 events, event_reach' (0x8024)
30 Jun 11:22:01 ntpd[13450]: peer 10.10.0.12 event 'event_reach' (0x84)
status 'unreach, conf, 2 events, event_reach' (0x8024)
30 Jun 11:59:00 ntpd[13450]: ntpd exiting on signal 15
30 Jun 11:59:05 ntpd[13451]: parent died before we finished, exiting
30 Jun 12:59:00 ntpd[16030]: signal_no_reset: signal 17 had flags
4000000
30 Jun 12:59:00 ntpd[16029]: running as uid(74)/gid(65534)
euid(74)/egid(65534).
30 Jun 12:59:00 ntpd[16029]: frequency initialized -257.571 from
/var/lib/ntp/drift/ntp.drift

[email]markon@gmail.com[/email] wrote:
[color=blue]
> Hi,
>
> I am using NTPd on overloaded network where delay is going between 7ms
> - 1300ms and sometimes NTP wrongly synchronize time +-800s. Is that a
> way to properly set up ntp to work on this circumstances.[/color]
<snip>

Fix the network! AFAIK there is little or nothing that will make NTP
work well under these conditions.

In article <1151666841.775293.92670@i40g2000cwc.googlegroups.com>,
[email]markon@gmail.com[/email] wrote:
[color=blue]
> I am using NTPd on overloaded network where delay is going between 7ms
> - 1300ms and sometimes NTP wrongly synchronize time +-800s. Is that a
> way to properly set up ntp to work on this circumstances.[/color]

"tinker huffpuff" was introduced to cope with the typical case of this
symptom (e.g. lunch time web surfing peaks). The other approach is to
re-compile with a maximum root delay that is only slightly larger than
than needed in non-overloaded times.

In the old days, the network would have been so slow that the maximum
root delay would have been exceeded anyway. It is the increase in
connection speeds for sites with a consumer type traffic profile that
has meant that assymmetric delays don't trigger this limit.
[color=blue]
> A log is below:[/color]

Your log covers an inadequate amount of time to actually show this
symptom properly as the key symptom is balancing positive and
negative steps.

> Fix the network! AFAIK there is little or nothing that will make NTP[color=blue]
> work well under these conditions.[/color]

Please do not thing that it is an easy action to fix overloaded network
and buy new net devices. Of course I am working on it too, but need to
fix NTP now.

A good ideea is to build your own time server and install it "in the
middle" of the network. A GPS one will cost you no more than 200$ (the
GPS receiver and a P2/400MHz from the trash) plus your time to
configure it.