Re: PHP performance on Xen domU with mulitple vcpu

Mouse <[email protected]> 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.