Date: Thu, 9 Jul 2009 23:02:12 +0100 From: Andrew Brampton <brampton+freebsd@gmail.com> To: freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) Message-ID: <d41814900907091502gbcd7e47h6982dbcf2e837963@mail.gmail.com> In-Reply-To: <4A562960.3010801@freebsd.org> References: <4A562960.3010801@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/7/9 Andriy Gapon <avg@freebsd.org>: > > > There are at least the following two alternatives: > > 1. Keep things as they are and warn users not to change CPU clock frequency when > they use DTrace and the CPU doesn't have invariant TSC. I think that this should > cause only minor inconveniences to a portion of DTrace users. > > 2. Use raw TSC value as a DTrace timestamp and document this difference from the > original DTrace. Advantage: timestamp value is always monotonic. Disadvantage: > manual conversion is needed to get "real" time (using the same formula). > Please note that in this case timestamps would be in non-linear time dimension if > TSC frequency changes, so to get meaningful timestamps (when needed/important) one > would still have to make sure that TSC frequency stay constant. > According to wikipedia newer Intel processors have a constant rate TSC whos freq does not change. If this features is available on most processors today, then I am happy to stick with option 1. Another problem with this is that on a multicore machine each core may have different TSC values. Has anyone thought how to address this issue? Could we calculate the offset of each core from core0, and then ensure the offset is applied to the tsc value when it is needed? thanks Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d41814900907091502gbcd7e47h6982dbcf2e837963>