[asterisk-bugs] [Zaptel 0010314]: [patch] Merged in support for high resolution timers in kernel >=2.6.16
noreply at bugs.digium.com
noreply at bugs.digium.com
Sat Jul 28 19:27:36 CDT 2007
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=10314
======================================================================
Reported By: darren1713
Assigned To:
======================================================================
Project: Zaptel
Issue ID: 10314
Category: ztdummy
Reproducibility: always
Severity: feature
Priority: normal
Status: new
Zaptel Version: SVN
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!): 2770
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 07-26-2007 18:36 CDT
Last Modified: 07-28-2007 19:27 CDT
======================================================================
Summary: [patch] Merged in support for high resolution timers
in kernel >=2.6.16
Description:
The new high resolution timer in the kernel generates very accurate
periodic timing. Just using the kernel based timing gets these sorts of
results from ztdummy (99.999992% avg):
......
8192 samples in 8192.000000 sample intervals 100.000000%
8192 samples in 8192.008000 sample intervals 99.999908%
--- Results after 123 passes ---
Best: 100.000000 -- Worst: 99.999512 -- Average: 99.999992
The high resolution timer in ztdummy is only built if it's supported and
enabled in the kernel, and will continue to use the RTC timing if the high
resolution timers are not available.
Specifically, CONFIG_HIGH_RES_TIMERS needs to be enabled (Processor type
and features -> High Resolution Timer Support), and optionally, (Processor
type and features -> HPET Timer Support) provides a better clock source.
There should be no side effects to this, since it's the new kernel
timers.
Adding an option into the "make menuselect" to force RTC instead if they
are both available would be a good addition. Configs/Makefiles are not my
fortay, so this would be better for someone else to do.
======================================================================
----------------------------------------------------------------------
darren1713 - 07-28-07 19:27
----------------------------------------------------------------------
Now I understand what piece of the code you were talking about rate limits
on. There is not currently a rate limit there because something is
massively wrong if it ever misses a tick. It would mean that something in
the kernel is hanging and really messing everything up. Even a rogue user
process running at 100% cpu, nice'd to it's highest priority, would not
cause this timer to be delayed or miss a tick.
I do agree it would be good to have a rate limit on it, in the event that
something is hanging processes in the kernel, but it definitely has to warn
the user the first time it happens. Considering it's very rare it would
ever happen, it should be limited to maybe printing 1 message per second,
and not 1 message after 5000 misses.
Also, this is not a debug message, it means something is really really
wrong, and should always be printed.
Do you have a simple solution/prior code for rate limiting by time?
Issue History
Date Modified Username Field Change
======================================================================
07-28-07 19:27 darren1713 Note Added: 0068016
======================================================================
More information about the asterisk-bugs
mailing list