On Tue, Oct 4, 2011 at 2:57 AM, Peter Senna Tschudin <peter.senna@xxxxxxxxx> wrote: > Hi Peter, > > Thanks for the repply. I've realized that I have no need to transform > the arbitrary number in something like seconds because I'm interested > in comparing them. > > Is it safe to say that if I do not make the division by > CPU_THOUSAND_HZ I have the number of clock cycles that were "spent" > between the calls to getticks()(including some for getticks() itself)? > > Please see below. > > Thank you! > > Peter > > On Mon, Oct 3, 2011 at 1:17 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: >> why not u put a sleep(1) here like this: >> >>> ticks tickBegin, tickEnd; >>> tickBegin = getticks(); >>> >> >> sleep(1); >> >>> >>> tickEnd = getticks(); >>> double time = (tickEnd-tickBegin)/CPU_THOUSAND_HZ; >>> >> Then u know that it is reading the TSC values for 1 sec. And by >> running the same program on different system u will get different >> "time" values, and then u divide by that values for THAT system - so >> that eventually running the same program on different system will get >> u the same difference of ticks, which in our present case is "1". >> After this "normalization", you can run your system with any timing >> difference, and maximum achievable resolution is of course 1 sec. Is >> that what u wanted? > > That sounds as great idea but: > - may dynamic clock rate and multiple CPU cores mess with your proposal? > - How precise is sleep about sleeping for 1 second? > - I hope that the out of order execution mechanism of the CPU gets > frustrated with your proposal and runs the instructions in the order > we're expecting (tickBegin-> sleep-> tickEnd). How can we be sure that > the instructions were run in correct order? > >> >> BTW, modern OS does not use TSC any more, but yes, your assembly can >> still access and read TSC. But the OS usually read from HPET (which >> is how sleep(1) calculate the time differences) and to read the HPET >> here is a link: >> >> http://www.fftw.org/cycle.h > > Looking cycle.h I found this familiar code(starts on line 216): > > /*----------------------------------------------------------------*/ > /* > * X86-64 cycle counter > */ > > static __inline__ ticks getticks(void) > { > unsigned a, d; > asm volatile("rdtsc" : "=a" (a), "=d" (d)); > return ((ticks)a) | (((ticks)d) << 32); > } > Oh no, you are right, I just re-quote the link from Wiki which says 'code to read the high-resolution timer on many CPUs and compilers' ......ok, RDTSC is nevertheless a high resolution timer as well..... > The code found on cycle.h is so similar to the one I was using that I > guess that both codes were written by the same author. I got the code > I'm using from the paper at: > http://people.virginia.edu/~chg5w/page3/assets/MeasuringUnix.pdf > >> >> And query the OS via: >> >> cat /sys/devices/system/clocksource/clocksource0/* >> hpet acpi_pm >> hpet >> The above is from my x86 Ubuntu 10.04 laptop. >> and u can see from above that "tsc" is missing from my system. >> (linux kernel is 2.6.35-22) >> >> For TSC, I am not sure what is the highest resolution u can go, but in >> a modern SoC chip, with 600Mhz core speed (speaking of PowerPC >> http://en.wikipedia.org/wiki/PowerPC_e500), the fastest execution is >> 600 millions instruction per sec, assuming the instruction is one insn >> per clock. With this kind of speed, TSC is a very bad for measuring >> time differences. > > This is my mistake. I did not told you about my tests will run only on x86 arch. > Sorry to you too....I forgotten to mention that my hpet output is from x86 arch. Anyway, TSC is nevertheless a valid timer, after some research, I found its resolution is as good as HPET: http://aufather.wordpress.com/2010/09/08/high-performance-time-measuremen-in-linux/ But it did highlight lots of risks with TSC. And reading further: http://stackoverflow.com/questions/3388134/rdtsc-accuracy-across-cpu-cores http://stackoverflow.com/questions/3835111/whats-the-most-accurate-way-of-measuring-elapsed-time-in-a-modern-pc http://the-b.org/Linux_timers beware of something called "constant TSC" or 'invariant tsc', and overflow time (all different timers are given except for TSC, in link above) - if your duration is longer than that, the timer would have turnaround before that and gave you inaccurate figures. >> >> On Mon, Oct 3, 2011 at 9:27 AM, Peter Senna Tschudin >> <peter.senna@xxxxxxxxx> wrote: >>> Dear list members, >>> >>> I'm following: >>> >>> http://people.virginia.edu/~chg5w/page3/assets/MeasuringUnix.pdf >>> >>> And I'm trying to measure executing time of simple operations with RDTSC. >>> >>> See the code below: >>> >>> #include <stdio.h> >>> #define CPU_THOUSAND_HZ 800000 >>> typedef unsigned long long ticks; >>> static __inline__ ticks getticks(void) { >>> unsigned a, d; >>> asm("cpuid"); >>> asm volatile("rdtsc" : "=a" (a), "=d" (d)); >>> return (((ticks)a) | (((ticks)d) << 32)); >>> } >>> >>> void main() { >>> ticks tickBegin, tickEnd; >>> tickBegin = getticks(); >>> >>> // code to time >>> >>> tickEnd = getticks(); >>> double time = (tickEnd-tickBegin)/CPU_THOUSAND_HZ; >>> >>> printf ("%Le\n", time); >>> } >>> >>> How can the C code detects the correct value for CPU_THOUSAND_HZ? The >>> problems I see are: >>> - It is needed to collect the information for the CPU that will run >>> the process. On Core i7 processors, different cores can run at >>> different clock speed at same time. >>> - If the clock changes during the execution of process, what should >>> it do? When is the best time for collecting the clock speed? >>> >>> The authors of the paper are not sure about the effects of >>> "asm("cpuid");" Does it ensure that the entire process will run on the >>> same CPU, and will serialize it avoiding out of order execution by the >>> CPU? >>> >>> Thank you very much! :-) >>> >>> Peter >>> >>> >>> -- >>> Peter Senna Tschudin >>> peter.senna@xxxxxxxxx >>> gpg id: 48274C36 >>> >>> _______________________________________________ >>> Kernelnewbies mailing list >>> Kernelnewbies@xxxxxxxxxxxxxxxxx >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >> >> >> >> -- >> Regards, >> Peter Teoh >> > > > > -- > Peter Senna Tschudin > peter.senna@xxxxxxxxx > gpg id: 48274C36 > -- Regards, Peter Teoh _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
