Xref: utzoo comp.unix.wizards:23983 comp.unix.programmer:993 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!execu!sequoia!rpp386!jfh From: jfh@rpp386.cactus.org (John F Haugh II) Newsgroups: comp.unix.wizards,comp.unix.programmer Subject: Re: deamon help Message-ID: <19032@rpp386.cactus.org> Date: 6 Feb 91 13:29:16 GMT References: <594@edpmgt.UUCP> <2304@inews.intel.com> Reply-To: jfh@rpp386.cactus.org (John F Haugh II) Organization: Lone Star Cafe and BBS Service Lines: 50 X-Clever-Slogan: Recycle or Die. In article <2304@inews.intel.com> bhoughto@hopi.intel.com (Blair P. Houghton) writes: >In article bzs@world.std.com (Barry Shein) writes: >>For a problem like this I'll bet you a nickel crafting the whole thing >>in C using /dev/kmem etc will not be much faster than the above >>described script, and will take a week to get right instead of 30 minutes. > >Better, use popen(3) and top(1). Top usually gets the data >much faster than ps. Why? Who knows? Could be anything >from superior skills among public-domain software developers >to abuse of /dev/null. Hmmm. I'm half tempted to take that bet. One problem I envision with the PS approach is that the CPU resolution is to the full second, and there are many processes which lurk about in the background and don't use much more than a second in a days time. Here's the PS output from this system with those processes selected - UID PID PPID C STIME TTY TIME COMMAND root 30 1 0 Jan 24 ? 0:00 /etc/syslogd /usr/adm/syslog lp 35 1 0 Jan 24 ? 0:00 /usr/lib/lpsched I'd wager that it is fairly easy to write a program that would do a considerable amount of work and never record a single CPU tick. PER PROCESS USER AREA: USER ID's: uid: 0, gid: 0, real uid: 0, real gid: 0 PROCESS TIMES: user: 6, sys: 17, child user: 0, child sys: 0 PROCESS MISC: proc slot: 8, cntrl tty: maj(4) min(2) IPC: locks: unlocked FILE I/O: user addr: 25708343, file offset: 357, bytes: 0, segment: user, umask: 26, ulimit: 2097152 ACCOUNTING: command: syslogd, memory: 931552, type: fork start: Thu Jan 24 19:30:02 1991 OPEN FILES: file desc: 0 1 2 3 file slot: 9 9 9 8 This is most of the user structure for the "syslogd" process which I PS'd above. It has logged 23 ticks in 13 days of running, yet it at a minimum produces a log record once an hour. You can't log a fraction of a tick, so it would appear there is about a 1 in 13 chance of the hourly timestamp logging a tick. The implication of this is that a process which does work (even "does work every hour") may still log clock ticks so slowly that even after a month of furious light activity (interesting use of the word "furious" ;-), it still has yet to log a single full second of time. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.