From owner-freebsd-current@FreeBSD.ORG Thu Apr 24 19:36:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4D7E1065675 for ; Thu, 24 Apr 2008 19:36:24 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outB.internet-mail-service.net (outb.internet-mail-service.net [216.240.47.225]) by mx1.freebsd.org (Postfix) with ESMTP id BDBA68FC16 for ; Thu, 24 Apr 2008 19:36:24 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 24 Apr 2008 14:19:32 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id A9DFF2D6010; Thu, 24 Apr 2008 12:36:23 -0700 (PDT) Message-ID: <4810E137.4020006@elischer.org> Date: Thu, 24 Apr 2008 12:36:23 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: obrien@freebsd.org, Julian Elischer , Poul-Henning Kamp , Andrew Gallatin , gnn@freebsd.org, freebsd-current@freebsd.org References: <51610.1208498408@critter.freebsd.dk> <4808E06D.8020304@elischer.org> <20080424164734.GA10152@dragon.NUXI.org> In-Reply-To: <20080424164734.GA10152@dragon.NUXI.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: TSC Timecounter and multi-core/SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2008 19:36:24 -0000 David O'Brien wrote: > On Fri, Apr 18, 2008 at 10:54:53AM -0700, Julian Elischer wrote: >> Poul-Henning Kamp wrote: >>> In message <48080276.3040203@elischer.org>, Julian Elischer writes: >>>> You'd think that an invariant sync'd clock (fast to read) of some >>>> type would have been done by someone by now.. The software people >>>> have been asking for this for the last decade at least. >>> Actually one of the original design documents for SAGE stressed that >>> such hardware were crucially important "for any system operating >>> in real time", so yes, the HW people have had adequate notices. >>> Poul-Henning >> I'm certain that earlier systems had it as a requirement but I wasn't >> willing to lump the IBM 407 or 1620 in to the same bucket as an SMP >> PC with the ability to change the frequency on each CPU. I remember >> that the MP vaxen and PDPs had good timers.. and I'm certain the MP >> IBMs did too. > > You're also speaking of a world where the HW vendor controlled the OS and > could change the OS at any time to match changes in the HW. That has not > been true of the x86 world for nearly three decades. > > >> How hard can it be? > > Quite hard - especially if you want it fast (on the order of say 10 > cycles like TSC is). > no it can't be that hard.. other processors manage it. And it's a critical feature.. kind of like atomic bus operations.. you can get around it, but it's really hard. SO it deserves real effort. > >> An instruction that gives a 64 bit counter, in some reasonable >> granularity that is run at the same speed for all CPUS in a system >> regardless of the speed each cpu is running.. > > AMD Greyhound (Family 10h) gives this (well, at 60'ish cycles). What you > didn't ask for here (but I think you did in another email) is for all the > values to be the same. That means off-chip signaling. The HPET was > one attempt at addressing this, but it centralized the counter and thus > the reads of it are serialized and >100 cycles. > no I don't need the values to be the same if the offset remains constant. that would just be a 'nice' feature. > It is my understanding, some Sparc systems have the time source you are > looking for. my point exactly.. it is doable. > > What you're really asking for is for wall-time to be split out of > processor cycle counter (which is what TSC really is). That OS's > have been abusing TSC for a wall-time source is the fault. they have no alternative because the HW manufacturers will not give us a suitable source. > > x86 processor companies would like to make this change (TSC and clock > time source), but is the ways heard "there way too much software written > that uses X to change". > who the heck told them that? A new facility would start to get used in new software. (!?) > >> While nsecs would be nice even usecs might do. > > Nope, not really. Every OS I know of that has tried to use the HPET or > ACPI PMtimer instead of TSC cannot stand the latency and thus fights for > ways to go back to the TSC. [FreeBSD is mostly an exception, but the > fact we're having this discussion... say we're not totally satisfied > with ACPI PMtimer or HPET.] > no they are too slow.. we want somethign that just reads an on chip register in one cycle. > >> They don't even have to be in sync as long as the offset >> between them is constant (though that would be nice). > > This is what AMD's Greyhound (family 10h) *finally* gives [AMD users]. > I think Intel Core2 does too - but at a price of lower granularity. that's fine.. I haven't seen the specs but that's great news. > > >> hardware people don't seem to realise the importance >> of this. and keep throwing it out to gain/save a pin or to save >> some transistors for some other feature. > > NO. The HW people *DO* understand this. It has nothing to do with > saving a pin or some transistors. Multi-core and 6GB cache is here > today because we have an abundance of transistors. AMD Opteron's now > have 1207 pins. > then why didn't we have this a decade ago? > A large set of folks responsible for lack of change are SW folks who > would need to change on a dime (and go back and change older SW too) > that gets in the way. Would we be willing to go change time sources > for FreeBSD 6.4? Would Microsoft for w2k3? Or Red Hat for RHEL4? > (HW vendors want to sell product, which means to customers using > *released* software; not requiring a 5 year out OS to take advantage > of it.) If you have a new feature, there is nothing that says old sw has to use it.. >