when we adjust time. This prevents ntpd from going wild when using
sensor time sources; ok henning@ (on an earlier version) and a LOT
of testing by naddy@
stats' and 'rndc recursing' commands in /var/named/tmp (instead of
/var/named), which is writable by the 'named' user.
feedback and ok jakob@ deraadt@, also agreed by fkr@ and msf@
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@