Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Dec 2005 03:51:47 -0800
From:      "Ed" <ed@edslocomb.com>
To:        "Peter Jeremy" <PeterJeremy@optushome.com.au>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: cpu-timer rate
Message-ID:  <002b01c5fb24$9a802150$1132e7d8@robotslave>
References:  <20051205124910.GC90806@over-yonder.net><20051205181552.2D7AB5D04@ptavv.es.net> <20051207071710.GQ32006@cirb503493.alcatel.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
I certainly do not have a full understanding of the interactions between the 
various FreeBSD software timers and i386 hardware clocks, but I do know this 
is not the first time we've seen a problem with the APIC/ACPI timers/clocks.

See here:
http://www.freebsd.org/cgi/getmsg.cgi?fetch=643512+646009+/usr/local/www/db/text/2005/freebsd-stable/20051120.freebsd-stable

And workaround, here:
http://www.freebsd.org/cgi/getmsg.cgi?fetch=687445+690193+/usr/local/www/db/text/2005/freebsd-stable/20051120.freebsd-stable

I haven't made much of a fuss, since my vmware FreeBSD works just fine so 
long as I disable the APIC (not ACPI) device.  I was guessing there was some 
assumption about relative rates gumming things up for vmware (the hardware 
APIC (not ACPI) timer runs at memory bus speed, not cpu speed, and thus will 
get goofed if you assume straight/DDR/quad/whatever memory-- from what I 
gather, you need to check it against a known-hz device, e.g. the PIT/i8253 
clock).

My complacency, however, is probably misguided, as the release notes for 6.0 
clearly sate that "FreeBSD always uses the local APIC timer even on 
uni-processor systems now," and will presumably continue to do so for the 
forseeable future.

There is a nice layman's overview of  various i386 hardware clock devices 
here:
http://www.vmware.com/pdf/vmware_timekeeping.pdf

Again, I'm no expert, but clock problems do keep cropping up here on 
the -STABLE list, and the explanations for them to date have not been 
consistent.  This leads me to believe that the FreeBSD kernel clock/timer 
code is not well-understood by any one developer who monitors this list; I'm 
sure I'm not the only end-user who would appreciate it if the core team 
would look into this and post some information that would explain the 
various clock/timer problems that odd corners of the user community have 
been reporting.


----- Original Message ----- 
From: "Peter Jeremy" <PeterJeremy@optushome.com.au>
To: "Kevin Oberman" <oberman@es.net>
Cc: "kama" <kama@pvp.se>; <freebsd-stable@freebsd.org>; "Matthew D. Fuller" 
<fullermd@over-yonder.net>
Sent: Tuesday, December 06, 2005 11:17 PM
Subject: Re: cpu-timer rate


> On Mon, 2005-Dec-05 10:15:52 -0800, Kevin Oberman wrote:
>>> On Mon, Dec 05, 2005 at 09:42:08AM +0100 I heard the voice of
>>> kama, and lo! it spake thus:
>>> >
>>> > I appreciate that you took time to answer about the different
>>> > clocks. But that does not answer why vmstat -i shows a rate of 2000
>>> > when I have set the hz to 1000.
>>>
>>> Because the rate is always twice hz.
>>
>>While I will concede that I have no explanation, but on all of my systems
>>rate = HZ +/-1. I have never seen a case where rate/2 = HZ.
>
> Basically, it depends on what clock(s) your kernel is using.
>
> Traditionally, FreeBSD/i386 uses the one of the i8254 counters to
> generate hz (on irq0) and the RTC to generate profhz/stathz (on irq8).
> In this case, the rate on those interrupts should match the values
> reported by kern.clockrate.  On SMP machines, this approach is fairly
> expensive because the interrupts need to be forwarded to all CPUs
> using IPIs.
>
> In early February, jhb implemented an alternative approach using the
> local APIC clock (sys/i386/i386/local_apic.c v1.13 and other files).
> Since every CPU has a LAPIC, every CPU gets its own clock interrupts
> without needing IPIs.  The downside is that there's only a single
> LAPIC so a single hardware clock interrupt needs to generate separate
> (and independent) hz/tick and stathz/profhz clocks.
>
> Since the clocks need to be independent (to make process statistics
> meaningful), this implies that the hardware (LAPIC) clock (cpu0) needs
> to be faster than hz.  The original commit ran LAPIC at hz*3 but this
> was later changed to hz*2 to reduce overheads.
>
> -- 
> Peter Jeremy
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002b01c5fb24$9a802150$1132e7d8>