[9fans] trace.c

[9fans] trace.c

[mirtchov]

trace.c came with the Jan 22 pull, but what is it?  it does show
somewhat interesting pictures and tells me how much certain processes
have been using the CPU, but without a man page the mind boggles :)

Re: [9fans] trace.c

[Peter Bosch]

> trace.c came with the Jan 22 pull, but what is it?  it does show
> somewhat interesting pictures and tells me how much certain processes
> have been using the CPU, but without a man page the mind boggles :)

trace shows the kernel scheduling actions and when interrupts
occur.  it reads scheduling events from /proc/trace (unfortunately
binary format only).  the definition of a trace event can be found
in /sys/include/trace.h.

to switch on tracing:

	echo traceon > /proc/<pid>/ctl

to switch it off again:

	echo traceoff > /proc/<pid>/ctl

when real-time processes are used it also shows you the release
times and deadlines of processes.

'q'	quits trace
'+'	zooms in
'-'	zooms out
'p'	pauses trace

(hmm, i guess the above _is_ the man page ;-)).


peter.

Re: [9fans] trace.c

[Skip Tavakkolian]

> (hmm, i guess the above _is_ the man page ;-)).

Also realtime(3) is not there.

BTW, I played with it when it first appeared (2002?) and couldn't
work it right, probably due to my incorrect understanding.  I
was trying to write a deterministic cat for copying CD audio files to
/dev/audio on a slow machine (K6-166Mhz).  Regular cat results in a
periodic chop, which I assumed (wild guess more like it) was buffer
underrun.

I think there was an example in the manpage too but a few more would
have been nice.

Anyhow, here is the rtcat.c which I couldn't make work. I don't remember
a thing about the details now.

------------------ rtcat.c --- DOESN'T WORK -------------
#include <u.h>
#include <libc.h>

char *	T = "10s";	/* the period between releases */
char *	D = "5s";	/* deadline before we must start (within T) */
char *	C = "1.5s";	/* time we have to do our work */
int		verbose, debug, tset, dset, cset;
char *clonedev = "#R/realtime/clone";

/*
 we've got to read /dev/volume and look for speed attribute.
 then we read the /dev/audiostat to get the buffer size for causing
 DMA. Then we use this formula to calculate the period (T) for
 this function:  Ex. 'speed 44100' would yeild:
	T = 1 ÷ (($speed × 16) ÷ ((1024 × 8))  OR 1 ÷ (($speed × 2) ÷ 1024))
	C = How long to run?
	D = T - C
*/
void
rtcat(int f, char *s)
{
	char buf[44100 * 2];		/* bytes: actually (44100×16)÷8  */
	long n;

	int fd;

	if ((fd = open(clonedev, ORDWR)) < 0)
		sysfatal("%s: %r", clonedev);
	if (fprint(fd, "T=%s D=%s C=%s  procs=%d resources= admit", T,D,C,getpid()) < 0)
		sysfatal("%s: admit: %r", clonedev);
	for (;;) {
		if ((n=read(f, buf, (long)sizeof buf))>0) {
			if(write(1, buf, n)!=n)
				sysfatal("write error copying %s: %r", s);
			if (fprint(fd, "yield") < 0)
				sysfatal("%s: yield: %r", clonedev);
		} else if(n < 0) {
			sysfatal("error reading %s: %r", s);
		} else {
			break;
		}
	}

	if (fprint(fd, "remove") < 0)
		sysfatal("%s: remove: %r", clonedev);
	close(fd);
}

static void
usage(void)
{
	fprint(2, "Usage: %s [-T period] [-D deadline] [-C cost] [-v]\n", argv0);
	exits(nil);
}

void
main(int argc, char *argv[])
{
	int f, i;

/*
	ARGBEGIN {
	case 'T':
		T = EARGF(usage());
		tset++;
		break;
	case 'D':
		D = EARGF(usage());
		dset++;
		break;
	case 'C':
		C = EARGF(usage());
		cset++;
		break;
	case 'v':
		verbose++;
		break;
	case 'd':
		debug++;
		break;
	default:
		usage();
	}
	ARGEND;
	if (tset && !dset) D = T;
*/

	argv0 = "rtcat";
	if(argc == 1)
		rtcat(0, "<stdin>");
	else for(i=1; i<argc; i++) {
		f = open(argv[i], OREAD);
		if(f < 0)
			sysfatal("can't open %s: %r", argv[i]);
		else{
			rtcat(f, argv[i]);
			close(f);
		}
	}
	exits(0);
}

Re: [9fans] trace.c

[Bruce Ellis]

sorry, it's hard to get a dinosaur to write a cd,
give it all the cpu ... still no good.  there are
many > 1G P3s at the local hock shop for
a few hunge..

> was trying to write a deterministic cat for copying CD audio files to
> /dev/audio on a slow machine (K6-166Mhz).  Regular cat results in a

Re: [9fans] trace.c

[boyd, rounin]

> sorry, it's hard to get a dinosaur to write a cd,
> give it all the cpu ... still no good.  there are
> many > 1G P3s at the local hock shop for
> a few hunge..
>
> > was trying to write a deterministic cat for copying CD audio files to
> > /dev/audio on a slow machine (K6-166Mhz).  Regular cat results in a

doesn't the word 'underrun' spring to mind?

Re: [9fans] trace.c

[Sape Mullender]

> Also realtime(3) is not there.

This has been replaced by proc(4)

Re: [9fans] trace.c

[Rob Pike]

On Wednesday, January 28, 2004, at 05:00 AM, Sape Mullender wrote:

>> Also realtime(3) is not there.
>
> This has been replaced by proc(4)

is there a proc(4)?  or did you mean proc(3).

i can't check because yet again i am getting inexplicable auth errors
connecting to sources when auth/debug says it should work.

-rob

Re: [9fans] trace.c

[Sape Mullender]

>>> Also realtime(3) is not there.
>>
>> This has been replaced by proc(4)
>
> is there a proc(4)?  or did you mean proc(3).

I did.  Sorry.

Re: [9fans] trace.c

[Geoff Collyer]

> > Also realtime(3) is not there.
> This has been replaced by proc(4)
> > is there a proc(4)?  or did you mean proc(3).
> I did.  Sorry.

Then rtstats(1) needs to be updated to cite proc(3) instead of
realtime(3).

Re: [9fans] trace.c

[Peter Bosch]

>> > Also realtime(3) is not there.
>> This has been replaced by proc(4)
>> > is there a proc(4)?  or did you mean proc(3).
>> I did.  Sorry.
>
> Then rtstats(1) needs to be updated to cite proc(3) instead of
> realtime(3).

trace replaces rtstats.

Re: [9fans] trace.c

[Geoff Collyer]

[-- Attachment #1: Type: text/plain, Size: 86 bytes --]

Greeeeaat!  Then rtstats(1) needs to be retracted and trace(1) needs
to be created.

[-- Attachment #2: Type: message/rfc822, Size: 2174 bytes --]

From: Peter Bosch <pb@research.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] trace.c
Date: Wed, 28 Jan 2004 20:56:36 -0500
Message-ID: <b605a4b07ddf57ace9855a96171086e7@plan9.bell-labs.com>

>> > Also realtime(3) is not there.
>> This has been replaced by proc(4)
>> > is there a proc(4)?  or did you mean proc(3).
>> I did.  Sorry.
>
> Then rtstats(1) needs to be updated to cite proc(3) instead of
> realtime(3).

trace replaces rtstats.