On Thu, 1 Feb 2018 a bug that doesn't want repl...@freebsd.org wrote:
--- Comment #21 from Aleksander Derevianko <ae...@list.ru> ---
OK, problem solved. 12-hours test doesn't show any delays longer then 1 ms.
For the future reference, only following parameters must be set in
# Exact clock for nanosleep()
# Disable random delays in network/adapter code
All other parameters (boot.loader) can be left as system defaults.
Closing defect with "Works As Intended" because it's possible to solve just in
It doesn't work as intended.
kern.timecounter.alloweddeviation=0 might be the correct setting for the
default, since nonzero gives many other suprising behaviours (like
"time sleep 1" usually appearing to sleep for precisely 1 second in old
versions of FreeBSD despite a large timer granularity (10 msec, the same
as time(1)), while under -current it often sleeps by up to about 66 msec
extra despite (actually because of) a timer granularity of 1 msec (actually
much smaller, provided the caller asks for it). High resolution timers
can be inefficient and are usually not needed, so FreeBSD allows inaccuracy
of about 5% by default, up to an interval of about 1 second (time sleep 10
has the same absolute inaccuracy of up to about 66 msec, but that is only
0.66% relative inaccuracy).
Changing kern.timecounter.alloweddeviation to 0 breaks the optimization for
all uses to fix only 1 known problem here.
The main bug here are probably that some TCP or application timer doesn't
ask for the high resolution that it needs (I don't know how to specify the
resolution for applications, and there are security problems with allowing
it to be small). The timeouts are apparently long, so 5% relative is a lot
absolute. I think 5% relative should only apply to short timeouts, say
10 msec instead of 1 second.
kern.eventtimer.periodic=1 is never the correct setting except with buggy
hardware. It turns off most of the new timer code, and breaks setting of
resolutions below 1/HZ. I actually prefer simpler timeout code with only
periodic timers supported, and rarely need high resolutions, but I also
prefer large HZ and the new timer code works better with that provided
kern.eventtimer.periodic is not 1. Periodic timers can be more efficient
but this doesn't show up in my benchmarks.
Since kern.eventtimer.periodic=1 seems to help, there might be further bugs,
but I suspect this is an artifact of the measurements. With periodic timers,
everything tends to wake up at the same time and see only constant differences
in times (of an integer times the timeout period). Worse, activity between
timeout interrupts tends to be invisible.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"