Mouse <mo...@rodents-montreal.org> writes:
> Not a bug in the sense that gettimeofday is violating its interface
> contract, just a bug in the sense that "something is wrong". I'd say
> gettimeofday() taking as long as a second, measured by ktrace records,
> indicates a bug; everything involved is entirely in-kernel, so that
> can't really be blamed on userland.
Agreed; sorry for misreading.
> Yes. VAX timekeeping is rather bad by modern standards; many VAXen
> (the KA630, used by the MicroVAX-II, in particular - I don't know the
> MicroVAX-III in this regard) are not capable of better than 10ms.
> There's no cycle counter and the ICCS can't do anything but an
> interrupt every 10ms - NICR and ICR are subsetted away.
I have no memory of the III (KA650?) being much different.
> And, yes, here's that "increment the usec" behaviour:
>
> if (tvp->tv_sec == lasttime.tv_sec &&
> tvp->tv_usec <= lasttime.tv_usec &&
> (tvp->tv_usec = lasttime.tv_usec + 1) >= 1000000) {
> tvp->tv_sec++;
> tvp->tv_usec -= 1000000;
> }
> bcopy(tvp, &lasttime, sizeof(struct timeval));
>
> Obviously, this depends on the system not sustaining as many as a
> million fetches of the time (gettimeofday() being only one of variousp
> things which can call microtime()) per second for any significant
> period.
heh, indeed. I was thinking such behavior would be dangerous now, but
nobody would have thought so back in the those days.
