Date: Thu, 24 Apr 2008 09:47:34 -0700 From: "David O'Brien" <obrien@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: gnn@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-current@freebsd.org, Andrew Gallatin <gallatin@cs.duke.edu> Subject: Re: TSC Timecounter and multi-core/SMP Message-ID: <20080424164734.GA10152@dragon.NUXI.org> In-Reply-To: <4808E06D.8020304@elischer.org> References: <51610.1208498408@critter.freebsd.dk> <4808E06D.8020304@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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). > 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. It is my understanding, some Sparc systems have the time source you are looking for. 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. 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". > 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.] > 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. > 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. 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.) -- -- David (obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080424164734.GA10152>