On Thu, Apr 13, 2006 at 10:37:17PM +0100, Daniel P. Berrange wrote:
> Basically if doing the RPC(s) takes a millisecond, then
you're in troubles
> anyway because that means 1ms of active CPU time, and the more you sample
> to get accuracy, the more you generate artefact. Adding the timestamp makes
> sense only if the time to process is large and you want accuracy, i.e.
> sampling often, but high latency, and in that case the simple fact of sampling
> often kills any precision you may hope to get, so my gut feeling is that
> this is not useful in practice, but doing so increase the cost of the operation
> even in the fast case or when not needed. Data would help convince me :-)
I've not really got any formal data on it at this time - it was just a random
afternoon thought. I'll see if there's any useful way to get some data on
the effects.
if running as root locally with Xen, then getting the data is a simple
hypercall, I would expect that to be nearly as fast as a gettimeofday(),
and this won't increase precision. In the case of a non-root local process
with an HTTP request to xend the time spent could potentially be quite large
actually not bounded at all due to potential I/O, the quality of the
data extracted then will be poor due to the tme of acquisition, would
that be worth it ? The last corner case is a remote monitoring, and there the
time spent is most likely to be due to network round trip, which in general
is approximated by taking the medium time between emission and reception
the time to do the 2 gettimeofday() are probably neglectible.
So in those 3 kind of extreme scenario it's a bit unclear how adding the
timestamp to the data would really help, except maybe as a convenience to
the user layer.
Actually getting some data about the costs of doing the call as root
though the hypervisor versus the xend HTTP RPC would be an interesting
datapoint in itself, I initially wanted to hack virsh to extract
statistics about this but never took the time to do it :-)
Daniel
--
Daniel Veillard | Red Hat
http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/