Hi,

i've tried to get an ntp server running on the router.

when the server runs a while i get:

Oct  9 21:57:47 (none) syslog.info -- MARK --
Oct  9 21:58:03 (none) kern.info ntpd[2367]: adjusting local clock by 4.410640s
Oct  9 21:58:34 (none) kern.info ntpd[2367]: adjusting local clock by 4.407322s
Oct  9 21:59:04 (none) kern.info ntpd[2367]: adjusting local clock by 4.321437s
Oct  9 21:59:35 (none) kern.info ntpd[2367]: adjusting local clock by 4.458682s
Oct  9 22:03:38 (none) kern.info ntpd[2367]: adjusting local clock by 4.651436s
Oct  9 22:07:16 (none) kern.info dropbear[2353]: exit after auth (root): Exited normally
Oct  9 22:07:38 (none) kern.info ntpd[2367]: adjusting local clock by 4.819689s
Oct  9 22:11:41 (none) kern.info ntpd[2367]: adjusting local clock by 4.957727s
Oct  9 22:15:16 (none) kern.info ntpd[2367]: adjusting local clock by 4.989818s
Oct  9 22:17:48 (none) syslog.info -- MARK --
Oct  9 22:19:21 (none) kern.info ntpd[2367]: adjusting local clock by 5.048912s
Oct  9 22:20:49 (none) kern.info ntpd[2367]: adjusting local clock by 5.149886s

so like you see the time drift is getting larger, or it looks like the ntp server isn't setting the time..

The server i used is openntp, and it uses the adjtime systemcall. I googled a bit and found, that the most time functions on linux/mips are broken until 2.4.22.

So is it possible to build a current kernel? (and not the old 2.4.20?)

I'm preparing an ipkg of the lastest openntpd version. I'm running the daemon for a week now and everything seems fine.
I have include a linux specific patch that use adjtimex (instead of adjtime). This patch also use settimeofday on the first time adjustement if delta is more than 5s.
I have also remove OpenSSL requirement.

You can download the ntpd binary at http://www.tuxfan.net/ntpd
md5sum: fdbfb86e257334c7b03b75ea9ef26ffb

Thanks, looks good. In the meanwhile a experimented a bit with the newest version of ntpclient, which uses some small Linksys patches. This binary also uses the  adjtimex.

I'll try your bin here.. :-)

I installed this newer NTP server binary, but it doesn't seem to regulate the time very well, the difference finally becoming nearly a full minute:
@router:/# diff
Wed Oct 20 17:28:47 2004
Wed Oct 20 17:27:45 UTC 2004

Where:

# alias diff
diff='rdate -p time.nist.gov; date'

Hum?

Strange. I get much a better result even if the clock is not very accurate and stable. I have a WRT54GS.

root@wrt:~# rdate -p time.nist.gov; date
Wed Oct 20 22:33:10 2004
Wed Oct 20 22:33:10 CEST 2004
root@wrt:~# logread |grep ntpd|tail -10
Oct 20 19:59:37 (none) kern.info /usr/sbin/ntpd[295]: adjusting local clock by -0.028441s
Oct 20 19:59:37 (none) kern.info /usr/sbin/ntpd[295]: interval 2383.175 skew -11.934 total skew 466.423
Oct 20 20:35:21 (none) kern.info /usr/sbin/ntpd[295]: adjusting local clock by -0.039822s
Oct 20 20:35:21 (none) kern.info /usr/sbin/ntpd[295]: interval 2143.323 skew -18.579 total skew 465.981
Oct 20 21:05:11 (none) kern.info /usr/sbin/ntpd[295]: adjusting local clock by -0.079160s
Oct 20 21:05:11 (none) kern.info /usr/sbin/ntpd[295]: interval 1790.615 skew -44.208 total skew 464.953
Oct 20 21:40:54 (none) kern.info /usr/sbin/ntpd[295]: adjusting local clock by -0.033653s
Oct 20 21:40:54 (none) kern.info /usr/sbin/ntpd[295]: interval 2143.067 skew -15.703 total skew 464.596
Oct 20 22:12:05 (none) kern.info /usr/sbin/ntpd[295]: adjusting local clock by -0.069914s
Oct 20 22:12:05 (none) kern.info /usr/sbin/ntpd[295]: interval 1870.808 skew -37.370 total skew 463.765

Can you post the output of 'logread|grep ntpd|tail -24' ?
How many ntp servers are you using ?
I use 3 different ntp servers all located in my own country.

I have build a new openntpd package.
This package provides an init script and includes the patch to use settimeofday on the first time adjustement is delta is more than 5s.

You can download it from http://www.itux.net/ipkg/.

