Hello,

I posted a question about timing some time a go and got an answer; but let down for a while because other problems required my attention. So, I need a simple func to get the current time; mainly to benchmark various implementation choices, possibly for other needs.

The timer module brings the opposite feature, namely it triggers an event after a given elapsed time, while my need is the get the time when a given event occurs...

Using a system command (time on unix) is not possible in the general case, because it can only globally measure the running time of the app, while (1) I have no a priori idea of the relative cost of init tasks such as feeding test data structures, (2) there are numerous test funcs to run (at least 45 in this case) in a row, every running time beeing collected, then post-processed.

So, what I need and hope exists is the simplest possible func returning the current time as a real value (at best with unit=second). I guess this must be obtained from the system (but not the time command), possibly from a C routine. Pointers welcome :-)

Denis
________________________________

vit esse estrany ☣

spir.wikidot.com

You can use EpikTimer for that:

http://wiki.lazarus.freepascal.org/EpikTimer

spir ☣ het geskryf:

let down for a while because other problems required my attention. So, I need a simple func to get the current time; mainly to benchmark various implementation choices, possibly for other needs.

A very crude solution would be to use Sysutils.GetTickCount() before and after a procedure - then calculate the difference (end - start), but if you want more control and higher resolution timing - like in the case of profiling your applications, I would suggest EpikTimer (Felipe posted the link).

EpikTimer is a non-visual component, so can even be used in console applications.

Note:
I can't remember if I submitted a patch for EpikTimer, breaking the dependency on LCL. Originally EpikTimer only had one design-time package, meaning it gets registered in the Lazarus IDE - hence a dependency on LCL. But EpikTimer is non visual, so I split the package in two (Runtime and Designtime). The latter is the only one that now depends on LCL. The Runtime package can be used in Console apps, fpGUI apps etc..

Regards,
- Graeme -

Felipe Monteiro de Carvalho het geskryf:

You can use EpikTimer for that: http://wiki.lazarus.freepascal.org/EpikTimer

Included in the lazarus-ccr bug report is the patch that splits the EpikTimer package into Runtime and Designtime packages. Could you apply this to Lazarus-CCR please.

http://bugs.freepascal.org/view.php?id=16510

Regards,
- Graeme -

On Mon, May 17, 2010 22:25, spir ☣ wrote:

Hello Denis,

I posted a question about timing some time a go and got an answer; but let down for a while because other problems required my attention. So, I need a simple func to get the current time; mainly to benchmark various implementation choices, possibly for other needs.

.
.

If you need a high-resolution timer and only x86 platforms (or maybe x86_64 too), one option would be using the timer available in http://members.yline.com/~tom_at_work/cpudist.zip (see http://members.yline.com/~tom_at_work/ for link to documentation and further information).

A completely platform independent solution included in FPC RTL but with lower precision is using either Dos.GetTime, Dos.GetMsCount or one of functions provided in unit SysUtils (e.g. GetLocalTime, Time or Now).

Tomas

Thank you. Using dos.getTime (including its last arg), the following returns integer time in 10^-2s units:

Function TimeInt : Integer;
var
	h,m,s,f	: word;
begin
	GetTime(h,m,s,f);
	result := 360000*h + 6000*m + s*100 + f;
end;

This is the needed base for my uses. (A unit of 1s is too gross for timing, this leads to endless runs; more precision than 10^-2s is unneeded.)

Denis
________________________________

vit esse estrany ☣

spir.wikidot.com

"spir ☣" :

Thank you. Using dos.getTime (including its last arg), the following returns integer time in 10^-2s units:

[...]

This is the needed base for my uses. (A unit of 1s is too gross for timing, this leads to endless runs; more precision than 10^-2s is unneeded.)

Actually, the resolution is only about 55ms (or, to be precise, the underlying clock ticks with a frequency of 1193182 / 65536 Hz).

Vinzent.

Thank you for this precision. Where does getTime actually get its time? And where do these numbers come from; I mean why chose this time unit instead of plain 1/10 or 1/100 or 1/1000s? (1193182 does not look familiar to my eyes ;-) Do you have an idea on how to get one of those time units (ms would be perfect, since more precision can be rounded, while the contrary is a hard task!)

