Measuring time differences

[Flash Gordon]

coder1024 wrote:

<snip>

Note that the documentation does not, that I could see, does not specify
an accuracy, so it could well on a C implementation where time() is
accurate to 1 second just return a value accurate to 1 second, with the
scaling to milliseconds and the defined epoch just being to make the
interface consistent rather than to guarantee a given accuracy.

Remember that the APR is basically there to support web appications and
they don't generally require sub-second accuracy on time.

Thank you for that hints! I'll take a look at that, but as this seems to
be a rather big library (and I don't want that much dependencies of my
code) I may or may not find it useful.

Go over to the DOS/Windows groups and you are likely to get much more
helpful replies from people who actually know what facilities are
provided by the systems to support your requirements.
-
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

 

[Flash Gordon]

<snip>

Note that the documentation does not, that I could see, does not specify
an accuracy, so it could well on a C implementation where time() is
accurate to 1 second just return a value accurate to 1 second, with the
scaling to milliseconds and the defined epoch just being to make the
interface consistent rather than to guarantee a given accuracy.

Remember that the APR is basically there to support web appications and
they don't generally require sub-second accuracy on time.

Having checked what apr_time_now does, and checked the Windows
documentation, apr_time_now is definitely NOT suitable if you want to
know time differences, because the functions it uses are ones MS says
NOT to use for time differences.

Yet another perfect example of why system specific questions should not
be answered by people who do not know the system, and why they should be
redirected to appropriate groups.

<snip>

You won't find it useful because it does not solve your problem. There
are correct solutions for Windows and DOS, but someone like Dominik
Wallner is completely unqualified to provide them and is likely to keep
sending you looking at things of no use to you.

 

[coder1024]

Thank you for that hints! I'll take a look at that, but as this seems to
be a rather big library (and I don't want that much dependencies of my
code) I may or may not find it useful.

good luck! hope you can get it resolved

 

[coder1024]

The point is you have ABSOLUTELY NO CLUE as to what might be helpful to
the OP and your suggestion of gettimeofday I can say quite categorically
is of ABSOLUTELY NO HELP and so a COMPLETE waste of everyone's time.
Hence, if you actually know the platform you can point the poster in the
right direction AND tell them to go to a more appropriate group
(suggesting a solution without redirecting them is inappropriate), but
if you don't know the platform the ONLY thing you can sensibly do is
tell them to go to a more appropriate group.

gettimeofday() will work very well if available in the OP's development
environment. the OP didn't provide specifics as to their environment.
I do know the platform. I've developed SW on Windows using cygwin and
gcc and successfully used gettimeofday() when in a similar situation
which is why I suggested it. I've also developed using Visual C++. I
don't know about other environments (Borland C++, etc.). Anyway, the
OP can take 2 minutes to try and call the function and will immediately
know if it isn't there. This is more helpful than your ranting. I
mean, really, did you just get out of bed on the wrong side this
morning? Dare I say... relax?

Regardless, there's also the APR which will almost certainly be
available on the OP's platform if they want to put in the effort to add
a product to their environment and dependencies list.

 

[coder1024]

Having checked what apr_time_now does, and checked the Windows
documentation, apr_time_now is definitely NOT suitable if you want to
know time differences, because the functions it uses are ones MS says
NOT to use for time differences.

Yet another perfect example of why system specific questions should not
be answered by people who do not know the system, and why they should be
redirected to appropriate groups.

The apr_time_now() function retrieves the current system time from
Windows in a FILETIME structure. The MS documentation
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/filetime_str.asp)
for the FILETIME structure says, "It is not recommended that you add
and subtract values from the FILETIME structure to obtain relative
times". It goes on to say that you should instead copy the structure
data into a 64-bit variable and use normal 64-bit arithmetic on it.
Which is exactly what APR does in the FileTimeToAprTime() function.

Granted, the OP doesn't need to worry about this. They should be able
to just call apr_time_now and get what they want and from what I can
tell it should work fine for them on Windows.

<snip>

You won't find it useful because it does not solve your problem. There
are correct solutions for Windows and DOS, but someone like Dominik
Wallner is completely unqualified to provide them and is likely to keep
sending you looking at things of no use to you.
--

The apr_time_now() will solve the OP problem if they're willing and
want to add a dependency to their code and take the time to go download
it, etc. They can also do a quick try at using gettimeofday() to see
if its avaiable. Or they can go to another newsgroup and ask further.