Here is the syslog after a reboot:

Jan  1 00:00:20 (none) kern.info /usr/sbin/ntpd[295]: listening on 10.0.0.253
Jan  1 00:00:20 (none) kern.info /usr/sbin/ntpd[295]: ntp engine ready
Jan  1 00:00:38 (none) kern.info /usr/sbin/ntpd[295]: peer 212.37.192.31 now valid
Jan  1 00:00:38 (none) kern.info /usr/sbin/ntpd[295]: peer 84.207.3.34 now valid
Jan  1 00:00:38 (none) kern.info /usr/sbin/ntpd[295]: peer 82.228.182.88 now valid
Jan  1 01:01:23 (none) kern.info /usr/sbin/ntpd[294]: adjusting local clock by 151859999.476375s
Oct 23 17:21:23 (none) kern.info /usr/sbin/ntpd[294]: setting clock with settimeofday
Oct 23 17:33:33 (none) kern.info /usr/sbin/ntpd[294]: adjusting local clock by 0.315798s
Oct 23 17:33:33 (none) kern.info /usr/sbin/ntpd[294]: interval 0.000 skew 0.000 total skew 0.000

I was trying to get the output requested above, but seeing this latest post, instead I have installed the new package and will see how it performs on my WRT54GS.

Further to my posting just above: I have managed to upgrade to the 20041025 snapshot, re-install your latest openntpd package and get the result of 'logread|grep ntpd|tail -24':
---
Jan  1 00:12:48 (none) kern.info /usr/sbin/ntpd[1652]: listening on 192.168.1.254
Jan  1 00:12:48 (none) kern.info /usr/sbin/ntpd[1652]: ntp engine ready
Jan  1 00:13:03 (none) kern.info /usr/sbin/ntpd[1652]: peer 192.43.244.18 now valid
Oct 25 21:36:40 (none) kern.info /usr/sbin/ntpd[1651]: adjusting local clock by 152054575.696233s
Aug 20 18:59:35 (none) kern.info /usr/sbin/ntpd[1651]: setting clock with settimeofday
Oct 25 21:38:20 (none) kern.info /usr/sbin/ntpd[1652]: ntp engine exiting
Oct 25 21:38:20 (none) kern.info /usr/sbin/ntpd[1651]: Terminating
Oct 25 21:38:34 (none) kern.info /usr/sbin/ntpd[1676]: listening on 192.168.1.254
Oct 25 21:38:34 (none) kern.info /usr/sbin/ntpd[1676]: ntp engine ready
Oct 25 21:38:50 (none) kern.info /usr/sbin/ntpd[1676]: peer 192.43.244.18 now valid
Oct 25 21:39:35 (none) kern.info /usr/sbin/ntpd[1675]: adjusting local clock by -3.824411s
Oct 25 21:39:35 (none) kern.info /usr/sbin/ntpd[1675]: interval 0.000 skew 0.000 total skew 0.000
---
I will check from time to time the performance of the package and post here.  At the moment I have:
---
# alias diff='rdate -p time.nist.gov; date'
# diff
Mon Oct 25 21:45:17 2004
Mon Oct 25 21:45:20 UTC 2004
---

With the new snapshot and ntp package as posted by me just above, things are much better, the server has kept my WRTGS's time accurate over the last several days.  Thanks for producing this package!

Is this working for the longer term? I've noticed it was working for a while, but for example this morning, uptime about 25 days, the adjustment had been increasing again. Here's some lines from my log:

[code]Jan 18 03:53:21 (none) kern.info /usr/sbin/ntpd[1314]: adjusting local clock by 269.185043s
Jan 18 03:53:21 (none) kern.info /usr/sbin/ntpd[1314]: interval 0.000 skew 0.000 total skew -479.097
Jan 18 03:57:21 (none) kern.info /usr/sbin/ntpd[1314]: adjusting local clock by 269.312184s
Jan 18 03:57:21 (none) kern.info /usr/sbin/ntpd[1314]: interval 0.000 skew 0.000 total skew -479.097
Jan 18 04:01:22 (none) kern.info /usr/sbin/ntpd[1314]: adjusting local clock by 269.370907s
Jan 18 04:01:22 (none) kern.info /usr/sbin/ntpd[1314]: interval 0.000 skew 0.000 total skew -479.097
Jan 18 04:05:23 (none) kern.info /usr/sbin/ntpd[1314]: adjusting local clock by 269.487858s
Jan 18 04:05:23 (none) kern.info /usr/sbin/ntpd[1314]: interval 0.000 skew 0.000 total skew -479.097
Jan 18 04:09:24 (none) kern.info /usr/sbin/ntpd[1314]: adjusting local clock by 269.563775s
Jan 18 04:09:24 (none) kern.info /usr/sbin/ntpd[1314]: interval 0.000 skew 0.000 total skew -479.097
Jan 18 04:13:25 (none) kern.info /usr/sbin/ntpd[1314]: adjusting local clock by 269.676870s
Jan 18 04:13:25 (none) kern.info /usr/sbin/ntpd[1314]: interval 0.000 skew 0.000 total skew -479.097
Jan 18 04:17:26 (none) kern.info /usr/sbin/ntpd[1314]: adjusting local clock by 269.776935s
[/code]

