Getting time in milliseconds

[Pravesh]

Hi:
is there a way to get current system time in milliseconds...
which functions and headers??

thanks
pravesh

 

[Mike Wahler]

Hi:
is there a way to get current system time in milliseconds...

Not portably.

which functions and headers??

The standard functions for retrieving system time and
working with time are declared by the header <time.h>.
They including 'time()', 'localtime()', and 'gmtime()',
among others. However, the resolution of the time
is implementation-specific.

-Mike

 

[Merrill & Michele]

Pravesh:

:
Not portably.

The standard functions for retrieving system time and
working with time are declared by the header <time.h>.
They including 'time()', 'localtime()', and 'gmtime()',
among others. However, the resolution of the time
is implementation-specific.

But if, conjecturally, some one put a gun to your head and said "I need
milliseconds from the arbitrary machine using C compiled on said machine,"
you wouldn't get your brains blown out, correct? In particular, is this not
true if you let a program "warm up" to an OS for, say, a minute? MPJ

 

[Mike Wahler]

But if, conjecturally, some one put a gun to your head and said "I need
milliseconds from the arbitrary machine using C compiled on said machine,"
you wouldn't get your brains blown out, correct?

It's entirely possible that I would. "Arbitrary machine" might not
have the requested functionality. Or perhaps a C translator for it
does not exist.

In particular, is this not
true if you let a program "warm up" to an OS for, say, a minute? MPJ

Some platforms, operating systems, and C implementations do provide
the requested functionality, others do not. Also note that a C program
need not be hosted by an operating system at all.

-Mike

 

[Jack Klein]

But if, conjecturally, some one put a gun to your head and said "I need
milliseconds from the arbitrary machine using C compiled on said machine,"
you wouldn't get your brains blown out, correct? In particular, is this not
true if you let a program "warm up" to an OS for, say, a minute? MPJ

Sure, you can always multiply the return value of difftime() by 1000.

But there are a lot of systems out there that don't track time
accurately to the millisecond.

 

[Merrill & Michele]

Jack Klein:
Sure, you can always multiply the return value of difftime() by 1000.

But there are a lot of systems out there that don't track time
accurately to the millisecond.

That systems don't track milliseconds doesn't mean that we can't track THEM
to the millisecond. That is, with a little elbow grease and the view that
the occurence of the next second can be seen as a Poisson process. The
following code is crude, but I think it illustrates that one isn't shackled
by notions smaller than a second. I think I recall that a "jiffy" is 10^-52
seconds. MPJ

#include <stdio.h>
#include <time.h>
int main (){
time_t timer;
long i, counter, aboutbillion, fiveseconds;
aboutbillion = 0;
counter = 0;
fiveseconds = (long)(time(&timer) + 5);
while (aboutbillion < fiveseconds){
aboutbillion = (long)time(&timer);
++counter;
}
printf (" counter= %ld\n", counter);
printf (" timer= %ld\n", aboutbillion);
printf (" and five= %ld\n", fiveseconds);
return 0;
}

 

[suman kar]

Hi:
is there a way to get current system time in milliseconds...
which functions and headers??

Short reply:in C, no.

Long reply:But there are libraries that define certain structures and functions
that let you manipulate time values.That is system/implementation dependant.Also
you will need to know why and where you are using it.And that's exactly OT here.
E.g:if you are on *nix systems you can probably find something like time.h,
look up on it.And Google for it!There are lots of resources available.

HTH
Suman.

 

[Christian Kandeler]

Sure, you can always multiply the return value of difftime() by 1000.

And then divide the result by 1000000.


Christian

 

[ranjeet]

Hi:
is there a way to get current system time in milliseconds...
which functions and headers??

Yes, there is Fucntion to compute/get time of the specified fuction.
(How much fucntion is taking time to execute),I think this is your Goal.

for linux --> #include <sys/time.h>
gettimeofday


See the both the arguments in it
and You will be able to get the Time in milliseconds
Hope this will help you out.
If You have the problem then drop the mail.

Enjoy
Ranjeet

 

[Jens.Toerring]

That systems don't track milliseconds doesn't mean that we can't track THEM
to the millisecond. That is, with a little elbow grease and the view that
the occurence of the next second can be seen as a Poisson process. The
following code is crude, but I think it illustrates that one isn't shackled
by notions smaller than a second. I think I recall that a "jiffy" is 10^-52
seconds. MPJ

#include <stdio.h>
#include <time.h>
int main (){
time_t timer;
long i, counter, aboutbillion, fiveseconds;
aboutbillion = 0;
counter = 0;
fiveseconds = (long)(time(&timer) + 5);

There's nothing that guarantees that time_t is a time in seconds on
all systems, at least the C standard does only says that time_t is
a "arithmetic type capable of representing times".

while (aboutbillion < fiveseconds){
aboutbillion = (long)time(&timer);
++counter;
}
printf (" counter= %ld\n", counter);
printf (" timer= %ld\n", aboutbillion);
printf (" and five= %ld\n", fiveseconds);
return 0;
}

