Timing issue with Dummynet on high kernel timer interrupt

[Rasool Al-Saadi]

On Saturday, 7 November 2015 10:51 PM, Bruce Evans wrote:
> On Sat, 7 Nov 2015, Hans Petter Selasky wrote:
> 
> > On 11/07/15 07:19, Bruce Evans wrote:
> >> I don't know if CTLFLAG_RWTUN with SYSCTL_PROC() actually works for
> >> all types, but it is used with CTLFLAG_STRING for kern.corefile.
> >> This is another bogus undocumented tunable.  It is better documented
> >> as a sysctl than most since it is old so it is documented in
> >> sysctl(8).  It is not documented as a tunable there of course.  It is
> >> also not documented as a tunable in core(5).
> >
> > SYSCTL_PROC() works with RWTUN from /boot/loader.conf, as long as the
> > procedure callback handles early calls during boot.
> 
> Hmm, that would be messy if it wants to do hardware stuff like
> sysctl_kern_eventtimer_periodic() does.
> 
> Timercounters only have 1 MI tunable
> (sysctl_kern_timecounter_adjprecision).  It has a (cold) check to avoid doing
> too much.
> 
> Bruce

Thanks a lot all for your help!

The results now reasonable when kern.eventtimer.periodic=1. sysctl kern.timecounter.alloweddeviation=0 does not make deference (at least in my test) .
Here is RTT vs Time graph when Hz=10000, kern.eventtimer.periodic=1 and kern.timecounter.alloweddeviation={default (5), 0} https://goo.gl/photos/ukxTvpBDeoFCFEPH8
The time deference graph https://goo.gl/photos/AAV8oECBpdvowgsY7
 
So, what the effects of using periodic mode on the system in general? Why the timing issue disappears when eventtimer.periodic=0 and C_DIRECT_EXEC  is removed from callout_reset_sbt() call?

Cheers,
Rasool