I admit I was running the older release of the package, 3.6.1p1-2.wrt and have now upgraded to 3.6.1p1-4.wrt.

By the way, is it possible to use this as a time server, so that other clients could connect to my WRT54GS and use it as a ntp server? If I put the listen option in ntpd.conf, then ntpd won't start...[/code]

You must use the 3.6.1p1-4.wrt package.
The 'Listen *' directive is broken on wrt. You must specify the IP address. The problem comes from a function that is not present in uClibc.

OK. It seems to work so far, but there are some comments in the log that seem alarming, "skew change exceeds limit". Are these a problem?

Jan 18 11:33:05 (none) kern.info /usr/sbin/ntpd[374]: adjusting local clock by 0.272793s
Jan 18 11:40:54 (none) kern.info /usr/sbin/ntpd[374]: adjusting local clock by 0.255890s
Jan 18 11:49:31 (none) kern.info /usr/sbin/ntpd[374]: adjusting local clock by 0.243616s
Jan 18 11:49:31 (none) kern.info /usr/sbin/ntpd[374]: skew change 471.459 exceeds limit
Jan 18 12:00:54 (none) kern.info /usr/sbin/ntpd[374]: adjusting local clock by 0.187886s
Jan 18 12:00:54 (none) kern.info /usr/sbin/ntpd[374]: skew change 137.514 exceeds limit
Jan 18 12:09:59 (none) kern.info /usr/sbin/ntpd[374]: adjusting local clock by 0.189188s
Jan 18 12:09:59 (none) kern.info /usr/sbin/ntpd[374]: skew change 115.720 exceeds limit

It doesn't seem to work with address etiher, I get this:

# /usr/sbin/ntpd -d
listening on 10.0.0.1
fatal: bind: Cannot assign requested address
dispatch_imsg in main: pipe closed
Lost child: child exited
Terminating

No. I have included a linux specific patch that use 'adjtimex' function to synchronize that clock.

can you post your ntpd.conf file and the output of 'ifconfig' ?

ntpd.conf:

# Addresses to listen on (ntpd does not listen by default)
#listen on *
# listen on 127.0.0.1
# listen on ::1
# listen on 192.168.1.3
listen on 10.0.0.1
#listen on 10.0.0.2

# use a random selection of 8 public stratum 2 servers
# see http://twiki.ntp.org/bin/view/Servers/NTPPoolServers
#servers europe.pool.ntp.org

# Sync to the first active address these resolve to
server ntp.saunalahti.fi
server fi.pool.ntp.org
server se.pool.ntp.org
server europe.pool.ntp.org
#server ntp.inet.fi

ifconfig output, my config isn't exactly common. I suppose my use of an IP alias might be a problem. I noticed when I was setting up the box that for example udhcpc can get a DHCP lease for an alias interface, but can't renew the lease.

eth0      Link encap:Ethernet  HWaddr 00:0F:66:D3:99:DE
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:2772 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3715 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:259460 (253.3 KiB)  TX bytes:375835 (367.0 KiB)
          Interrupt:5 Base address:0x2000

eth1      Link encap:Ethernet  HWaddr 00:0F:66:D3:99:E0
          inet addr:10.0.1.6  Bcast:10.0.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:2291
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:4 Base address:0x1000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vlan0     Link encap:Ethernet  HWaddr 00:0F:66:D3:99:DF
          inet addr:85.76.10.228  Bcast:85.255.255.255  Mask:255.255.252.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2771 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3715 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:209514 (204.6 KiB)  TX bytes:375835 (367.0 KiB)

vlan0:0   Link encap:Ethernet  HWaddr 00:0F:66:D3:99:DF
          inet addr:10.0.0.6  Bcast:10.0.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

No interface has IP address 10.0.0.1 ... so you can't have ntpd listening on that IP address.
Try 10.0.0.6. You can use multiple Listen directive to listen on multiple interfaces.

Yes, my bad. I thought the listen directive was a kind of access control, to select which clients can connect... It seems to be working now.