Even if time_t does return times in seconds that won't do you any
good on a multi-tasking OS. What you try to do here is measure the
time a call of time() takes - but that will only give you a useful
result if the process gets all the CPU time during that 5 seconds.
But on most modern operating systems the CPU time gets distributed
between different processes, and the OS itself uses some time for
it's own purposes. So you don't have a chance to get a reproducible
value that way since you don't have any idea how much time the other
processes get (you don't even know how many there are) and how much
time the OS is going to need.
Regards, Jens

 

[Richard Bos]

Yes, there is Fucntion to compute/get time of the specified fuction.

Not in ISO C, there isn't.

(How much fucntion is taking time to execute)

That's not what he asked for.

for linux --> #include <sys/time.h>
gettimeofday

for windows --> #include <time.h>
GetTickCount is the function

Now please answer the question for the Sinclair QL. And then for my
microwave controller.

Richard

 

[Chris Torek]

That systems don't track milliseconds doesn't mean that we can't track THEM
to the millisecond. That is, with a little elbow grease and the view that
the occurence of the next second can be seen as a Poisson process. ...

Except that time is *not* a Poisson process. Time is isochronous
(by definition), and isochronous processes are not Poisson. (Events
in a Poisson process are characterized by an exponential probability
distribution.)

This distinction can actually matter, as Steve McCanne and I showed
in a paper given at a Usenix in the 1990s. Unix-like systems whose
scheduler is driven from the same clock as their "random" (actually
not random at all!) sampling clock provide just what is needed to
write programs whose resource usage is systematically mismeasured.
This sort of mis-measuring can and does occur "by accident", as
well as on purpose in our "hog.c" program (which uses more than
90% of the available CPU time, even though "ps" commands show it
using under 5%).

To get accurate measurements, many modern CPUs provide a clock-cycle
counter. Using it requires a lot of careful attention to details,
all of which are, unfortunately, off-topic in comp.lang.c.

 

[Merrill & Michele]

Jack Klein: But there are a lot of systems out there that don't track
time

Jens Toerring:
There's nothing that guarantees that time_t is a time in seconds on
all systems, at least the C standard does only says that time_t is
a "arithmetic type capable of representing times".

Even if time_t does return times in seconds that won't do you any
good on a multi-tasking OS. What you try to do here is measure the
time a call of time() takes - but that will only give you a useful
result if the process gets all the CPU time during that 5 seconds.
But on most modern operating systems the CPU time gets distributed
between different processes, and the OS itself uses some time for
it's own purposes. So you don't have a chance to get a reproducible
value that way since you don't have any idea how much time the other
processes get (you don't even know how many there are) and how much
time the OS is going to need.

If I get you correctly, then all this stuff I just lifted from time.h is OS
stuff.

#ifndef _TM_DEFINED
struct tm {
int tm_sec; /* seconds after the minute - [0,59] */
int tm_min; /* minutes after the hour - [0,59] */
int tm_hour; /* hours since midnight - [0,23] */
int tm_mday; /* day of the month - [1,31] */
int tm_mon; /* months since January - [0,11] */
int tm_year; /* years since 1900 */
int tm_wday; /* days since Sunday - [0,6] */
int tm_yday; /* days since January 1 - [0,365] */
int tm_isdst; /* daylight savings time flag */
};
#define _TM_DEFINED
#endif


/* Clock ticks macro - ANSI version */

#define CLOCKS_PER_SEC 1000

An arithmetic type capable of representing time. So kann die Zeit nicht
dargestellt werden. MPJ

 

[Richard Bos]

[ BTW, _please_ use proper attribution lines. ]

If I get you correctly, then all this stuff I just lifted from time.h is OS
stuff.

You don't get him correctly; what you quote has nothing whatsoever to do
with time().

#ifndef _TM_DEFINED

_This_ line is implementation-specific, as are the related lines below.

struct tm {
int tm_sec; /* seconds after the minute - [0,59] */
int tm_min; /* minutes after the hour - [0,59] */
int tm_hour; /* hours since midnight - [0,23] */
int tm_mday; /* day of the month - [1,31] */
int tm_mon; /* months since January - [0,11] */
int tm_year; /* years since 1900 */
int tm_wday; /* days since Sunday - [0,6] */
int tm_yday; /* days since January 1 - [0,365] */
int tm_isdst; /* daylight savings time flag */
};

These members of struct tm, however, are perfectly defined in the
Standard. Their order is not specified, and struct tm could have other
members, but those listed here are required.
However, struct tm is used by several functions, but _not_ by time().

/* Clock ticks macro - ANSI version */

#define CLOCKS_PER_SEC 1000

CLOCKS_PER_SEC is indeed ISO (not just ANSI!) C, but its value is
implementation-specific. Moreover, it's not used with time(), but with
clock().

An arithmetic type capable of representing time. So kann die Zeit nicht
dargestellt werden.

Oh, doch, kann sie. But you'll need to use something like ctime() to get
a human-readable representation from it, and you cannot depend on having
any particular resolution.

Richard

 

[Merrill & Michele]

:
[ BTW, _please_ use proper attribution lines. ]

I thought I worked hard to get the right author attributed with the correct
number of greater than signs. Is this not what is desired? Apparently, you
omit them entirely (?).

You don't get him correctly; what you quote has nothing whatsoever to do
with time().

I freely admit that I don't get him correctly; I'm trying to determine how
far out in left field I actually am. Wouldn't you expect a declaration of
time_t in time.h?

_This_ line is implementation-specific, as are the related lines below.
These members of struct tm, however, are perfectly defined in the
Standard. Their order is not specified, and struct tm could have other
members, but those listed here are required.
However, struct tm is used by several functions, but _not_ by time().

Because time() is a system call (?)

CLOCKS_PER_SEC is indeed ISO (not just ANSI!) C, but its value is
implementation-specific. Moreover, it's not used with time(), but with
clock().


Oh, doch, kann sie. But you'll need to use something like ctime() to get
a human-readable representation from it, and you cannot depend on having
any particular resolution.

I'm obviously no match for this topic yet. I should get back to K&R. MPJ

 

[Joona I Palaste]

:
[ BTW, _please_ use proper attribution lines. ]

I thought I worked hard to get the right author attributed with the correct
number of greater than signs. Is this not what is desired? Apparently, you
omit them entirely (?).

The established form is:

==========================cut here============================

Don't worry, we all make mistakes.

Even _I_... =)
=========================cut here=============================

There should be one blank line between every level of quotation. At
least I find it difficult to distinguish between quotation levels if
there are no blank lines.

 

[Merrill & Michele]

Except that time is *not* a Poisson process. Time is isochronous
(by definition), and isochronous processes are not Poisson. (Events
in a Poisson process are characterized by an exponential probability
distribution.)

This distinction can actually matter, as Steve McCanne and I showed
in a paper given at a Usenix in the 1990s. Unix-like systems whose
scheduler is driven from the same clock as their "random" (actually
not random at all!) sampling clock provide just what is needed to
write programs whose resource usage is systematically mismeasured.
This sort of mis-measuring can and does occur "by accident", as
well as on purpose in our "hog.c" program (which uses more than
90% of the available CPU time, even though "ps" commands show it
using under 5%).

To get accurate measurements, many modern CPUs provide a clock-cycle
counter. Using it requires a lot of careful attention to details,
all of which are, unfortunately, off-topic in comp.lang.c.

I would say that it is more to the point a Poisson process is characterized
by a failure rate, lamba, which as I think to recall was also the expected
value. The failure is that time() is no longer equal to itself. If I ran
my little program time ditty for 2 seconds, 5 seconds and thirty seconds,
and then did a little figuring, I bet I could get 60 seconds within a
millisecond. MPJ

 

[Merrill & Michele]

:
[ BTW, _please_ use proper attribution lines. ]

I thought I worked hard to get the right author attributed with the correct
number of greater than signs. Is this not what is desired? Apparently, you
omit them entirely (?).

The established form is:

==========================cut here============================

Don't worry, we all make mistakes.

Even _I_... =)
=========================cut here=============================

