lfm@ukc.UUCP (05/04/84)
Can anybody enlighten me as to why the following things happen :
1) When testing some code that interacts with a server on a remote machine
I replaced a programmed C copy loop with a call on a fast move subroutine,
as expected the user time as reported by "time(1)" dropped significantly.
However, the system time increased considerably, and the elapsed stayed
about the same. This was repeatable and consistent, and the program was
unmodified in any other way. (PDP11/45 and V7 by the way).
2) (This time on a PERQ running PNX - a V7 port) This time the
optimisation was put into the file server end, so the program running
locally was completely unchanged. When the test was run again the system
time increased significantly and consistently. The time was measured
was only local and could not include any of the time on the remote machine.
No extra messages were generated by the communication between the processes
(A first thought was that with the speed increase things were running too
fast and retries were happening) and the local process cannot have done
anymore work than it would have before the change to the server.
So, any suggestions?
Lindsay F. Marshall
uucp : ...!{mcvax,vax135}!ukc!lfm
ARPA : Lindsay_Marshall%NEWCASTLE@MIT-MULTICS
post : Computing Laboratory, U of Newcastle upon Tyne, U.K.
+44 - 632 - 329233 xtn 212suitti@pur-phy.UUCP (Stephen K. Uitti) (05/15/84)
You added some optimal code to a PDP 11/45 program and it slowed down in system time. One of the things that can happen to a machine with a small address space is that you can run out of data space. In this case, it may be that stdio can't malloc more space for a new buffer. If this happens, it silently doesn't bother buffering. You get single character writes, that is, one sys call per character. Sometimes this will increase your user time two. This shouldn't happen if you compile with split instruction & data (which, if memory serves, is available on an 11/45). We have this kind of problem from time to time with "vnews" on our 11/44. The only other thing I can think of is that you do more swapping with a bigger processes (not a problem on 11's with > 1 Meg of RAM). This is unlikely for a small change. Stephen Uitti (Purdue physics site manager) UUCP: pur-ee!Physics:suitti, purdue!Physics:suitti INTERNET: suitti @ pur-phy.UUCP