[Libvir] Add a timestamp to virDomainInfo ?

[Daniel P. Berrange]

On Thu, Apr 13, 2006 at 04:44:40PM -0400, Daniel Veillard wrote:
> 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 :-)

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.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|