| This box is dhcp'd, but it has a fixed address, so that shouldn't be an
| issue.  I *do* recall having this experience on my laptop, though, with
| much the same workaround, IIRC.

1. /var/run/ntp.drift exists so that one can discipline the PLL
   quickly when re-starting ntpd (e.g. after reboot)

2. it is sensible to terminate ntpd and restart it (with or without -g)
   whenever the local address(es) change

3. sensible != essential; if ntpd can discipline the PLL well by
   virtue of understanding its own track-record, the local time
   should not drift appreciably for a long time (possibly many days)

4. rafal's PLL is fscked

| I bet the reason if loses is it uses sockets bound to <interface-addr>.123,
| so it's probably still sending packets from your old IP address 8-)

xntpd had no smarts wrt this kind of thing because it used to
have to do alot more work within itself, before kernel PLL support
was available.   making any blocking/synchronous system
calls fed imprecision.  we all love how long it can take to do a DNS lookup...

i can't remember if there's a reason why INADDR_ANY isn't bound
for receiving packets from elsewhere, other than that it wouldn't
do obvious enormous good given the nature of the ntp protocol, and
people didn't think of changing numbers with any frequency as
recently as 1995...

	Sean.