Denis

______________________________

vit esse estrany ☣

spir.wikidot.com

Thank you for this precision. Where does getTime actually get its time? And where do these numbers come from; I mean why chose this time unit instead of plain 1/10 or 1/100 or 1/1000s? (1193182 does not look familiar to my eyes ;-) Do you have an idea on how to get one of those time units (ms would be perfect, since more precision can be rounded, while the contrary is a hard task!) Denis

The standard clock for the system timer runs at 1,193,182 Hz, derived for the original IBM PC as the 4.77 MHz processor clock divided by 4.

Technically it should use a DOS function. Of course, on non-DOS systems it will be mapped to something different with a probably higher resolution, yet the old DOS time is all accuracy you can assume here.

And where do these numbers come from; I mean why chose this time unit instead of plain 1/10 or 1/100 or 1/1000s? (1193182 does not look familiar to my eyes ;-)

Well, historically it's the frequency driving the programmable interval timer (an 8254). I don't know the exact reason, but it's probably 1/11 of the frequency of a 13.125 MHz quartz (at least that's what it looks like, CMIIW). Whatever the exact choices of base frequency and divider, that's where the 1.193 MHz value comes from.

The second part is due to the fact that the timer values are loaded with the value providing the largest divider value (and thus the least possible interrupt load). This value is actually a zero (16-bit), but having the effect of a divider of 65536), so that the abovementioned and quite strange interrupt frequency comes up.

Do you have an idea on how to get one of those time units (ms would be perfect, since more precision can be rounded, while the contrary is a hard task!)

Actually, I would simply use "SysUtils.Now" as base clock and appropriate rounding. I used that in the past and it provides fairly accurate values while maintaining system portability. The DOS unit is provided for TP compatibility only and I wouldn't advise using it for new code.

Theoretically this clock has a millisecond resolution. IIRC, in practice, the tick behind this clock is about 15 ms under Win32, but under most Unices you'll get the full millisecond resolution.

If you want to get better than that, you need to get system specific, I'm afraid. But as you stated, you don't need more accuracy, so system dependent functions providing a higher resolution simply won't be necessary in your case.

Vinzent.

The standard clock for the system timer runs at 1,193,182 Hz, derived for the original IBM PC as the 4.77 MHz processor clock divided by 4.

Digging a bit deeper clarifies it:

http://sos.enix.org/lxr/source/hwcore/i8254.c?v=6.5

|* Ahhh PC systems are nice toys: this maximum "strange" frequency |* equals that of the NTSC clock (14.31818 MHz) divided by 12. In |* turn, the famous 4.77 MHz cpu clock frequency of the first IBM PC |* is this same NTSC frequency divided by 3. Why the NTSC frequency as |* a base "standard" ? Because the 14.31818 MHz quartz were cheap at |* that time, and because it allows to simply drive altogether the |* cpu, the "time of day" timer, and the video signal generators.

So, the base frequency actually was a 14.318 Mhz quartz, not a 13.125 as I assumed in my previous post.

But that's enough history lessons for a day. ;)

Vinzent.

If you want to get better than that, you need to get system specific, I'm afraid.

That's not true. As Graeme already mentioned there is EpikTimer which is a cross-plattform, high-resolution timer (which btw works very well for realtime tasks).

R.

Reimar Grabowski :

Well, that depends on your definition of "system-specific", doesn't it? ;)

BTW, quoted from the EpikTimer Wiki:

|Tested on:
|Pentium IV 3,2Mhz on Windows and Linux with great precision |(~ 3,220,000,000 ticks per second)
|Pentium 233Mhz with Damn Small Linux. Works great with hardware clock. |Mobile AMD 64 Athlon 3200+ on Windows XP Home (32 bit), Lazarus 9.13 |AMD 64 CPU, running 64 bit version of Ubuntu Linux, Lazarus 9.18. |
|Issues: Needs testing on FreeBSD and older machines that lack TSC |hardware.

I'd expect "cross-platform" to cover a bit more than Windows and Linux on x86 and seemingly depending on a working Time Stamp Counter (no I haven't looked at the source yet).

But as always, YMMV.

Vinzent.