There should be one blank line between every level of quotation. At
least I find it difficult to distinguish between quotation levels if
there are no blank lines.

The links for messages and e-mail get snipped?

 

[Jens.Toerring]

:
[ BTW, _please_ use proper attribution lines. ]

I thought I worked hard to get the right author attributed with the correct
number of greater than signs. Is this not what is desired? Apparently, you
omit them entirely (?).

I freely admit that I don't get him correctly; I'm trying to determine how
far out in left field I actually am. Wouldn't you expect a declaration of
time_t in time.h?

That's not the point. 'time_t' can very well be typedef'ed in <time.h>.
But what 'struct tm' is is unrelated to what 'time_t' is - and that
was what you were using in your program. 'struct tm' is something
used to represent times in some (more or less) human-readable form,
while 'time_t' is just some "arithmetic type" that can represent
times in some compacter and more system dependend way. To get it
into a more useful representation you have e.g. ctime(), gmtime()
and localtime(). While a 'time_t' value is often the time in seconds
since some date taken as the zero point, it could also be the time
since then in microsends, nanoseconds or also hours, dependend on
what the systems time resolution allows and what the implementors
thought to be useful.

Because time() is a system call (?)

No, because things were defined that way. time() were probably defined
the way it is because its return value doesn't need much space (when
compared to a 'struct tm' structure) and it's probably fast since it
can store the value in a way that's near to (or even identical with)
the underlying hardware representation of a time, while to get the
time into the 'struct tm' you need a lot of calculations.

Regards, Jens

 

[Joona I Palaste]

:
[ BTW, _please_ use proper attribution lines. ]

I thought I worked hard to get the right author attributed with the correct
number of greater than signs. Is this not what is desired? Apparently, you
omit them entirely (?).

The established form is:

==========================cut here============================

Bar wrote:
Baz wrote:
Quux wrote:
Yeah, well is that so?

Yes, it is, as a matter of fact.

Then my original message was incorrect.

Don't worry, we all make mistakes.

Even _I_... =)
=========================cut here=============================

There should be one blank line between every level of quotation. At
least I find it difficult to distinguish between quotation levels if
there are no blank lines.

The links for messages and e-mail get snipped?

They don't *have* to, but they are allowed to. The way you're quoting
now is completely OK.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers."
- Bill Gates