At 06:19 AM 6/2/2008, Bruce Evans wrote:
These are very slow. Are they on a 486? :-) I get about 262 ns for
CLOCK_REALTIME using the TSC timecounter on all ~2GHz UP systems.
The syscall overhead is about 200 nsec (170 nsec for a simpler syscall
and maybe 30 nsec extra for copyin/out for clock_gettime()) and reading
the TSC timecounter adds another 60 nsec, including a whole 6 nsec for
the hardware part of the read (perhaps more like 30 nsec than 60 for the
whoe read). The TSC doesn't work on all machines (never for SMP), but
this will hopefully change. (Phenom is supposed to have TSCs that are
coherent across CPUs, and rdtsc has slowed down from 12 cycles to 40+
to implement this :-(. Core2 already has a 40+ cycles rdtsc, but AFAIK
it doesn't have coherent TSCs.) Other timecounters are much slower than
the TSC, but I haven't seen one take 8000 nsec since 486 days.
Phenom's don't have TSCs that are coherent, as least on a few machines here:
4 CPUs, running 4 parallel test-tasks.
checking for time-warps via:
- read time stamp counter (RDTSC) instruction (cycle resolution)
- gettimeofday (TOD) syscall (usec resolution)
- clock_gettime(CLOCK_MONOTONIC) syscall (nsec resolution)
new TSC-warp maximum: -4294919263 cycles, 00000000ffffe11b -> 0000000000009cbc
new TSC-warp maximum: -4294919300 cycles, 00000000ffff74e4 -> 0000000000003060
| TSC: 2.24us, fail:3 | TOD: 2.24us, fail:0 | CLK: 2.24us, fail:0 |
The code to test the TSC to check for warping:
http://leaf.dragonflybsd.org/~gary/tests/time-warp-test.c
However, it seems that Core2's don't have any warping of the TSC. I
tested that code on a core2quad for 8 hours with no TSC failures.
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
