Greetings,
as I ran in some "calculate to zero" trouble with my assumptions on the
tick resolution in Solaris x86, I wrote a test module (source/binary
available on request) to verify the characteristics of the usual
suspects ddi_getlbolt(), gethrtime() and drv_usectohz().
Here are my findings from some x86_64 machines:
o 3GHz Pentium-D:
gethrtime() latency: 192ns
gethrtime() resolution: 192 (eff. 1ns)
ddi_get_lbolt() latency: 4ns
ddi_get_lbolt() resolution: 9904769ns
o 2.2GHz Core-2 Duo (4 times faster for gethrtime() at 30% lower
clock rate!):
gethrtime() latency: 48ns
gethrtime() resolution: 48 (eff. 1ns)
ddi_get_lbolt() latency: 2ns
ddi_get_lbolt() resolution: 9935202ns
o Even better: those are from an old 1.6GHz Opteron:
gethrtime() latency: 39ns
gethrtime() resolution: 41 (eff. 1ns)
ddi_get_lbolt() latency: 6ns
ddi_get_lbolt() resolution: 9952182ns
o On all machines, the tick resolution is 10ms, which reflects in what
the drv_usec/hz functions return:
drv_usectohz(1) = 1
drv_usectohz(1000) = 1
^^^^ some (like) might not expect this
drv_usectohz(1000000) = 100
drv_usectohz(1000000000) = 100000
drv_hztousec(1) = 10000
drv_hztousec(1000) = 10000000
drv_hztousec(1000000) = 10000000000
=> Bottom line:
o The low tick resolution, in combination with the 'usec' "resolution"
of the names of the conversion functions can easily cause problems. I
think this should at least be mentioned in the man page.
o Choose your timing functions wisely depending on your requirements on
latency and resolution (also applies to the kernel, which uses
gethrtime() pretty intensively - and 200ns is not cheap!).
Finally, one question as I could not find the code for gethrtime(): is
CPU frequency scaling always considered?
Joachim
--
Joachim Worringen, Software Architect, Dolphin Interconnect Solutions
phone ++49/(0)228/324 08 17 - http://www.dolphinics.com
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
