Date: Fri, 28 Oct 2005 22:32:31 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: David Xu <davidxu@freebsd.org> Cc: Pertti Kosunen <pertti.kosunen@pp.nic.fi>, Poul-Henning Kamp <phk@phk.freebsd.dk>, current@freebsd.org, "Yuriy N. Shkandybin" <jura@networks.ru> Subject: Re: Timers and timing, was: MySQL Performance 6.0rc1 Message-ID: <20051028222454.T20147@fledge.watson.org> In-Reply-To: <436229CF.6040001@freebsd.org> References: <32412.1130505646@critter.freebsd.dk> <436229CF.6040001@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-1276508706-1130535151=:20147
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 28 Oct 2005, David Xu wrote:
>>> On the other hand, a lower risk change might be to simply add a new
>>> CLOCK_ type for lower resolution, and have a timer synchronize a
>>> variable to the system clock once every 1/10 of a second. This avoids
>>> having to muck with VM layout, etc.
>>
>> Is the CLOCK_* namespace ours to muck about with in the first place ?
>>
> I prefer this way, can you implement it? The global page idea is a
> complex, someone can slowly work on it, there are many things can be
> done, for example, fast syscall using sysenter/sysexit.
Just as an experiment, I added two new time counters:
CLOCK_POOR - use a cached time returned by getnanotime(), which may be out
of date by up to 10/hz (see phk's e-mail for the correct
number).
CLOCK_SECOND - Same as CLOCK_POOR, only truncate the nanoseconds field to
0, and return 1 second as the resolution via
clock_getres().
Patch is attached.
Performance measurements on a P4 Xeon, dual processor with UP and SMP
kernel configurations, no debugging. Measured using 10,000 loops of each
system call, 12 samples per clock type. Measurements are in nanoseconds,
measured using CLOCK_REALTIME, which has a resolution of 280ns reported
via clock_getres(). Not surprisingly, the two above clocks measure about
the same (they should do), and are a lot faster than real time
measurements (they should be). As currently implemented, gettimeofday()
appears to cost the same as CLOCK_REALTIME.
It would be interesting to distribution of clock wrongness was, but I'm
not set up to measure that currently.
Robert N M Watson
x 7UP/gettimeofday
+ 7UP/clock_gettime_poor
* 7UP/clock_gettime_realtime
% 7UP/clock_gettime_second
+--------------------------------------------------------------------------+
| @ * |
| @ * |
| @ * |
| @ * |
|+ @ * |
|@ @ x* |
|@%@ @@ x* *** *|
| |__A_M| |_AA|_| |
+--------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 12 1410 1507 1502 1493.75 26.574509
+ 12 523 634 624 595.58333 47.586206
Difference at 95.0% confidence
-898.167 +/- 32.632
-60.1283% +/- 2.18457%
(Student's t, pooled s = 38.5399)
* 12 1437 1627 1503 1507.6667 42.401401
No difference proven at 95.0% confidence
% 12 524 631 623 595 45.696628
Difference at 95.0% confidence
-898.75 +/- 31.6491
-60.1674% +/- 2.11877%
(Student's t, pooled s = 37.379)
x 7SMP/gettimeofday
+ 7SMP/clock_gettime_poor
* 7SMP/clock_gettime_realtime
% 7SMP/clock_gettime_second
+--------------------------------------------------------------------------+
|@ @ * x*|
|@ @ * x*|
|@% @% * x*|
|@@ @@ **x**|
||MA_M |AMM|
+--------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 12 1406 1443 1436 1425.4167 16.527984
+ 12 503 566 517 527.08333 26.352362
Difference at 95.0% confidence
-898.333 +/- 18.6239
-63.0225% +/- 1.30656%
(Student's t, pooled s = 21.9957)
* 12 1404 1450 1444 1430.0833 19.327128
No difference proven at 95.0% confidence
% 12 505 562 549 531.5 26.182923
Difference at 95.0% confidence
-893.917 +/- 18.538
-62.7127% +/- 1.30054%
(Student's t, pooled s = 21.8943)
--0-1276508706-1130535151=:20147
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=time.diff
Content-Transfer-Encoding: BASE64
Content-ID: <20051028223231.J20147@fledge.watson.org>
Content-Description:
Content-Disposition: attachment; filename=time.diff
LS0tIC8vZGVwb3QvdmVuZG9yL2ZyZWVic2Qvc3JjL3N5cy9rZXJuL2tlcm5f
dGltZS5jCTIwMDUvMTAvMjMgMjM6MDA6NTMNCisrKyAvL2RlcG90L3VzZXIv
cndhdHNvbi9jbG9jay9zcmMvc3lzL2tlcm4va2Vybl90aW1lLmMJMjAwNS8x
MC8yOCAxNzo0Mjo0NA0KQEAgLTIyNSw2ICsyMjUsMTQgQEANCiAJY2FzZSBD
TE9DS19NT05PVE9OSUM6DQogCQluYW5vdXB0aW1lKGF0cyk7DQogCQlicmVh
azsNCisJY2FzZSBDTE9DS19TRUNPTkQ6DQorCQlnZXRuYW5vdGltZShhdHMp
Ow0KKwkJYXRzLT50dl9uc2VjID0gMDsNCisJCWJyZWFrOw0KKwljYXNlIENM
T0NLX1BPT1I6DQorCQlnZXRuYW5vdGltZShhdHMpOw0KKwkJYXRzLT50dl9u
c2VjID0gMDsNCisJCWJyZWFrOw0KIAlkZWZhdWx0Og0KIAkJcmV0dXJuIChF
SU5WQUwpOw0KIAl9DQpAQCAtMzA2LDYgKzMxNCw3IEBADQogCXN3aXRjaCAo
Y2xvY2tfaWQpIHsNCiAJY2FzZSBDTE9DS19SRUFMVElNRToNCiAJY2FzZSBD
TE9DS19NT05PVE9OSUM6DQorCWNhc2UgQ0xPQ0tfUE9PUjoNCiAJCS8qDQog
CQkgKiBSb3VuZCB1cCB0aGUgcmVzdWx0IG9mIHRoZSBkaXZpc2lvbiBjaGVh
cGx5IGJ5IGFkZGluZyAxLg0KIAkJICogUm91bmRpbmcgdXAgaXMgZXNwZWNp
YWxseSBpbXBvcnRhbnQgaWYgcm91bmRpbmcgZG93bg0KQEAgLTMxOCw2ICsz
MjcsMTAgQEANCiAJCS8qIEFjY3VyYXRlbHkgcm91bmQgdXAgaGVyZSBiZWNh
dXNlIHdlIGNhbiBkbyBzbyBjaGVhcGx5LiAqLw0KIAkJdHMtPnR2X25zZWMg
PSAoMTAwMDAwMDAwMCArIGh6IC0gMSkgLyBoejsNCiAJCWJyZWFrOw0KKwlj
YXNlIENMT0NLX1NFQ09ORDoNCisJCXRzLT50dl9zZWMgPSAxOw0KKwkJdHMt
PnR2X25zZWMgPSAwOw0KKwkJYnJlYWs7DQogCWRlZmF1bHQ6DQogCQlyZXR1
cm4gKEVJTlZBTCk7DQogCX0NCi0tLSAvL2RlcG90L3ZlbmRvci9mcmVlYnNk
L3NyYy9zeXMvc3lzL3RpbWUuaAkyMDA1LzA0LzAyIDEyOjM1OjE5DQorKysg
Ly9kZXBvdC91c2VyL3J3YXRzb24vY2xvY2svc3JjL3N5cy9zeXMvdGltZS5o
CTIwMDUvMTAvMjggMTc6NDI6NDQNCkBAIC0yMzgsNiArMjM4LDggQEANCiAj
ZGVmaW5lIENMT0NLX1ZJUlRVQUwJMQ0KICNkZWZpbmUgQ0xPQ0tfUFJPRgky
DQogI2RlZmluZSBDTE9DS19NT05PVE9OSUMJNA0KKyNkZWZpbmUJQ0xPQ0tf
U0VDT05ECTUNCisjZGVmaW5lCUNMT0NLX1BPT1IJNg0KICNlbmRpZg0KIA0K
ICNpZm5kZWYgVElNRVJfQUJTVElNRQ0K
--0-1276508706-1130535151=:20147--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051028222454.T20147>