Re: [Libvir] Add a timestamp to virDomainInfo ?
On Thu, Apr 13, 2006 at 06:49:33PM +0100, Daniel P. Berrange wrote:
The primary use of the virDomainInfo data is in calculating resource
utilization over time. The CPU runtime data, however, is represented
as a counter, so to calulate utilization requires some transformations.
Basically subtract the CPU runtime value for time X, from the value
at time Y, and divide the result by Y-X. Obviously this requires us to
know the times X & Y. Currently the virDomainInfo structure does not
contain this information though, so apps have to call something like
gettimeofday() before virDomainGetInfo(), to record the timestamp of each
virDomainInfo record.
The problem is that this is a pretty poor approximation - particularly
if libvirt is talking via XenD, a non-trivial period of time can pass
between the call to gettimeofday() and the values for virDomainInfo
actually sampled.
the fact that libvirt does it or the application does it generate the
exact same incertitude. You won't get any added precision really...
Thus I would like to suggest that the virtDomainInfo structure be
expanded
to add an extra data field of type 'struct timeval' to record a high
resolution timestamp. Now currently this wouldn't help accuracy all that
much, since libvirt would still be filling this in much the same way as
the app did. It does however, open the door to having Xen itself provide
an accurate timestamp back to libvirt, which would in turn benefit apps
without requiring further code change.
In practice this forces libvir to make one extra syscall for all sampling
even if the application is not interested in such a timestamp. I find this
a bit dubious honnestly. It would make some sense only if the timestamp is
actually added at the protocol level, best is to ask on xen-devel, if
there is a positive feedback then okay why not. But to me this just won't
work in the general case, if you extract the informations from the Xen Store
this mean multiple RPCs to get back the informations which one should be
used for the timestamp ?
In practice what kind of deviation are you seeing ? If you're afraid of
network induced delays ? Please explain with some concrete actual numbers
because I'm not convinced myself, and it would help also convince people
on xen-devel this is actually needed.
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 :-)
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/