bret@codonics.COM (Bret Orsburn) (12/14/89)
Here is a question for the Unix Wizards (Any of you left out there? :-) How coarse is the real-time base on *real* Unix machines? The gettimeofday function returns (in part) a microsecond resolution counter. The docs I have found so far indicate that this counter is really just bumped by the system tick interrupt at a 50-100 HZ rate. Is that a useful generalization? Are there any significant counter-examples? Some context: I am contributing to the design of a stand-alone system that will run some code ported from a Unix environment. This code uses the gettimeofday system call to derive a millisecond-resolution timestamp. If *real* Unix just bumps this counter 50-100 times per second, I can immediately recommend that behavior as a minimum system capability. I can then take steps to determine if there is any real benefit in exceeding this minimum capability. TIA, Wizards. -- ------------------- bret@codonics.com uunet!codonics!bret Bret Orsburn
chris@mimsy.umd.edu (Chris Torek) (12/15/89)
In article <598@codonics.COM> bret@codonics.COM (Bret Orsburn) writes: >The gettimeofday function returns (in part) a microsecond resolution counter. >The docs I have found so far indicate that this counter is really just bumped >by the system tick interrupt at a 50-100 HZ rate. Is that a useful >generalization? Are there any significant counter-examples? No, and yes (in that order): 4.3BSD on most VAXen, for instance. These have a 100 hz clock, but can read the countdown (acutally count-up) register to tell how long it has been since the last clock interrupt, and there is a routine called microtime() that calculates the time to the nearest microsecond or so. Of course, by the time the time has been calculated, it is wrong again. . . . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
leres@surf.ee.lbl.gov (Craig Leres) (01/04/90)
By the way, the Sparcstation's clock has a microsecond register; we were able to modify the nit code to take advantage of this when constructing the nit timestamp. While this is a vast improvement over the 20ms clock other Suns provide (10ms if you've hacked the kernel like me) it's still not perfect for network analysis. When packets arrive close together, you tend to be measuring the time it takes nit to process a packet instead of the inter-packet spacing. What we need is an ethernet interface that installs per-packet timestamps in hardware! Don't have any sun4c source so I haven't hacked gettimeofday() to use it yet. But I gave the nit enhancements to a buddy at Sun and he it was a good idea and would see about sticking it in SunOS. Craig