Hello, I'm looking for an alternative to (get-internal-real-time) in
Lisp to obtain more precise time intervals. get-internal-real-time
seems to compare to GetTickCount on Win32 in term of accuracy, where it
doesn't have any precision under 10-20 ms.
I haven't had luck finding any Lisp library dealing with this. There's
no implementation specific extension for that on my implementation
(SBCL).
Do you have suggestions?
Thanks a lot.
<·········@gmail.com> wrote:
+---------------
| Hello, I'm looking for an alternative to (get-internal-real-time) in
| Lisp to obtain more precise time intervals. get-internal-real-time
| seems to compare to GetTickCount on Win32 in term of accuracy, where
| it doesn't have any precision under 10-20 ms.
+---------------
Common Lisp does not define anything more precise than
GET-INTERNAL-REAL-TIME. And whether there even *is* anything
more precise also depends on your operating system, not just
your CL implementation. That said, however...
+---------------
| I haven't had luck finding any Lisp library dealing with this.
| There's | no implementation specific extension for that on my
| implementation (SBCL).
+---------------
Are you sure? SBCL was based on CMUCL, and CMUCL provides the
UNIX:UNIX-GETTIMEOFDAY function:
cmu> (documentation #'unix:unix-gettimeofday 'function)
"If it works, unix-gettimeofday returns 5 values: T, the seconds
and microseconds of the current time of day, the timezone (in
minutes west of Greenwich), and a daylight-savings flag. If it
doesn't work, it returns NIL and the errno."
cmu>
Note that the "seconds" here is *Unix* time in seconds, not CL's
"universal time". Add LISP::UNIX-TO-UNIVERSAL-TIME (2208988800)
to the former to get the latter.
cmu> (unix:unix-gettimeofday)
T
1159335019
692535
420
0
cmu> (loop for i below 10 collect (nth-value 2 (unix:unix-gettimeofday)))
(920407 920427 920435 920442 920449 920456 920462 920469 920476 920482)
cmu> (mapcar #'- (cdr *) *)
(20 8 7 7 7 6 7 7 6)
cmu>
Wow, that's slow! 6-8 us per iteration. Oh, yeah, I forgot,
that's interpreted. Let's try compiled:
cmu> (funcall
(compile nil
(lambda ()
(loop for i below 10
collect (nth-value 2 (unix:unix-gettimeofday))))))
; Compiling LAMBDA NIL:
; Compiling Top-Level Form:
(861686 861687 861688 861688 861689 861689 861690 861690 861691 861691)
cmu> (mapcar #'- (cdr *) *)
(1 1 0 1 0 1 0 1 0)
cmu>
That's better!! ;-} ;-}
Anyway, do an (APROPOS :GETTIMEOFDAY) in SBCL and see what you get...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Are you sure? SBCL was based on CMUCL, and CMUCL provides the
> UNIX:UNIX-GETTIMEOFDAY function:
That's great, thanks a lot. I'm on Linux, so that's perfect. But I'd
love to have my application work under Windows too... Given that
get-internal-real-time is precise enough on Windows, it might be just
great.. if only I could get the Windows port of SBCL to run..
"debugger invoked on a SB-INT:EXTENSION-FAILRE:
Don't know how to REQUIRE SB-BSD-SOCKETS."
Does that tell anybody anything?
(That's when loading up SLIME, I believe sockets are needed to
communicate with Swank)
On 26 Sep 2006 22:15:46 -0700, <·········@gmail.com> wrote:
>
> doesn't have any precision under 10-20 ms.
There is nothing. That's the limit for the type of builtin-clocks
found in integrated circuits.
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper wrote:
> On 26 Sep 2006 22:15:46 -0700, <·········@gmail.com> wrote:
> >
> > doesn't have any precision under 10-20 ms.
>
> There is nothing. That's the limit for the type of builtin-clocks
> found in integrated circuits.
No, the resolution of gettimeofday can be ~2us on modern hardware. The
timer is ~10ms accurate. However the processor supplies the number of
clocks it has experienced since startup, gettimeofday uses this to
derieve the details of time.
On 27 Sep 2006 04:39:32 -0700, <·············@antenova.com> wrote:
> GP lisper wrote:
>> On 26 Sep 2006 22:15:46 -0700, <·········@gmail.com> wrote:
>> >
>> > doesn't have any precision under 10-20 ms.
>>
>> There is nothing. That's the limit for the type of builtin-clocks
>> found in integrated circuits.
>
> No, the resolution of gettimeofday can be ~2us on modern hardware.
So? You forget all the glue hardware, the propagation times,
interrupt latency, software approximations, etc. It's the real-world
afterall, has temperature variations, load fluctuations, etc to smear
out that custom clock, laboratory controlled value you cite. I would
have said "PCs" for "ICs", but the Mac fanatics would have objected....
Try carefully inspecting the output of 'ntpq -c pe' against multiple
stratum 1-2 servers.
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper wrote:
> On 27 Sep 2006 04:39:32 -0700, <·············@antenova.com> wrote:
> > GP lisper wrote:
> >> On 26 Sep 2006 22:15:46 -0700, <·········@gmail.com> wrote:
> >> >
> >> > doesn't have any precision under 10-20 ms.
> >>
> >> There is nothing. That's the limit for the type of builtin-clocks
> >> found in integrated circuits.
> >
> > No, the resolution of gettimeofday can be ~2us on modern hardware.
>
> So? You forget all the glue hardware, the propagation times,
> interrupt latency, software approximations, etc. It's the real-world
> afterall, has temperature variations, load fluctuations, etc to smear
> out that custom clock, laboratory controlled value you cite. I would
> have said "PCs" for "ICs", but the Mac fanatics would have objected....
No I'm not. I was talking about the resolution, not the accuracy.
There are many problems with the absolute accuracy of computer clocks.
The difficult ones being AFAIK the first two you mention latency inside
the OS and incorrect approximations. Defective hardware (and possibly
also OS bugs) is also a problem. Temperature variations are of much
less concern on modern hardware.
The upshot of this is that if you want to time something down to us
over a long period of time, say days, you haven't got much chance of
getting it right. Over a relatively small space of time though things
are more accurate though. It's also OK if you need to do something say
approx every 100us. It's this type of things that's most often
necessary.
> Try carefully inspecting the output of 'ntpq -c pe' against multiple
> stratum 1-2 servers.
Yes.
·········@gmail.com wrote:
> Hello, I'm looking for an alternative to (get-internal-real-time) in
> Lisp to obtain more precise time intervals. get-internal-real-time
> seems to compare to GetTickCount on Win32 in term of accuracy, where it
> doesn't have any precision under 10-20 ms.
>
> I haven't had luck finding any Lisp library dealing with this. There's
> no implementation specific extension for that on my implementation
> (SBCL).
I have implemented get-internal-real-time for SBCL for Windows and it uses
GetProcessTimes, which has 100 nanosecond precision, but I don't know the
accuracy.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getprocesstimes.asp
But it's very easy to use the SBCL alien interface or CFFI to call every
Win32 function you want, like QueryPerformanceCounter.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> I have implemented get-internal-real-time for SBCL for Windows and it uses
> GetProcessTimes, which has 100 nanosecond precision, but I don't know the
> accuracy.
Careful, you can screw up the system clock if you ask for too much
accuracy (no joke).
Hmm, but I think that's when you ask it to wait for a certain number of
milliseconds. I think if it's not a multiple of 10, your system clock
gets skewed by that same difference each time.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist