Re: ntpd jump ahead
hmm, on Fri, Sep 06, 2013 at 07:42:39AM -0400, Nick Holland said that On 09/06/13 04:50, Stuart Henderson wrote: On 2013/09/05 20:03, Barry Grumbine wrote: Non-VM use case: The BeagleBone Black has no RTC, so -j could be useful for cheap little ARM development boards. -s is fine for that (and the same for those of the alix boards with no rtc battery, etc). ...unless the machine isn't attached to the network when initially powered up. Same goes for any machine with a dead RTC battery that may not have a good network connection at boot, and/or you don't want to slow the boot down by 15 seconds if there is no network connection. This shocks people, but I often use a computer where there is no network connection. Waiting for that 15 second boot delay is annoying. a quick and dirty solution could be rdate(8) in crontab(5) -f -- i am not a dictator. it's just i have a grumpy face.
Re: ntpd jump ahead
On 2013/09/05 20:03, Barry Grumbine wrote: Non-VM use case: The BeagleBone Black has no RTC, so -j could be useful for cheap little ARM development boards. -s is fine for that (and the same for those of the alix boards with no rtc battery, etc).
Re: ntpd jump ahead
On 09/06/13 04:50, Stuart Henderson wrote: On 2013/09/05 20:03, Barry Grumbine wrote: Non-VM use case: The BeagleBone Black has no RTC, so -j could be useful for cheap little ARM development boards. -s is fine for that (and the same for those of the alix boards with no rtc battery, etc). ...unless the machine isn't attached to the network when initially powered up. Same goes for any machine with a dead RTC battery that may not have a good network connection at boot, and/or you don't want to slow the boot down by 15 seconds if there is no network connection. This shocks people, but I often use a computer where there is no network connection. Waiting for that 15 second boot delay is annoying. I like the idea. Nick.
Re: ntpd jump ahead
On 2013/09/06 07:42, Nick Holland wrote: On 09/06/13 04:50, Stuart Henderson wrote: On 2013/09/05 20:03, Barry Grumbine wrote: Non-VM use case: The BeagleBone Black has no RTC, so -j could be useful for cheap little ARM development boards. -s is fine for that (and the same for those of the alix boards with no rtc battery, etc). ...unless the machine isn't attached to the network when initially powered up. Same goes for any machine with a dead RTC battery that may not have a good network connection at boot, and/or you don't want to slow the boot down by 15 seconds if there is no network connection. Another similar case, also not handled particularly well at present, is where you pick up your default route from a dynamic routing protocol so there's no default route when ntpd starts. It seems to me that improving -s to cope better in this situation would be useful, and safer than -j in the event of an upstream NTP server going bad. This shocks people, but I often use a computer where there is no network connection. Waiting for that 15 second boot delay is annoying. Me too, I usually ^C there if I'm offline.
Re: ntpd jump ahead
I think I had a script on my previous laptop to see if ifconfig egress would result in something, and only wait for ntp to sync time in those cases. The existance of a default route may not be 100% fool-proof, but on dhcp-boxes it was good-enough for me. 2013/9/6 Stuart Henderson st...@openbsd.org On 2013/09/06 07:42, Nick Holland wrote: On 09/06/13 04:50, Stuart Henderson wrote: On 2013/09/05 20:03, Barry Grumbine wrote: Non-VM use case: The BeagleBone Black has no RTC, so -j could be useful for cheap little ARM development boards. -s is fine for that (and the same for those of the alix boards with no rtc battery, etc). ...unless the machine isn't attached to the network when initially powered up. Same goes for any machine with a dead RTC battery that may not have a good network connection at boot, and/or you don't want to slow the boot down by 15 seconds if there is no network connection. Another similar case, also not handled particularly well at present, is where you pick up your default route from a dynamic routing protocol so there's no default route when ntpd starts. It seems to me that improving -s to cope better in this situation would be useful, and safer than -j in the event of an upstream NTP server going bad. This shocks people, but I often use a computer where there is no network connection. Waiting for that 15 second boot delay is annoying. Me too, I usually ^C there if I'm offline. -- May the most significant bit of your life be positive.
Re: ntpd jump ahead
Non-VM use case: The BeagleBone Black has no RTC, so -j could be useful for cheap little ARM development boards. On Wed, Sep 4, 2013 at 5:58 AM, Reyk Floeter r...@openbsd.org wrote: On Wed, Sep 04, 2013 at 08:45:25AM -0400, Ted Unangst wrote: Bah. I tend to turn ntpd off and rely on the internal clock synchronization of the hypervisor. But fixing ntpd inside VMs would probably be a big win. Can you explain what you do? I have a vmt timedelta sensor that shows host time, but how do you sync the openbsd clock to that? let the host sync the system clock and hope that it doesn't run off ... but you're right, having a working ntpd would be much better. I don't like the fact that it would require another button. Couldn't ntpd just detect this automatically? Maybe by detecting that it is running inside a VM, or by whatever else? I think there is resistance to anything that treats VM differently. I tend to agree. This is a more generic problem of the clock failing to keep up, and can affect real hardware as well. Can you freeze and continue any other non-VM system? Is it comparable with suspend/resume? If not, than it is a special case that could be handled without being scared about a VM-specific option. For example: The timedelta sensor could tell userland that it might jump. ntpd would pick it up from vmt automatically. I think that adding another button is worse. It is already annoying to decide if I want to run ntpd with -s or not. Now it would add -j and -s. What combination is the best for my system? Who knows? Reyk
Re: ntpd jump ahead
Il giorno Domenica, 11 Agosto, 2013 22:47 CEST, Ted Unangst t...@tedunangst.com ha scritto: Nobody seemed to much care about my previous effort to get OpenBSD to play nicely inside a suspended VM. http://marc.info/?l=openbsd-miscm=134324835209706w=2 Instead of the kernel, this time I'm poking ntpd. To review, the problem is if the VM host is suspended, the VM guest (OpenBSD) doesn't get clock interrupts and therefore doesn't advance the clock. ntpd quite futilely attempts to cope with this: ntpd[15280]: adjusting local clock by 1396998.486806s ntpd[15280]: adjusting local clock by 1396997.386122s I'd like to add an option like -s that will jump the clock forward, not just once, but whenever it falls too far behind. I called it -j. If the clock is more than five seconds behind, we just set the time instead of trying to skew towards it. Note that we never jump backwards, that would be bad. I like the idea and I am ok with the code, before committing it it needs some man pages update. Cheers Giovanni
Re: ntpd jump ahead
Hi!
On Sun, Aug 11, 2013 at 04:47:08PM -0400, Ted Unangst wrote:
Nobody seemed to much care about my previous effort to get OpenBSD to
play nicely inside a suspended VM.
http://marc.info/?l=openbsd-miscm=134324835209706w=2
Well, I do care about VMs!
Instead of the kernel, this time I'm poking ntpd. To review, the
problem is if the VM host is suspended, the VM guest (OpenBSD) doesn't
get clock interrupts and therefore doesn't advance the clock. ntpd
quite futilely attempts to cope with this:
ntpd[15280]: adjusting local clock by 1396998.486806s
ntpd[15280]: adjusting local clock by 1396997.386122s
Bah. I tend to turn ntpd off and rely on the internal clock
synchronization of the hypervisor. But fixing ntpd inside VMs would
probably be a big win.
I'd like to add an option like -s that will jump the clock forward,
not just once, but whenever it falls too far behind. I called it -j.
If the clock is more than five seconds behind, we just set the time
instead of trying to skew towards it. Note that we never jump
backwards, that would be bad.
I don't like the fact that it would require another button. Couldn't
ntpd just detect this automatically? Maybe by detecting that it is
running inside a VM, or by whatever else?
Reyk
Index: ntp.c
===
RCS file: /cvs/src/usr.sbin/ntpd/ntp.c,v
retrieving revision 1.117
diff -u -p -r1.117 ntp.c
--- ntp.c 21 Sep 2011 15:41:30 - 1.117
+++ ntp.c 11 Aug 2013 16:16:32 -
@@ -580,6 +580,7 @@ priv_adjtime(void)
int offset_cnt = 0, i = 0, j;
struct ntp_offset **offsets;
doubleoffset_median;
+ enum imsg_typemsgtype;
TAILQ_FOREACH(p, conf-ntp_peers, entry) {
if (p-trustlevel TRUSTLEVEL_BADPEER)
@@ -632,7 +633,11 @@ priv_adjtime(void)
}
conf-status.leap = offsets[i]-status.leap;
- imsg_compose(ibuf_main, IMSG_ADJTIME, 0, 0, -1,
+ if (conf-jumptime offset_median 5.0)
+ msgtype = IMSG_JUMPTIME;
+ else
+ msgtype = IMSG_ADJTIME;
+ imsg_compose(ibuf_main, msgtype, 0, 0, -1,
offset_median, sizeof(offset_median));
priv_adjfreq(offset_median);
Index: ntpd.c
===
RCS file: /cvs/src/usr.sbin/ntpd/ntpd.c,v
retrieving revision 1.69
diff -u -p -r1.69 ntpd.c
--- ntpd.c19 Mar 2011 23:40:11 - 1.69
+++ ntpd.c11 Aug 2013 16:12:09 -
@@ -73,7 +73,7 @@ usage(void)
{
extern char *__progname;
- fprintf(stderr, usage: %s [-dnSsv] [-f file]\n, __progname);
+ fprintf(stderr, usage: %s [-djnSsv] [-f file]\n, __progname);
exit(1);
}
@@ -97,7 +97,7 @@ main(int argc, char *argv[])
log_init(1);/* log to stderr until daemonized */
- while ((ch = getopt(argc, argv, df:nsSv)) != -1) {
+ while ((ch = getopt(argc, argv, df:jnsSv)) != -1) {
switch (ch) {
case 'd':
lconf.debug = 1;
@@ -105,6 +105,9 @@ main(int argc, char *argv[])
case 'f':
conffile = optarg;
break;
+ case 'j':
+ lconf.jumptime = 1;
+ break;
case 'n':
lconf.noaction = 1;
break;
@@ -295,6 +298,14 @@ dispatch_imsg(struct ntpd_conf *lconf)
fatalx(invalid IMSG_ADJFREQ received);
memcpy(d, imsg.data, sizeof(d));
ntpd_adjfreq(d, 1);
+ break;
+ case IMSG_JUMPTIME:
+ if (imsg.hdr.len != IMSG_HEADER_SIZE + sizeof(d))
+ fatalx(invalid IMSG_JUMPTIME received);
+ if (!lconf-jumptime)
+ break;
+ memcpy(d, imsg.data, sizeof(d));
+ ntpd_settime(d);
break;
case IMSG_SETTIME:
if (imsg.hdr.len != IMSG_HEADER_SIZE + sizeof(d))
Index: ntpd.h
===
RCS file: /cvs/src/usr.sbin/ntpd/ntpd.h,v
retrieving revision 1.107
diff -u -p -r1.107 ntpd.h
--- ntpd.h30 Apr 2013 11:42:56 - 1.107
+++ ntpd.h11 Aug 2013 16:11:40 -
@@ -178,6 +178,7 @@ struct ntpd_conf {
struct ntp_freq freq;
u_int32_t scale;
u_int8_tlisten_all;
+ u_int8_tjumptime;
u_int8_tsettime;
u_int8_tdebug;
u_int8_t
Re: ntpd jump ahead
On Wed, Sep 04, 2013 at 02:28:00PM +0200, Reyk Floeter wrote: Bah. I tend to turn ntpd off and rely on the internal clock synchronization of the hypervisor. But fixing ntpd inside VMs would probably be a big win. the guest drivers in OpenBSD don't provide a time sensor based on the host clock. That's something that could be done. I looked quickly at doing it for KVM hosts, it seemed not too hard to me. Just haven't got enough motivation to actual code it. -- Matthieu Herrb
Re: ntpd jump ahead
On Wed, Sep 04, 2013 at 14:28, Reyk Floeter wrote: Bah. I tend to turn ntpd off and rely on the internal clock synchronization of the hypervisor. But fixing ntpd inside VMs would probably be a big win. Can you explain what you do? I have a vmt timedelta sensor that shows host time, but how do you sync the openbsd clock to that? I don't like the fact that it would require another button. Couldn't ntpd just detect this automatically? Maybe by detecting that it is running inside a VM, or by whatever else? I think there is resistance to anything that treats VM differently. I tend to agree. This is a more generic problem of the clock failing to keep up, and can affect real hardware as well.
Re: ntpd jump ahead
On Wed, Sep 04, 2013 at 02:39:16PM +0200, Matthieu Herrb wrote: On Wed, Sep 04, 2013 at 02:28:00PM +0200, Reyk Floeter wrote: Bah. I tend to turn ntpd off and rely on the internal clock synchronization of the hypervisor. But fixing ntpd inside VMs would probably be a big win. the guest drivers in OpenBSD don't provide a time sensor based on the host clock. That's something that could be done. I looked quickly at doing it for KVM hosts, it seemed not too hard to me. Just haven't got enough motivation to actual code it. We do have a timedelta sensor for VMware with vmt(4) hw.sensors.vmt0.timedelta0=-4.876658 secs, OK, Wed Sep 4 14:39:51.067 Reyk
Re: ntpd jump ahead
On Wed, Sep 04, 2013 at 08:45:25AM -0400, Ted Unangst wrote: Bah. I tend to turn ntpd off and rely on the internal clock synchronization of the hypervisor. But fixing ntpd inside VMs would probably be a big win. Can you explain what you do? I have a vmt timedelta sensor that shows host time, but how do you sync the openbsd clock to that? let the host sync the system clock and hope that it doesn't run off ... but you're right, having a working ntpd would be much better. I don't like the fact that it would require another button. Couldn't ntpd just detect this automatically? Maybe by detecting that it is running inside a VM, or by whatever else? I think there is resistance to anything that treats VM differently. I tend to agree. This is a more generic problem of the clock failing to keep up, and can affect real hardware as well. Can you freeze and continue any other non-VM system? Is it comparable with suspend/resume? If not, than it is a special case that could be handled without being scared about a VM-specific option. For example: The timedelta sensor could tell userland that it might jump. ntpd would pick it up from vmt automatically. I think that adding another button is worse. It is already annoying to decide if I want to run ntpd with -s or not. Now it would add -j and -s. What combination is the best for my system? Who knows? Reyk
