Date: Fri, 14 Oct 2005 19:41:48 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Garrett Wollman <wollman@csail.mit.edu>, Andrew Gallatin <gallatin@cs.duke.edu>, net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) Message-ID: <20051014192509.F80520@delplex.bde.org> In-Reply-To: <12349.1129279613@critter.freebsd.dk> References: <12349.1129279613@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Oct 2005, Poul-Henning Kamp wrote: > In message <17230.62415.991707.840932@grasshopper.cs.duke.edu>, Andrew Gallatin > writes: > >> Linux already takes care of syncing the TSC between SMP cpus, so we >> know it is possible. This seems like a much more doable optimization. >> And it is likely to have other benefits.. The timestamps in mi_switch() are taken on the same CPU and only their differences are used, so they don't even need to be synced. It they use the TSC, then the TSCs just need to have the same almost-constant frequency (or different almost-constant frequencies if timecounters werre per-CPU). > Validating that the TSC is reliable is a nontrivial task which requires > access to a lot of NDA information and an extensive positive/negative > list of chips and chipsets. It only requires comparsion with another time source over a sufficently long enough time and large enough set of operating environments. This is hard to automate. I compare with a local ntp server with a known good TSC. > Even in the most recent chips, there are still issues with TSC that > makes it unusable as a default timecounter. I think newer chipsets are more liketly to have unusable TSCs. Anything with power control is unleky to have an almost-constant frequency. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051014192509.F80520>