of the last sensor update time got broken, doesn't show up with gps since
it updates often (more often than we read), but naddy ran into it with dcf.
record time of last sensor datum seperately. ok naddy balmer
and deleted. previously this script only generated diffs for existing
files.
ok lots of people including millert@ msf@ mcbride@ todd@ and probably more.
time, and make ntpd use that to send the next uery to an ntp peer and the
like. this has the advantage that changes to the clock do not interfere
with the intervals. for example, when we start on machines without an
RTC and the initial settime (-s) kicks in, intervals were strange.
idea from amandal@entrisphere.com, this implementation by me
tested ckuethe, phessler, mbalmer, ok mbalmer
them only every 30 seconds. now query them every 5,and take the median
value from 7 queries as sensor value. this takes outliers out of the
equation and makes the overall result much better, especially for
sensors with heavy jitter (like nmea for now)
create special allocators for pginfo and pgfree structs instead of imalloc.
this keeps them separated from application memory.
for chunks, to prevent deterministic reuse, keep a small array
and swizzle the to be freed chunk with a random previously freed chunk.
this last bit only for chunks because keeping arbitrarily large regions
of pages around may cause out of memory issues (and pages are, to some
extent, returned in random order).
all changes enabled by default.
thanks to ben for pointing out these issues.
ok tech@
-1 because of error, it may still participate in poll()
causing poll() to repeatedly wake up on error fd.
so make sure w edon't add -1 fds to pollevents to avoid unnecessary wakeups
From: amandal@entrisphere.com
takes the offset it adjtime() is already correcting for into account
when taking the offset from a sensor, we need to correct it by the
offset between system time and ntpd view.
otto