Measurements

[ineiti]

Perhaps we should use better measurements than wall-clocking what is happening for each round. What are the possibilities to measure directly in the go-program how much cpu-power we used?

[ineiti]

OK, so I found syscall.Getrusage which can give the usage-stats of the currently running process. Using that we could re-write the measurements:

• measuring the processor-usage for each round instead of the wall-clock
• change forkexec to return processor time divided by the number of rounds

But perhaps the wall-clock-time is also interesting. And the total time from forkexec does also include the setup-time... Thoughts?

[bford]

Wait, I thought you were already using getrusage. What numbers is the CPU graph you sent me based on, if not that?

[ineiti]

The CPU-graph is using the

ProcessState.SystemTime()

on a command. I just discovered Getrusage today…

The time/round is using wall clock.

Le 8 oct. 2015 à 18:39, Bryan Ford notifications@github.com a écrit :

Wait, I thought you were already using getrusage. What numbers is the CPU graph you sent me based on, if not that?

—
Reply to this email directly or view it on GitHub.

[bford]

and ProcessState.UserTime() for user-time, right? Those should be fine too; they should measure the right thing anyway. But I guess you meant that the benefit of Getrusage is that you get the CPU time consumed by the calling process, not just by child processes? I guess I just misunderstood the concern.

[ineiti]

My main concern is to know what is important to measure. We have

• wall-clock (time.Since) which may indicate time spent on network-messages
• processor-time (Getrusage, SystemTime) which indicates the total time spent calculating

So, when do we want to know what? In addition, consider:

• some algorithms might make shorter wall-clock-time by parallelising checks, but the processor-time would stay equal - should we parallelise or not?
• same question, but this time thinking about the fact that we have multiple processes per server - is it better to count wall-time or processor-time?

[ineiti]

Note to self: syscall.Getrusage doesn't measure anything for syscall.RUSAGE_CHILDREN

[ineiti]

Please comment on things we want to measure:

• processor- and wall-clock for setup
• processor- and wall-clock for a round
• processor-clock for checking

where processor-clock is given by Getrusage and wall-clock by Time.since

[bford]

For the set of graphs measuring round time, we want wall-clock time - the total amount of real time it takes to do a round, typically as perceived by the leader.

For the set of graphs measuring CPU time, we want processor-clock time - i.e., the amount of processor time any or all CPUs have spent actually crunching on crypto and such, including parallel computing time, but not including time processors are waiting for network messages and such.

Is that what you were asking?

[ineiti]

Yep, I was not completely sure whether we still need the wall-clock, but for the round-trip time it makes sense.

On 12 Oct 2015, at 22:39, Bryan Ford notifications@github.com wrote:

For the set of graphs measuring round time, we want wall-clock time - the total amount of real time it takes to do a round, typically as perceived by the leader.

For the set of graphs measuring CPU time, we want processor-clock time - i.e., the amount of processor time any or all CPUs have spent actually crunching on crypto and such, including parallel computing time, but not including time processors are waiting for network messages and such.

Is that what you were asking?

—
Reply to this email directly or view it on GitHub #29 (comment).

[ineiti]

Continues in pull-request #42