Newsgroups: comp.parallel.pvm
From: dalle@alto.unice.fr (Olivier.DALLE)
Subject: Re: pvm message passing timing
Organization: ESSI, Universite' de Nice - Sophia Antipolis
Date: 17 Aug 1995 18:11:40 GMT
Message-ID: <4100os$r8s@malibu.unice.fr>

From: dalle@alto.unice.fr (Olivier.DALLE)
Subject: Re: pvm message passing timing
To: eve_li@btgmax.zko.dec.com (Eve Li)

In article <3vp7u4$8ue@nntpd.lkg.dec.com>, you write:
|> I looked at the example director of pvm, and find most of the examples
|> are timed using gettimeofday instead of clock(3), which gives you both
|> user and system time instead of ellapsed time. In a multitasking system,
|> the wall clock time (get from gettimeofday) seems to be inaccurate than
|> clock (the time spent by the process). Can someone discuss the pros
|> and cons of both scheme in measuring times took by pvm for passing
|> messages, Esp, why does one choose gettimeofday instead of clock? 
|> Thanks. 
|> eve

I think the clock function is not at all what you need for the
following reasons :

	- Using clock in a PVM task may not take in account the time
	elapsed while the message (parts of it) is managed by the pvmd.

	- My clock manpage (Sun) says clock returns micro-seconds but has
	only a precision of 16,67 milli-seconds. On the other hand, 
	gettimeofday has a precision of a few micro-seconds (I verified this).
	An explanation could be the following :
	* gettimeofday get the time value from a dedicated hardware component ;
	* the elapsed time given by the clock function is an accumulative
	value computed by the system from time to time (as many kernel stats).
	So, when you call the gettimeofday function, you get the real hardware
	time, but when you call the clock function, you get the last updated
	value of a kernel statistic...

	- the max duration you can evaluate using the clock function
	is limited by the internal integer representation to 2147 seconds 
	(this function returns only one integer).
	gettimeofday gives you an access to a 2-integers structure (timeval)
	which doesn't limit the length of the your time measurments.


Anyway, I agree with you when you say that a wall clock is inaccurate in a 
multi-tasking system... except when the system is unloaded and is not 
switching tasks! But in thit case, do we have realistic evaluations??

Another solution i'm currently working on, is to correct the inaccuracy
of the mesurments by considering the other system indicators but this is really
difficult since these indicators (CPU load, memory in use, users, process 
queue, paging, swapping, etc) are often system dependent and not very accurate.

	hope this helps,

			- Olivier -

----------- DALLE Olivier - Etudiant en These (PhD. Student) ----------------
adr :  Laboratoire I3S - CNRS - URA 1376 | email : dalle@unice.fr
       650, route des Colles,            | www : http://alto.unice.fr/~dalle/
       BP 145, 06903 SOPHIA ANTIPOLIS    | Tel : (33) 92 96 50 58
       FRANCE                            | Fax : (33) 92 96 51 55