Sounds like 3 alternatives and hopefully the OP is better off than when
they originally posted, which is really the point right?

 

[Flash Gordon]

gettimeofday() will work very well if available in the OP's development
environment. the OP didn't provide specifics as to their environment.
I do know the platform. I've developed SW on Windows using cygwin and
gcc and successfully used gettimeofday() when in a similar situation
which is why I suggested it. I've also developed using Visual C++. I
don't know about other environments (Borland C++, etc.). Anyway, the
OP can take 2 minutes to try and call the function and will immediately
know if it isn't there.

The sensible way to implement gettimeofday would be to use a function MS
SPECIFICALLY recommend against using for measuring time differences
during the execution of a program. Are you claiming to know that on the
implementations that provide it as an EXTENSION do not implement it in
the obvious way, or are you claiming to know more about programming for
Windows than MS?

For the record, I actually have an MSDN subscription, and I have been
reading the documentation, so I *know* that the solutions you are
recommending are *not* the appropriate solutions to use.

> This is more helpful than your ranting. I
mean, really, did you just get out of bed on the wrong side this
morning? Dare I say... relax?

No, your suggestions are NOT helpful because they are NOT the best way
to achieve the OPs aims. It is the fact that you are insisting that you
are providing helpful information when you are actually suggesting
solutions that are inappropriate to the OPs problem.

Regardless, there's also the APR which will almost certainly be
available on the OP's platform if they want to put in the effort to add
a product to their environment and dependencies list.

That, as I stated in another post, is NOT an appropriate solution. I
know this because I read the source code and checked the functions it
uses in MSDN. So again, unless you know more about the correct calls to
use in Microsoft Windows than Microsoft do you are giving BAD advice.

 

[coder1024]

That, as I stated in another post, is NOT an appropriate solution. I
know this because I read the source code and checked the functions it
uses in MSDN. So again, unless you know more about the correct calls to
use in Microsoft Windows than Microsoft do you are giving BAD advice.

See my other reply. The APR function calls Windows APIs which can be
used to compare times. The MS documentation simply says you shouldn't
directly compare the times in the structure but you should first
convert to a 64-bit variable and then to normal 64-bit arithmetic on
that. From what I saw, apr_time_now will work just fine for giving
relative times. Which MS documentation are you referring to which
indicates otherwise? I'm not saying its not there, just that the APR
source and MS documentation I looked through don't seem to agree with
what you're saying.

 

[Keith Thompson]

See my other reply. The APR function calls Windows APIs which can be
used to compare times. The MS documentation simply says you shouldn't
directly compare the times in the structure but you should first
convert to a 64-bit variable and then to normal 64-bit arithmetic on
that. From what I saw, apr_time_now will work just fine for giving
relative times. Which MS documentation are you referring to which
indicates otherwise? I'm not saying its not there, just that the APR
source and MS documentation I looked through don't seem to agree with
what you're saying.

And now here we are arguing about what Microsoft's documentation says.

This is exactly why we try to discourage off-topic discussions here.
I don't know which of you is correct about the Windows APIs. There
are plenty of people who would know, and they hang out in the Windows
newsgroups, which is where this discusssion should be happening.

If the OP had simply been redirected to a Windows or DOS newsgroup in
the first place, he'd probably already have a good (but
system-specific) solution, and we would have had more time to spend
discussing the C programming language, which is the topic of this
newsgroup.

 

[Mark McIntyre]

gettimeofday() will work very well if available in the OP's development
environment.

But the points are
a) you have no clue whether it is available, so may have egregiously
misled the OP

b) even if a function with tht name were available, it might return
something totally different to what you expect eg "around noon, I
think" or the number of femtoseconds since 3rd February 2000.

c) whether it may or may not exist, still doesn't make it topical
here, and here there's almost nobody able to properly correct you if
you're talking bullshit.

OP can take 2 minutes to try and call the function and will immediately
know if it isn't there.

How? Call it? What if he needs a specific header? What if he needs to
install a package he hasn't installed yet? What if he needs a special
coimpiler option? Plus see point b above.

This is more helpful than your ranting.

Was it more helpful than redirecting the OP to a group where he could
get a definitively correct answer, plus lots of other correct answers
to other questions he will probably have later?

Regardless, there's also the APR

I have no idea what this is, but unless its defined in the ISO C
Standard its also offtopic here.

 

