#5 Sample delay fix for non interactive mode

[Christian Ferrari]

If you collected the samples for quite a long period, for example 2880 samples (one sample every 30 seconds), nmon would accumulate some delay sample after sample and, at the end of the day, the delay can be order of seconds/minutes.
The following numbers was collected from a real system:
17:19:35
17:20:05
17:20:35
17:21:05
17:21:35
...
09:40:56
09:41:26
09:41:56
09:42:26
09:42:56

If there was no delay, you should collect something like this:
17:19:35
17:20:05
17:20:35
17:21:05
17:21:35
...
09:40:35
09:41:05
09:41:35
09:42:05
09:42:35

after 1967 samples, nmon accumulated 21 delay seconds.
For some use cases nmon behavior is not an issue, but if you want to correlate data collected with different tools inside different systems, the delay could be noisy.

I'm attaching a sample patch that can be applied to the original distributed source code: it slightly changes the sleep time of every loop taking in account the initial start time instead of sleeping for a constant time.

I use nmon14g.c, but I prepared a patch for nmon14i.c as well; the patches were tested on SuSE Linux Enterprise Server 11 for x86_64 architecture.

[Nigel Griffiths]

Thanks
I will take a look later.

Nigel Griffiths
Advanced Technology Support, EMEA: POWER7, POWER8, AIX, PowerVM, Linux on
Power
VIOS, Shared Storage Pools, PowerVC, PowerSC, WPAR, AME, Performance &
nmon

E-mail: nag@uk.ibm.com
Find me on: @mr_nmon
Technical-Info: 140 POWER+AIX Movies + AIX VUG
External--Blog: AIXpert Blog
Internal----Wiki: EMEA Power Advanced Technology

76-78 Upper Ground,
South Bank, London,
SE1 9PZ
United Kingdom

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[Nigel Griffiths]

Impilemeted in the code is a different way.
Thanks for the concept and ideas.