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 -=|