Date: Fri, 28 Oct 2005 22:34:52 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: current@freebsd.org Subject: Re: Timers and timing, was: MySQL Performance 6.0rc1 Message-ID: <35273.1130531692@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 29 Oct 2005 06:15:05 %2B1000." <20051028201505.GV39882@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20051028201505.GV39882@cirb503493.alcatel.com.au>, Peter Jeremy wri tes: >I was thinking that if the cost differential is large enough, it might >be worthwhile using different hardware counters (especially for duration >values where you don't have to worry about getting a valid UTC time). Yes, that is an obvious way to tune things. The problem however is the same: Getting convinced that the TSC is constant frequency is non-trivial. >This would probably mean adding a system call to set a default timer >type which is part of the struct proc - upon reflection, there would be >a significant amount of kernel API churn (at least) to get this to work. And worse: Unless we can sell the concept to the other contemporary UNIXen, another FreeBSD specific API which sees little use. >To go off on a different tangent, would it be possible to use the NTP >algorithms to synchronize the TSC? It all comes down to how much CPU time you're willing to burn to make timekeeping faster... >This gives something like: > now = magic->offset + (rdtsc() * magic->multiplier) >> magic->shift; You should really read http://phk.freebsd.dk/pubs/timecounter.pdf first :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35273.1130531692>