Need to implement a calendar clock with millisecond resolution, please help.

[Hunter]

Hi all,

I know it may sound like dump newbie question (which is very much
true, as I am a newbie, not even a real programmer), but I need to
implement a calendar time clock with a millisecond resolution. For
hours I've been digging the Visual C++ 6 help and Googling like a
madman. It seems to me that the standard C just don't have the tool to
get this type on information. Sure I found the time() and the clock()
but they don't really help me.

Is there any way I can get a real calendar time, say from a system?
Maybe I should look in the direction of some kind of Assemly language
routine inserted into the C (not that I like the option, last time I
touched Assembly was years ago, back at the university).

I'll appreciate any ideas you have.

/* I run VC6, on a PC powered by Win2000 */

[Walter Roberson]

In article <11************ **********@k79g 2000hse.googleg roups.com>,
Hunter <Ig*********@gm ail.comwrote:

>Hi all,

I know it may sound like dump newbie question (which is very much
true, as I am a newbie, not even a real programmer), but I need to
implement a calendar time clock with a millisecond resolution. For
hours I've been digging the Visual C++ 6 help and Googling like a
madman. It seems to me that the standard C just don't have the tool to
get this type on information. Sure I found the time() and the clock()
but they don't really help me.

You are correct, standard C does not have such a mechanism.

You probably don't need to drop into assembler, though; check out
a Windows programming newsgroup to find out what you can do within
the Windows API (since assembler wouldn't be portable anyhow.)

By the way, after you get finished figuring out how to get
millisecond -resoluti0n-, you are going to have the even more
fun task of getting similar -precision-. On most systems, the
built-in real-time clocks drift, fairly noticably, so if you want
calendar time with millisecond resolution, you are going to need
to start thinking about how to keep that clock synchronized with
some sort of standard time signal.
--
Prototypes are supertypes of their clones. -- maplesoft

[Hunter]

Oh... API... Whatever that means :(
As for precision, do you know how much it can "drift"?
I mean, what I need is to synchronize between to programs, each
acquiring it's data from a different source (And the data rate is
about 1kHz), and saving it into the file. The programs not necessarily
start at the same time, but they do run simultaneously most of the
time. So I thought of "time stamping" the data in files.
Thank you very much!

[Army1987]

On Sun, 26 Aug 2007 03:07:23 -0700, Hunter wrote:

Oh... API... Whatever that means :(
As for precision, do you know how much it can "drift"?

Usually the rate of hardware clocks is not extremely accurate, it
can be slightly too fast or too slow, depending among other things
on temperature. Normally the differences are of about one part on
10**5 or less, but if you need to measure times to within one
microseconds it will make the least significant digits bogus.

I mean, what I need is to synchronize between to programs, each
acquiring it's data from a different source (And the data rate is
about 1kHz), and saving it into the file. The programs not necessarily
start at the same time, but they do run simultaneously most of the
time. So I thought of "time stamping" the data in files.

Well, so you just need high precision and resolution, even if
accuracy is not perfect.

--
Army1987 (Replace "NOSPAM" with "email")
No-one ever won a game by resigning. -- S. Tartakower

[Hunter]

Such a drift strikes me as a bit odd. I meen the sysem clock runs at
hundreds of MHz, and probably has plenty of PLLs and dividors to form
all the derivative clocks.

Anyway thanks a lot!

[David Thompson]

On Sun, 26 Aug 2007 03:07:23 -0700, Hunter <Ig*********@gm ail.com>
wrote:

Oh... API... Whatever that means :(

http://en.wikipedia.org/wiki/API and in this case particularly
http://en.wikipedia.org/wiki/Windows_API

As for precision, do you know how much it can "drift"?

s/precision/accuracy/; see PP (previous post)

I mean, what I need is to synchronize between to programs, each
acquiring it's data from a different source (And the data rate is
about 1kHz), and saving it into the file. The programs not necessarily
start at the same time, but they do run simultaneously most of the
time. So I thought of "time stamping" the data in files.

Programs on the same machine, or different machines?

On the same machine, if that machine can be a multiprocessor -- and
any machine you bought recently in the consumer market likely was --
make sure you use a call which gets time from a 'global' or 'shared'
clock, not a per-CPU counter, since those may not be or stay in sync.
I'm confident Windows does provide such a capability, but I'm not sure
if (or when) it's the default, and if not how you get it, and since
it's implementation-specific (to Windows) it's offtopic here.
comp.programmer .ms-windows.win32 is rumored to be good.

On different machines, if you want to keep clocks in sync to the
millisecond level, you need something specialized for the purpose.
There may be some Windows-specific capability, though I haven't heard
of one; the win32 group would probably know. There is an Internet
standard (in both the de-jure and de-facto sense) for this called NTP
(Network Time Protocol), but last I looked they weren't getting very
good precision on Windows. You could try comp.protocols. time.ntp ,
and in particular www.meinberg.de reportedly supports (free) a build
and configuration for Windows from the generic/portable NTP source.
(The company's business is selling precision clock _hardware_, and
they provide this support for NTP free presumably in the hope that
lots more NTP users = somewhat more clock buyers.)

- formerly david.thompson1 || achar(64) || worldnet.att.ne t