This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 8949 - Real Time Clock frequency set as constant rather than discovered.
Real Time Clock frequency set as constant rather than discovered.
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Michael K. Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-01-28 16:02 EST by ldrake
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-07 23:01:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description ldrake 2000-01-28 16:02:48 EST
I have found a bug in the kernel code. It's effects are system-wide and
pertain to all time-dependent operations.

in the file: /usr/src/linux/include/asm/param.h there is a constant
defined (HZ) as equalling 100.

This has caused all manner of problems on my system (Precision Workstation
410 (Dell) - dual 750 Coppermines on a 440BX-AGP based Dell motherboard
RHL pre-load) ranging in severity from rampant keyboard auto-repeats to
broken and repeated event sounds in gnome, to garbled ppp connections to
bad tape device operations.

The Constant (HZ) is one that describes the frequency of the Real Time
Clock in jiffies/sec. I have found the number 200 to work somewhat better,
but I still have some problems (It cleared up the keyboard and sound
problem, but device systems are still having difficulties)

While I am not familiar enough with the constructs of the kernel and
surrounding dependant modules to say this with any authority, wouldn't it
be better to employ a simple measurement algorithm to discover what this
number should be rather than setting it as a constant?
Comment 1 ldrake 2000-02-07 23:01:59 EST
I have noticed that I am experiencing far better ethernet operation with HZ set
to 200. Previously, there were a tremendous number of collisions. I am quite
certain that this is still not the correct number to use. Other sub-systems
complain if I set it any higher (NIS NFS etc.. all gripe and decide to use 100
(seems that they want to use a multiple of the HZ constant for some reason)

NIC = 3c905b on-board (Dell)
Video = Diamond Viper 770 32mb
Sound = Crystal Audio on-board (Dell)

I have tested this with both the original RH6.0 kernel (2.2.5-15), and a
freshly compiled 2.2.14 kernel - results are the same

Sound is still a tad choppy, however tolerable.

Note You need to log in before you can comment on or make changes to this bug.