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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/