[coder1024]

This is exactly why we try to discourage off-topic discussions here.
I don't know which of you is correct about the Windows APIs. There
are plenty of people who would know, and they hang out in the Windows
newsgroups, which is where this discusssion should be happening.

Well, the Windows API documentation is easily accessible on the web, so
its pretty trivial to verify. The whole dive into the Windows API
discussion was definitely off-topic for this forum, but it was only
done in response to the claim that using the APR time function
reccomended wouldn't work and used APIs which MS did not reccomend for
use in figuring out relative times. See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/filetime_str.asp
for more info on this if you're curious.

I believe we're left with at least 3 choices for the OP:

1) gettimeofday() which may or may not be available; quick test to find
this out
2) APR which adds dependencies, but which should provide the time delta
needed
3) go to another newsgroup and ask the question again there

If the OP had simply been redirected to a Windows or DOS newsgroup in
the first place, he'd probably already have a good (but
system-specific) solution, and we would have had more time to spend
discussing the C programming language, which is the topic of this
newsgroup.

they were directed to another newsgroup. they were also provided with
a couple suggestions on how to solve their problem.

 

[coder1024]

But the points are
a) you have no clue whether it is available, so may have egregiously
misled the OP

no, I think you're being a little dramatic there. the OP should be
able to very quickly determine if its available in their environment.
if its not, no loss. if its is, their problem has just been solved.
actually if it isn't they could also try the APR alternative presented.

b) even if a function with tht name were available, it might return
something totally different to what you expect eg "around noon, I
think" or the number of femtoseconds since 3rd February 2000.

if its available, its should be a trivial matter to do a sanity check
that you're getting good data back. since the OP is interested in time
deltas, I don't think it matters what the "0" time is based on.

c) whether it may or may not exist, still doesn't make it topical
here, and here there's almost nobody able to properly correct you if
you're talking bullshit.

I believe gettimeofday() might work for the OP (depending on their
environment) and APR will work for them which is why I posted the info.
I wasn't BS'ing. I was trying to provide some assistance.

Was it more helpful than redirecting the OP to a group where he could
get a definitively correct answer, plus lots of other correct answers
to other questions he will probably have later?

Re-directing the OP to another group is fine. I'm not arguing with
that. I just provided some possible solutions for the OP to try.

I have no idea what this is, but unless its defined in the ISO C
Standard its also offtopic here.

The Apache Portable Runtime (APR) is a C runtime library designed to
provide a number of lower level basic functions for developers. See
http://apr.apache.org/ for more info. It was posted here because I
felt it might be a good alternative for the OP to try in order to solve
their problem if they didn't have gettimeofday() available.

 

[Martin Ambuhl]

Flash Gordon wrote:

the OP didn't provide specifics as to their environment.
I do know the platform.

What part of 'but finally it should run only on a Windows/DOS machine',
from the original post, did you not understand?

 

[coder1024]

What part of 'but finally it should run only on a Windows/DOS machine',
from the original post, did you not understand?

By environment I was referring to compiler. For example, if you're
using gcc/cygwin on Windows you could use the gettimeofday() function.
But, under Visual C++ the function is not available.

 

[Flash Gordon]

See my other reply. The APR function calls Windows APIs which can be
used to compare times. The MS documentation simply says you shouldn't
directly compare the times in the structure but you should first
convert to a 64-bit variable and then to normal 64-bit arithmetic on
that. From what I saw, apr_time_now will work just fine for giving
relative times. Which MS documentation are you referring to which
indicates otherwise? I'm not saying its not there, just that the APR
source and MS documentation I looked through don't seem to agree with
what you're saying.

Cut from the current documentation my company pays for me to have:
| The system can periodically refresh the time by synchronizing with a
| time source. Because the system time can be adjusted either forward or
| backward, do not compare system time readings to determine elapsed
| time.

It goes on to suggest where to look for functions which should be used
for measuring elapsed time during program execution.

BTW, *plonk*, since I don't want to be discussing one of the many
specific systems I program here.

 

[Flash Gordon]

Keith Thompson wrote:

And now here we are arguing about what Microsoft's documentation says.

This is exactly why we try to discourage off-topic discussions here.

<snip>

Sorry Keith, and the rest of the group. I normally manage to avoid
letting erroneous off topic advice tempt me in to a debate, but I've now
plonked coder1024, so this won't be debated further by me.

 

[jacob navia]

