Michael van Elst wrote: > mo...@rodents-montreal.org (Mouse) writes: > > > } else if (sec <= (LONG_MAX / 1000000)) > > ticks = (((sec * 1000000) + (unsigned long)usec + (tick - 1)) > > / tick) + 1; > > >which looks suspicious. If sec is zero and usec is tick, that > >expression will return 2 instead of the 1 I suspect it needs to return. > > The delay is always rounded up to the resolution of the clock, > so waiting for 1 microsecond waits at least 10ms. > > The interval to the next tick can be arbitrarily short. Waiting > for at least 10ms therefore means to wait for the second next > tick.
Look at the wording sleep(3), nanosleep(2), etc. They all use wording like "... the number of time units have elapsed ..." and none of them make any guarantee that they'll return within any specific time frame after the time period has elapsed. In the same thread on port-vax Mouse references, Matt previously said: > unfortunately, we have a known issue hosting VMs on machines > with the same or near HZ values. i've built my VM hosting > systems with HZ=256 for the last year or so and it helps a lot. What Mouse is describing the Michael expanded on is is exactly the issue that Matt is referring to. Two options are to increase HZ on the host as suggested, or halve HZ on the guest. > In a tickless system, such a problem doesn't exist. Well, this is a third option. A bit harder though :) Cheers, Simon.
