*BSD News Article 73941


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!spool.mu.edu!sgigate.sgi.com!news.msfc.nasa.gov!elroy.jpl.nasa.gov!swrinde!cssun.mathcs.emory.edu!gatech!news.mathworks.com!nntp.primenet.com!news.cais.net!nntp.uio.no!nntp.uib.no!nntp-bergen.UNINETT.no!nntp-trd.UNINETT.no!not-for-mail
From: sthaug@nethelp.no (Steinar Haug)
Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc
Subject: Re: TCP latency
Date: 16 Jul 1996 20:43:03 GMT
Organization: Nethelp Consulting, Trondheim, Norway
Lines: 82
Message-ID: <4sgusn$4tr@verdi.nethelp.no>
References: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E7C0DD.41C67EA6@dyson.iquest.net>
	<4s8tcn$jsh@fido.asd.sgi.com> <31E80ACA.167EB0E7@dyson.iquest.net>
	<4sadde$qsv@linux.cs.Helsinki.FI> <31E9E3A7.41C67EA6@dyson.iquest.net>
	<4sefde$f0l@fido.asd.sgi.com> <s8hgr8nga9.fsf@sphinx.nuclecu.unam.mx>
NNTP-Posting-Host: trane.uninett.no
In-reply-to: Miguel de Icaza's message of 16 Jul 1996 14:34:38 -0500
Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:45462 comp.unix.bsd.netbsd.misc:4083 comp.unix.bsd.freebsd.misc:23763

[Miguel de Icaza]

|   Solaris seems like it has a special case for gettimeofday.  If they
|   don't have a special case, at least it is treated like it.  They got a
|   special system call just for this purpose. 
|   
|   Go to any Solaris 2.{4,5} and disassemble the gettimeofday routine.

Having a fast gettimeofday() is actually useful in lots of ways. I never
understood why gettimeofday() couldn't simply be reading a timeval which
was mapped into the process virtual address space. No muss, no fuss.

(Actually, in SunOS 4.1.x, for x>=2, you *almost* have that - due to an
error. See the enclosed posting from Greg Limes. I've made use of this
several times - it's (not surprisingly) considerably faster than a normal
gettimeofday().)

Steinar Haug, Nethelp consulting, sthaug@nethelp.no
----------------------------------------------------------------------
From: limes@fusim.Eng.Sun.COM (Greg Limes)
Subject: Re: [Q] fast hardware timer on SPARC SS10?
Date: 30 Jul 1993 03:14:41 GMT

kirk@zipimp.jpl.nasa.gov (Kirk Reinholtz) writes:

|Hi. I've got a performance tuning situation that would be more
|easily solved if I had access to a counter that incremented every
|microsecond or so. Silicon Graphics has such a thing that we've used
|to great advantage: you do a special system call to get the address
|and period of the counter, then mmap() at it, and then you've got
|it.

|Does anybody out there know if SS10/4* and 5* have such a thing?
|thanks!

Almost but not quite. Calls to "gettimeofday" will fill the timeofday
structure down to the microsecond, but the overhead of the call is
significant.

If you happen to be running SunOS 4.1.2 or 4.1.3 on a Sun-4m like the
4/600 or SS10, you *might* find a 64-bit counter that increments in bit
9 every half-microsecond, at some virtual address like 0xFD020000 ...
or it might be 0xFC020000, or maybe 0xFE020000; or it might not be
there. You might also find, if the system hasn't been running more than
about seven weeks or so, the following interesting property:

	double	*timer = (double *)0xFD020000;	/* address may be wrong */

	{
		double	t0, tn;
		...

		t0 = *timer;
		do_something(...);
		tn = *timer;
		printf("elapsed time: %f\n", tn - t0);

It is in fact a bug that this is visible in user space ... and it is a
bit if whimsy that the initial value makes the floatingpoint trick work
at all ... and of course this was not seen to be a desirable thing to
support, because it will not continue to work in future releases, nor
does it work on anything but the '600 series and maybe the SS10.
Consider it a playtoy that some silly engineer forgot to put away
before shipping the product.

Oh, if you get the wrong address, you won't hurt anything, your program
will just take a SIGSEGV. And you probably only want to read doublewords
>from that address; if you read two 32-bit words, you risk getting a carry
>from one to the other at just the wrong time.

Working out what to do if your system has been up for a long time
is up to you ... hint: it's really a 64-bit integer. Further hint: it's
weird becuase the counter ripplecarried into what the FP unit thinks
is the exponent, so maybe you don't need the first hint :O)

If you are running Solaris 2, I know there is *some* way to get a high
resolution timestamp from the system. I just don't yet know what it is.

On the other hand, if a MILLISECOND is all the precision you want, maybe
you won't particularly be worried about the time a "gettimeofday" takes.

-- Greg "silly me" Limes