One way of doing that (under an x86 and in standard C)
is:

#include <stdio.h>
long long (*rdtsc)(void);

int main(void)
{
unsigned char fn[] = {0xf,0x31,0xc3};
rdtsc = (long long(*)(void)) fn;
long long cycles = rdtsc();
printf("Cycles since machine start = %lld\n",cycles);
return 0;
}

That function will return the number of cycles
since the CPU started, expressed as a 64 bit number.

At 2GHZ that makes for an EXTREMELY accurate and reliable timer.

The only problem with it is that the CPU keeps counting cycles
when your program is NOT running but it has been swapped out
and is inactive.

If your machine is slightly loaded, this will work quite OK.


jacob

 

[jacob navia]

In a non C99 compatible compiler like msvc that should be:
#include <stdio.h>
__int64 (*rdtsc)(void);

int main(void)
{
unsigned char fn[] = {0xf,0x31,0xc3};
__int64 cycles;
rdtsc = (__int64(*)(void)) fn;
cycles = rdtsc();
printf("Cycles since machine start = %I64d\n",cycles);
return 0;
}

The "fn" values are:
0xf 0x31: rdtsc instruction.
0xc3 return

The rdtsc instruction leaves the 64 bit value of the time stamp counter
in EAX:EDX.

Normally you would be interested in the difference between
two calls.

 

[Mark McIntyre]

no, I think you're being a little dramatic there. the OP should be
able to very quickly determine if its available in their environment.

Bollocks. And if you can't see why, you're probably also incapable of
understanding the other arguments that have been made to you.

if its available, its should be a trivial matter to do a sanity check
that you're getting good data back. since the OP is interested in time
deltas, I don't think it matters what the "0" time is based on.

And if it returns "A quarter past the eleventh hour, since you ask",
or "slightly before noon, my good fellow"?

I wasn't BS'ing. I was trying to provide some assistance.

You miss the point entirely. You failed in the latter, and are now
persisting in ignoring polite (though increasingly less polite)
requests to stop it.

The Apache Portable Runtime (APR) is

I know that you dolt. I don't give two hoots. Its not topical here, so
here I know nothing of it. Stop wittering on about it.

 

[Richard Heathfield]

jacob navia said:

In a non C99 compatible compiler like msvc that should be:
#include <stdio.h>
__int64 (*rdtsc)(void);

int main(void)
{
unsigned char fn[] = {0xf,0x31,0xc3};
__int64 cycles;
rdtsc = (__int64(*)(void)) fn;
cycles = rdtsc();
printf("Cycles since machine start = %I64d\n",cycles);
return 0;
}

foo.c:2: parse error before `*'
foo.c:2: warning: type defaults to `int' in declaration of `__int64'
foo.c:2: `__int64' declared as function returning a function
foo.c:2: ANSI C forbids data definition with no type or storage class
foo.c: In function `main':
foo.c:7: `__int64' undeclared (first use in this function)
foo.c:7: (Each undeclared identifier is reported only once
foo.c:7: for each function it appears in.)
foo.c:7: parse error before `cycles'
foo.c:8: `rdtsc' undeclared (first use in this function)
foo.c:8: `__int64' used prior to declaration
foo.c:8: warning: implicit declaration of function `__int64'
foo.c:8: parse error before `)'
foo.c:9: `cycles' undeclared (first use in this function)
foo.c:9: `rdtsc' used prior to declaration
foo.c:9: warning: implicit declaration of function `rdtsc'
foo.c:10: warning: unknown conversion type character `I' in format
foo.c:10: warning: too many arguments for format
foo.c:6: warning: unused variable `fn'

 

[jacob navia]

I said that that program was for msvc like compilers. For gnuish
compilers use:
[root@gateway root]# uname -a
Linux gateway 2.4.18-6mdk #1 Fri Mar 15 02:59:08 CET 2002 i586 unknown
[root@gateway root]# cat rdtsc.c
#include <stdio.h>
long long (*rdtsc)(void);

int main(void)
{
unsigned char fn[] = {0xf,0x31,0xc3};
long long cycles;
rdtsc = (long long(*)(void)) fn;
cycles = rdtsc();
printf("Cycles since machine start = %lld\n",cycles);
return 0;
}
[root@gateway root]# gcc rdtsc.c
[root@gateway root]# ./a.out
Cycles since machine start = 7045896211955
[root@gateway root]#