Number: 563

Date:  9-Apr-84 16':02':49

Submitter: Sannella.PA

Source: JONL, Raim.pasa (VanBuer@USC-ECL)

Subject: TIMEALL, Time, Control-T should factor out disk swapout time

Assigned To: 

Attn: vanMelle, JonL, Masinter

Status: Open

In/By: 

Problem Type: Bug

Impact: Moderate

Difficulty: Moderate

Frequency: Everytime

Priority: Perhaps

System: Programming Environment

Subsystem: Performance Tools

Machine: 

Disk: 

Lisp Version: 

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
["Masinter" " 6-Sep-84 11':09':47" Source': Subject': Attn': Description':]

Description: '
Date': 13 JAN 84 18':27 PST'
From': JONL.PA'
Subject': (DISABLEGC) on BOYER benchmark'
To':   LispCore↑'
'
is a net loss.  The swap time for new pages dominates.  Approximately 50 secs'
instead of 17CPU and 13GC.'
'
Curiously, however, TIMEALL reports elapsed time and CPU time the same.'
Shouldn''t there be some factoring out for disk swapout time?  TIMEALL also shows'
PAGEFAULTS = 1934'
SWAPWRITES = 1452'
DISKOPS = 1450'
FIXP LISTP'
4    226469'
----------------------------------'
This is Environment/Performance tools (sort of)'
'
Impact': Moderate'
Problem type': bug'
'
Looks like there''s a glitch in the stats.'
'
'
Date': 18 May 84 00':38 PST'
From': JonL.pa'
Subject': Two little timing disappointments'
To': Masinter, vanMelle'
cc': JonL, LispCore↑, LispSupport'
'
. . . '
'
1) TIMEALL still seems to have a bug in it where it charges SWAP time to CPU.   Two runs of the famous FFT benchmark, which should have been identical except for SWAP and gc boundary conditions, showed the same GC time (about 3.2 secs of each), but one was charged 1.56 secs CPU and no SWAP, while the other was charged 2.27 secs CPU and only .157 swap.  Looks to me like there is a *gross* lossage in accounting for the SWAP time.  Is there an AR on this one?'
'
-- JonL --'
'
'
Date': 30 Aug. 1982 4':44 pm PDT (Monday)'
From': Raim.EOS'
Subject': BREAKDOWN'
To': LispSupport.pa'
cc': Raim'
'
Because the Dolphin CPU "runs" during keyboard IO waits, a large bundle of'
CPU time get ascribed to interactive functions by BREAKDOWN thereby'
obscuring the real costs.'
'
One user, Darrel Van Buer, has patched the problem by including \BACKGROUND in the functions being monitored and then manually ignoring that entry.  Should other functions be similarly treated?  Can BREAKDOWN be changed to make this a permanent feature to msake timing more comparable with the 10 version?'
'
*****************'
Date': 31 Aug. 1982 12':03 am PDT (Tuesday)'
From': VANBUER at USC-ECL'
Subject': Control-T'
'
There is also some kind of bug in the statistics printed by control-T, with utilization shown as negative (from looking at the compiled code, I see that utilization is what''s left of 100% when other categories are subtracted, so I guess there is either overlap in some of the statistics, or some timers are overflowing.'
'
		Darrel'
'
'


Workaround: 

Test Case: 

Edit-By: Masinter

Edit-Date:  6-Sep-84 11':09':48