In message <20051028201505.GV39882_at_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_at_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.Received on Fri Oct 28 2005 - 18:34:55 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:46 UTC