[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
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
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 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: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
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-misc&m=134324835209706&w=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_t
Re: ntpd jump ahead
Il giorno Domenica, 11 Agosto, 2013 22:47 CEST, Ted Unangst 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-misc&m=134324835209706&w=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
