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
[NEW] ugold(4) driver for Microdia's USB TEMPer variant (take 3)
Hi all, Here is the driver for Microdia's USB TEMPer, take 3. http://www.uaa.org.uk/gomitext/2013/20130905/20130905.diff Thanks to mpi@ and testers of tech@. man is not yet, sorry. Regards, SASANO Takayoshi u...@mx5.nisiq.net
