On Sat, 29 Nov 2003, Kris Kennaway wrote:
> I forwarded the reports of timecounter problems to phk, and he asked
> that people who are seeing timecounter problems provide FULL details
> of their system configuration, including:
Please note that there are quite a few broken timecounters out ther
In message <[EMAIL PROTECTED]>, "Marc G. Fournier" writes:
>On Sat, 29 Nov 2003, Don Bowman wrote:
>
>> For this config (below), kern.timecounter.method=0 reproduces the
>> problem, kern.timecounter.method=1 does not.
>
>Can anyone comment on what effect setting method to 1 has on the system?
>Like
In message <[EMAIL PROTECTED]>, "Marc G. Fournier" writes:
Hmm, I'm not saying this makes sense, but at least there is
an emergent pattern...
Col#1 is duration of the shift, sorted in increasing order.
Col#2 is the delta to the line above.
Notice stratification on 50msec boundaries:
695.
On Sat, 29 Nov 2003, Don Bowman wrote:
> For this config (below), kern.timecounter.method=0 reproduces the
> problem, kern.timecounter.method=1 does not.
Can anyone comment on what effect setting method to 1 has on the system?
Like, would one notice a degradation in performance?
Marc G. Fou
From: Kris Kennaway [mailto:[EMAIL PROTECTED]
>
> I forwarded the reports of timecounter problems to phk, and he asked
> that people who are seeing timecounter problems provide FULL details
> of their system configuration, including:
>
> * dmesg
>
> * kernel configuration
>
> * compiler options
On Sat, 29 Nov 2003, Kris Kennaway wrote:
> * dmesg
Attached ...
> * kernel configuration
Attached ...
> * compiler options
CFLAGS= -O -mpentium -pipe -g -DKVA_PAGES=512
COPTFLAGS= -O -mpentium -pipe -DKVA_PAGES=512
> * time-related system configuration (whether ntpd/timed/ntpdate is
> runni
