Date: Fri, 06 Jan 95 08:26:47 -0500 From: knight@zko.dec.com To: hackers@freebsd.org Cc: knight@zko.dec.com Subject: ntpdate (apparently lost in yesterday's mailing list funny stuff) Message-ID: <9501061326.AA08207@caboom.zko.dec.com>
next in thread | raw e-mail | index | archive | help
I've been experimenting with ntpdate from FreeBSD 2.0R for the last few days. My results have been a bit surprising (to me at least) at best; I thought you might be interested in the results, though. #1: Doing the following sample command: ntpdate -b -d xxx.yyy.com has interesting results: if xxx.yyy.com is a FreeBSD 2.0R system, it works. if xxx.yyy.com is an OSF/1 2.0 or 3.0, or ULTRIX or BSDi system, it fails, specifically, the messages are not responded to by the remote system. If, instead, I do: ntpdate -o2 -b -d xxx.yyy.com then everything works for the previously non-working systems. So it looks like the version 3 protocol is not quite right on the FreeBSD side. #2: If I run the ntpdate command from a FreeBSD system that has /etc/wall_cmos_clock enabled, ntpdate reports an offset of 17981.*** which, just happens to be the 5 hour offset to UTC from local time. Fwiw, xntpd, when used, also shows the same offset. Would it be desirable for the wall_cmos_clock to be taken into consideration when this calculation is made? Or is this too much of a hack/problem? Or, better yet, have I got something wrong in my kernel configuration? Thanks. ------ Dave Knight knight@zko.dec.com (work) knight@ka1dt.mv.com (home)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9501061326.AA08207>