On Sun, Nov 27, 2011 at 11:54:38PM -0800, Greg Smith wrote: > On 11/27/2011 04:39 PM, Ants Aasma wrote: > >On the AMD I saw about 3% performance drop with timing enabled. On the > >Intel machine I couldn't measure any statistically significant change. > > Oh no, it's party pooper time again. Sorry I have to be the one to > do it this round. The real problem with this whole area is that we > know there are systems floating around where the amount of time > taken to grab timestamps like this is just terrible. I've been > annoyed enough by that problem to spend some time digging into why > that is--seems to be a bunch of trivia around the multiple ways to > collect time info on x86 systems--and after this CommitFest is over
Something good to know: in Linux the file /sys/devices/system/clocksource/clocksource0/current_clocksource lists the current clock source, and /sys/devices/system/clocksource/clocksource0/available_clocksource lists the available clock sources. With cat you can switch them. That way you may be able to quantify the effects on a single machine. Learned the hard way while tracking clock-skew on a multicore system. The hpet may not be the fastest (that would be the cpu timer), but it's the fastest (IME) that gives guarenteed monotonic time. Have a nice day, -- Martijn van Oosterhout <klep...@svana.org> http://svana.org/kleptog/ > He who writes carelessly confesses thereby at the very outset that he does > not attach much importance to his own thoughts. -- Arthur Schopenhauer
signature.asc
Description: Digital signature
