I was asking around in #freebsdhelp on EFNet what the equivalent of
GetTickCount() in the Win32 API is in FreeBSD.
I need a way to properly determine passage of time that is not affected if I
change the system clock for example. The only way I'm aware that you can do
that is by counting the numbe
Andrei Cojocaru wrote:
> I was asking around in #freebsdhelp on EFNet what the equivalent of
> GetTickCount() in the Win32 API is in FreeBSD.
>
> I need a way to properly determine passage of time that is not affected if I
> change the system clock for example. The only way I'm aware that you can
* Andrei Cojocaru <[EMAIL PROTECTED]> [020717 12:02] wrote:
> I was asking around in #freebsdhelp on EFNet what the equivalent of
> GetTickCount() in the Win32 API is in FreeBSD.
>
> I need a way to properly determine passage of time that is not affected if I
> change the system clock for example
rdtsc() will give you cycle counts since system boot. It reads a Pentium
internal register which is incremented at every CPU internal clock cycle.
Deepankar
Andrei Cojocaru wrote:
> I was asking around in #freebsdhelp on EFNet what the equivalent of
> GetTickCount() in the Win32 API is in FreeB
In message <00d501c22dc4$57d08b00$0200a8c0@twothousand>, "Andrei
Cojocaru" writ
es:
> I was asking around in #freebsdhelp on EFNet what the equivalent of
> GetTickCount() in the Win32 API is in FreeBSD.
>
> I need a way to properly determine passage of time that is not affected if I
> change the
PROTECTED]>
To: "Andrei Cojocaru" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, July 17, 2002 13:43
Subject: Re: Counting the clock cycles
> In message <00d501c22dc4$57d08b00$0200a8c0@twothousand>, "Andrei
> Cojocaru" writ
> es:
>
Andrei Cojocaru wrote:
>
> doesn't fit my criteria since it changes, bah I'll just use
> gettimeofday since it's a portable API and hope the computers I run
> it on don't change their blocks by too much...
If you're really worried about it, get a GPS device that can provide
you with a PPS signal
PROTECTED]>
Sent: Wednesday, July 17, 2002 14:25
Subject: Re: Counting the clock cycles
> Andrei Cojocaru wrote:
> >
> > doesn't fit my criteria since it changes, bah I'll just use
> > gettimeofday since it's a portable API and hope the computers I run
> > it
depending on the acuracy needed use the uptime..
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
In message <005f01c22dd1$7be7d180$0300a8c0@fivehundred>, "Andrei Cojocaru" writ
es:
>I am already synchronizing using xntp, that's not the problem. The
>problem is by some weird way the clock got out of sync by about 1hr
>during daylight switch on one of the computers I run, and I need a
>reliable
[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, July 17, 2002 14:50
Subject: Re: Counting the clock cycles
> depending on the acuracy needed use the uptime..
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
> I need a way to properly determine passage of time
> that is not affected if I change the system clock
> for example.
how about using setitimer(2) - ITIMER_REAL?
since it appears(?) on almost all unix(-like)
platforms this expires based only on callout (or
jiffies) ticks countdown, and setti
In message: <[EMAIL PROTECTED]>
Darren Pilgrim <[EMAIL PROTECTED]> writes:
: If you're really worried about it, get a GPS device that can provide
: you with a PPS signal for use with ntpd. Then I'd say you could safely
: rely on the computer's clock being accurate.
If you are lucky e
In message: <[EMAIL PROTECTED]>
Poul-Henning Kamp <[EMAIL PROTECTED]> writes:
: In message <005f01c22dd1$7be7d180$0300a8c0@fivehundred>, "Andrei Cojocaru" writ
: es:
: >I am already synchronizing using xntp, that's not the problem. The
: >problem is by some weird way the clock got out
"M. Warner Losh" wrote:
>
> In message: <[EMAIL PROTECTED]>
> Darren Pilgrim <[EMAIL PROTECTED]> writes:
> : If you're really worried about it, get a GPS device that can provide
> : you with a PPS signal for use with ntpd. Then I'd say you could safely
> : rely on the computer's cloc
In message: <[EMAIL PROTECTED]>
Darren Pilgrim <[EMAIL PROTECTED]> writes:
: "M. Warner Losh" wrote:
: >
: > In message: <[EMAIL PROTECTED]>
: > Darren Pilgrim <[EMAIL PROTECTED]> writes:
: > : If you're really worried about it, get a GPS device that can provide
: > : you
In message <[EMAIL PROTECTED]>, "M. Warner Losh" writes:
>In message: <[EMAIL PROTECTED]>
>Poul-Henning Kamp <[EMAIL PROTECTED]> writes:
>: In message <005f01c22dd1$7be7d180$0300a8c0@fivehundred>, "Andrei Cojocaru" writ
>: es:
>: >I am already synchronizing using xntp, that's not the p
In message: <[EMAIL PROTECTED]>
Poul-Henning Kamp <[EMAIL PROTECTED]> writes:
: Unless we want to deal properly with leapseconds and implement TAI,
: we have no choice in that matter.
Well, djm has libraries that keeps the system time in UTC +
leapseconds and causes the right time to
Andrei Cojocaru wrote:
> I am already synchronizing using xntp, that's not the problem. The problem is by
>some weird way the clock got out of sync by about 1hr during daylight switch on one
>of the computers I run, and I need a reliable way to get passage of time (I don't
>need date/time, just
PROTECTED]>; "Cy Schubert - CITS Open
Systems Group" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, July 18, 2002 1:18 AM
Subject: Re: Counting the clock cycles
> Andrei Cojocaru wrote:
> > I am already synchronizing using xntp, that's not the pro
Andrei Cojocaru wrote:
> > Looking for another clock already living there somewhere in the same
> > PC hardware isn't going to fix it.
> >
> > You need to disable CMOS daylight savings time swithing in the BIOS,
> > so that it doesn't jump the reported clock value on you.
>
> Does FreeBSD do that
21 matches
Mail list logo
