Re: Timing issue with Dummynet on high kernel timer interrupt

On Fri, 2015-11-06 at 17:51 +0100, Hans Petter Selasky wrote:
> On 11/06/15 17:43, Ian Lepore wrote:
> > On Fri, 2015-11-06 at 17:28 +0100, Hans Petter Selasky wrote:
> > > Hi,
> 
> > 
> > Do the test II results change with this setting?
> > 
> >    sysctl kern.timecounter.alloweddeviation=0
> > 
> 
> Yes, it looks much better:
> 
> debug.total: 10013 -> 0
> debug.total: 10013 -> 0
> debug.total: 10012 -> 0
> debug.total: 10012 -> 0
> debug.total: 10012 -> 0
> debug.total: 10013 -> 0
> debug.total: 10012 -> 1
> debug.total: 10013 -> 0
> debug.total: 10013 -> 0
> debug.total: 10013 -> 0
> debug.total: 10012 -> 0
> debug.total: 10013 -> 0
> debug.total: 10013 -> 0
> 
> --HPS

This isn't the first time that the alloweddeviation feature has led
people (including me in the past) to think there is a timing bug.  I
think the main purpose of the feature is to help save battery power on
laptops by clustering nearby scheduled wakeups to all happen at the
same time and then allow for longer sleeps between each wakeup.

I've been wondering lately whether this might also be behind the
unexplained "load average is always 0.60" problem people have noticed
on some systems.  If load average is calculated by sampling what work
is happening when a timer interrupt fires, and the system is working
hard to ensure that a timer interrupt only happens when there is actual
work to do, you'd end up with statistics reporting that there is work
being done most of the time when it took a sample.

Maybe it would make sense to only enable the feature by default on
battery-powered systems?

-- Ian