jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) (02/28/91)
I know that in weeks past, there was a big string on how to get an
accurate timer to deal with times less than one second. Here's a
trick question - does the hardware keep track of time less than one
second in duration? A VAX (and I know that a 3B1 is *no* vax :-)
keeps a register that increments every microsecond. Is there some
sort of hidden register like that on our machine?
Thanks in advance!
j
--
Jeffrey L. Bromberger
System Operator---City College of New York---Science Computing Facility
jeffrey@sci.ccny.cuny.edu jeffrey@ccnysci.BITNET
Anywhere!{cmcl2,philabs,phri}!ccnysci!jeffreydlb5404@tamuts.tamu.edu (Daryl Biberdorf) (02/28/91)
In article <1991Feb27.195148.4122@sci.ccny.cuny.edu> jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) writes: >I know that in weeks past, there was a big string on how to get an >accurate timer to deal with times less than one second. Here's a >trick question - does the hardware keep track of time less than one >second in duration? A VAX (and I know that a 3B1 is *no* vax :-) >keeps a register that increments every microsecond. Is there some >sort of hidden register like that on our machine? I'd be interested in knowing this information myself. I just got done with an assignment for one of my classes where the prof wanted us to time some procedures and print the results out to hundredths of a second. I know that the gettimeofday() call modifies one of the two structures passed to it to contain both seconds and microseconds. If this is a BSD thing (and I think it is), has anyone written anything similar for the 3b1/System V world? --Daryl Biberdorf, dlb5404@{rigel,tamuts}.tamu.edu Texas A&M University
jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) (03/01/91)
In article <12768@helios.TAMU.EDU> dlb5404@tamuts.tamu.edu (Daryl Biberdorf) writes: >In article <1991Feb27.195148.4122@sci.ccny.cuny.edu> jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) writes: >>[stuff about usecs.] > >I know that the gettimeofday() call modifies one of the two structures >passed to it to contain both seconds and microseconds. If this is a >BSD thing (and I think it is), has anyone written anything similar >for the 3b1/System V world? For my self-assigned task of porting over the BSD timed (time control daemon), I wrote gettimeofday, setttimeofday, and I am beating on adjtime. That's great for up-to-one-second control. But it's a bummer being only able to adjust time to the next second. Is the Toshiba RTC chip common enough for anyone to know anything about it? Maybe the RTC doesn't know that much, but does the 68010? BTW: which clock is the one that gets carried away, the RTC or the software clock? Another thing that seems fishy regarding the WIN/TCP software. Timed uses ethernet ICMP TIMESTAMP packets to tell how far apart the system clocks are. Well, when you do that for any machine on our local network, you get: % repeat 10 timedc clockdiff cel time on cel.ccny.cuny.edu is 15 ms. ahead of time on sci time on cel.ccny.cuny.edu is 16 ms. ahead of time on sci time on cel.ccny.cuny.edu is 16 ms. ahead of time on sci time on cel.ccny.cuny.edu is 15 ms. ahead of time on sci time on cel.ccny.cuny.edu is 15 ms. ahead of time on sci time on cel.ccny.cuny.edu is 15 ms. ahead of time on sci time on cel.ccny.cuny.edu is 16 ms. ahead of time on sci time on cel.ccny.cuny.edu is 15 ms. ahead of time on sci time on cel.ccny.cuny.edu is 15 ms. ahead of time on sci time on cel.ccny.cuny.edu is 15 ms. ahead of time on sci Now, when you do the same for a 3b1 with version 1.4 of LOSE/TCP (it sure ain't WIN :-), here's what comes out: % repeat 10 timedc clockdiff notvax time on notvax.ccny.cuny.edu is 4491 ms. ahead of time on sci time on notvax.ccny.cuny.edu is 5006 ms. ahead of time on sci time on notvax.ccny.cuny.edu is 4538 ms. ahead of time on sci time on notvax.ccny.cuny.edu is 5107 ms. ahead of time on sci time on notvax.ccny.cuny.edu is 4275 ms. ahead of time on sci time on notvax.ccny.cuny.edu is 4456 ms. ahead of time on sci time on notvax.ccny.cuny.edu is 4994 ms. ahead of time on sci time on notvax.ccny.cuny.edu is 4490 ms. ahead of time on sci time on notvax.ccny.cuny.edu is 4865 ms. ahead of time on sci time on notvax.ccny.cuny.edu is 4976 ms. ahead of time on sci Now, the time difference is OK, the daemon isn't up and running yet. But! Look at the variability! Our Celerity (and Vaxen) differ by at most 1 millisecond. The *range* for the 3b1 is 832 millisecs. And that's when the machine is IDLE! What gives here? Is the whole ethernet driver just a kludge?!? One day, when I get done writing my thesis, I'll get around to rewriting it. j -- Jeffrey L. Bromberger System Operator---City College of New York---Science Computing Facility jeffrey@sci.ccny.cuny.edu jeffrey@ccnysci.BITNET Anywhere!{cmcl2,philabs,phri}!ccnysci!jeffrey
dnichols@ceilidh.beartrack.com (DoN Nichols) (03/01/91)
In article <1991Feb28.160950.7042@sci.ccny.cuny.edu> jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) writes: [ ... ] >Another thing that seems fishy regarding the WIN/TCP software. Timed >uses ethernet ICMP TIMESTAMP packets to tell how far apart the system >clocks are. Well, when you do that for any machine on our local >network, you get: >% repeat 10 timedc clockdiff cel [ ... ] >Now, when you do the same for a 3b1 with version 1.4 of LOSE/TCP (it >sure ain't WIN :-), here's what comes out: > >% repeat 10 timedc clockdiff notvax [ ... ] >Now, the time difference is OK, the daemon isn't up and running yet. >But! Look at the variability! Our Celerity (and Vaxen) differ by at >most 1 millisecond. The *range* for the 3b1 is 832 millisecs. And >that's when the machine is IDLE! What gives here? Is the whole >ethernet driver just a kludge?!? One day, when I get done writing my >thesis, I'll get around to rewriting it. The resolution of the clock is 1 second, and the timestamps are derived from the system clock. If you ran it long enough, you'd get a 999mS range. Till we get some extra hardware, a counter run from the 10MHZ system clock, divided down, and readable by the system, we aren't going to get much more resolution unless we dedicate LOTS of cpu cycles to it. As to the hardware, this might be another thing to include in the super combo card. (Of course, we'd need to modify the kernel to access it. :-) Is there a statute of limitations on the prohibition from disassembling the kernel ? :-) Perhaps the counter could be put on a new ethernet board, since that is where we need the calls. Can we add system calls that are serviced by a loadable device driver? We can but hope! DoN. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: <dnichols@ceilidh.beartrack.com> --- Black Holes are where God is dividing by zero ---
thad@public.BTR.COM (Thaddeus P. Floryan) (03/02/91)
In article <1991Mar1.040542.14965@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (DoN Nichols) writes: >[...] > The resolution of the clock is 1 second, and the timestamps are >derived from the system clock. If you ran it long enough, you'd get a 999mS >range. Till we get some extra hardware, a counter run from the 10MHZ system >clock, divided down, and readable by the system, we aren't going to get much >more resolution unless we dedicate LOTS of cpu cycles to it. Actually, there IS a 1/60 sec timer on board, and it's the one used by the "time" command and also the one I used for the BSD-equivalent gettimeofday() I posted last year for use with some of the BSD "Tahoe" networking software suite I ported to the 3B1. And, though I don't have the data sheets at hand, I "believe" the RTC could resolve to better than 1 second but there are no "hooks" in the 3B1 to allow access. I use a similar clock in one of my own products for datestamping "events". And if you want real precision, I have a Heath GC-1000 WWV clock connected to one of my serial ports and that sucker provides a very accurate time reference traceable to the NIST (formerly NBS) via "aethernet" (radio :-) along with another output at PRECISELY 3.6 MHz which could be divided-down to provide 0.000000277 second accuracy if you're concerned about leaving the popcorn in the microwave too long. :-) Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
jon@jonlab.UUCP (Jon H. LaBadie) (03/05/91)
In article <1991Feb27.195148.4122@sci.ccny.cuny.edu>, jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) writes: > I know that in weeks past, there was a big string on how to get an > accurate timer to deal with times less than one second. Here's a > trick question - does the hardware keep track of time less than one > second in duration? A VAX (and I know that a 3B1 is *no* vax :-) > keeps a register that increments every microsecond. Is there some > sort of hidden register like that on our machine? Though I know of none, there may be such a register; the 68000 micro- processor mimics much of the VAX architecture. However, there is access to a parameter that is the number of "ticks" since system boot. Ticks are defined in sys/param.h as "HZ" to be number of clock ticks per second. Many things use HZ. For example, the cursor is defined to be on for 2 HZ and off for 4 HZ. Process accounting is logged each clock tick, not each second. On the 3B1, HZ is defined as 60 ticks per second. The access to the tick counter is a system call times(2). Its primary purpose is to report the cpu usage of a process and its children (it fills a 4 member struct tms with this information). However, assuming no errors, it also returns the tick count. So, if before timing some event you save the return value of times(2), and determine again the return value or times(2) upon completion of the event, the difference is the number of clock ticks between start and end of event. NOTE, there is a considerable element of uncertainty here for small measured times due to system call overhead and system load. Given the granularity of 1/60th of a second, use of clock ticks to report times to the 1/100th (as is done by timex(1) and the ksh builtin time) is rather nebulous. A short program demonstrating the use of times(2) in this context and a portion of the programs output follow. /* Sample program */ #include <stdio.h> #include <sys/types.h> #include <sys/times.h> #include <sys/param.h> main() { time_t start_tms, cur_tms, dif_tms; struct tms tms; /* needed, but data is unused */ double elapsed; start_tms = times(&tms); while(1) { /* process til some event */ cur_tms = times(&tms); dif_tms = cur_tms - start_tms; elapsed = dif_tms / (double) HZ; printf("Timer: %10ld, %10ld, %8ld, %10.2f\n", start_tms, cur_tms, dif_tms, elapsed); } } /* Portion of sample output (run while news was expiring ) Timer: 15571070, 15571279, 209, 3.48 Timer: 15571070, 15571290, 220, 3.67 Timer: 15571070, 15571290, 220, 3.67 Timer: 15571070, 15571293, 223, 3.72 Timer: 15571070, 15571293, 223, 3.72 Timer: 15571070, 15571296, 226, 3.77 Timer: 15571070, 15571297, 227, 3.78 Timer: 15571070, 15571297, 227, 3.78 Timer: 15571070, 15571298, 228, 3.80 Timer: 15571070, 15571298, 228, 3.80 Timer: 15571070, 15571302, 232, 3.87 Timer: 15571070, 15571302, 232, 3.87 Timer: 15571070, 15571303, 233, 3.88 Timer: 15571070, 15571303, 233, 3.88 Timer: 15571070, 15571304, 234, 3.90 Timer: 15571070, 15571307, 237, 3.95 Timer: 15571070, 15571307, 237, 3.95 Timer: 15571070, 15571308, 238, 3.97 Timer: 15571070, 15571308, 238, 3.97 */ -- Jon LaBadie {att, princeton, bcr, attmail!auxnj}!jonlab!jon
agodwin@acorn.co.uk (Adrian Godwin) (03/06/91)
In article <924@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: >In article <1991Feb27.195148.4122@sci.ccny.cuny.edu>, jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) writes: >> I know that in weeks past, there was a big string on how to get an >> accurate timer to deal with times less than one second. Here's a I vaguely remember seeing this go by and of course, now it's gone, I want it :-(. I need to perform something like the following code, under CTIX 5.1 on a mini-20. This is part of ka9q's tcp/ip code, and wants its parent to be woken up at frequent intervals. I think it's normally set to 200ms. My current hack for this polls times(), which is far from satisfactory. Is this OS sufficiently closely related to the 3b1's that the same ideas can be used ? If so, I'd appreciate a summary of those postings (by mail). I think one of the postings suggested using a device driver to produce some sort of timing mark. I don't have any of the appropriate documentation for writing a device driver under CTIX - again, is the 3b1 documentation Thad was distributing at all relevant to my system ? Here's the code distributed for systems like SVR3 : parent = getppid(); timeout = atoi(argv[1]); fds.fd = -1; while (1) { if (poll(&fds,1,timeout) == -1) { perror("poll"); exit(1); } if (kill(parent,SIGALRM) == -1) exit(0); /* parent exited? */ } -adrian -- -------------------------------------------------------------------------- Adrian Godwin (agodwin@acorn.co.uk)
vince@tc.fluke.COM (Craig Johnson) (03/06/91)
In article <1988@public.BTR.COM>, thad@public.BTR.COM (Thaddeus P. Floryan) writes: > And, though I don't have the data sheets at hand, I "believe" the RTC could > resolve to better than 1 second but there are no "hooks" in the 3B1 to allow > access. I use a similar clock in one of my own products for datestamping > "events". Sorry Thad. I checked the Toshiba data sheet and found that there are only readable registers allowing resolution to 1 second. There is a programmable output that can be made to run at greater than 1 Hz rates, but I didn't see a way to monitor the state of the output from within the RTC chip. I haven't checked my schematic to see if that output is actually used anywhere in the Unix PC. I once had a look at some early schematics that showed an input register that tracked the value of the video display address register. They apparently had ideas about implementing a light pen. That could have been useful for doing some fine resolution timing. Too bad though, apparently this register never got implemented in actual production units since the address it was at instead got used for the P5.1 upgrade. --- Craig V. Johnson ...!fluke!vince John Fluke Mfg. Co. or Everett, WA vince@tc.fluke.com
jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) (03/07/91)
In article <924@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: >However, there is access to a parameter that is the number of "ticks" >since system boot. Ticks are defined in sys/param.h as "HZ" to be >number of clock ticks per second. Many things use HZ. For example, >the cursor is defined to be on for 2 HZ and off for 4 HZ. Process >accounting is logged each clock tick, not each second. > >On the 3B1, HZ is defined as 60 ticks per second. Terrific, but this is a read-only sort of thing. If I wanted to implement a settimeofday(2) of adjtime(2) [my ultimate goal], I'd need to control this. But it really isn't nice to muck with the kernel's tick counter. What I'm really after is some way to adjust the 3b1's clock to something smaller than a second. Somehow, the LOSE/TCP code sends stuff out with useconds. All I'm after is a way to make a *software* clock move either faster or slower than the hardware one. Then, I'd set the hardware from the software. Assuming that this is done in one piece of high-interrupt-level kernel code, it should be prretty accurate. Remember that the software clock can drop interrupts, so by itself, the hardware clock is the real clock. But, Thad has told me that there is no way to use the RTC for any interval less than one second. Which means that the only chance I have of setting the time more accurately then the second is by playing with the software clock and back-feeding the hardware clock. I'm starting to get the feeling that without beating upon the hardware (to get better control over the clock), this issue is going to go nowhere. Why couldn't the designers have thought in a more general frame of mind? Time doesn't always move in seconds! j -- Jeffrey L. Bromberger System Operator---City College of New York---Science Computing Facility jeffrey@sci.ccny.cuny.edu jeffrey@ccnysci.BITNET Anywhere!{cmcl2,philabs,phri}!ccnysci!jeffrey
dold@mitisft.Convergent.COM (Clarence Dold) (03/09/91)
in article <1991Mar6.202858.17593@sci.ccny.cuny.edu>, jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) says: > tick counter. What I'm really after is some way to adjust the 3b1's > clock to something smaller than a second. Somehow, the LOSE/TCP code > sends stuff out with useconds. All I'm after is a way to make a *software* The tv_usec returned by gettimeofday() is either 0, or time() % 60 * 10000 neither of them is really usec, it just looks good. > itself, the hardware clock is the real clock. arguably true, but not very often... The RTC chip is like a wristwatch (except terribly inaccurate). The system time (software clock) looks at it's wristwatch when it wakes up in the morning (boot time script), and possibly from time to time throughout the day (via cron scripts). I stretched that analogy far enough :-) As far as my rapidly fading memory can recall, unless you do a "date -", the system clock is never adjusted to match the RTC. When you specify a new date with "date 0306123491", you set the system time, and drive that into the RTC. In fact, an stime() call by itself doesn't set the RTC, just the system. You must use syslocal(SYSL_WTRTC) to change the RTC, which 'date' does. SYSL_WTRTC is the name on later Convergent boxes, I forget what it is on the 3b1, but it's close. -- --- Clarence A Dold - dold@tsmiti.Convergent.COM ...pyramid!ctnews!tsmiti!dold
thad@public.BTR.COM (Thaddeus P. Floryan) (03/11/91)
In article <1991Mar5.193756.25135@tc.fluke.COM> vince@tc.fluke.COM (Craig Johnson) writes: >In article <1988@public.BTR.COM>, thad@public.BTR.COM (Thaddeus P. Floryan) writes: >> And, though I don't have the data sheets at hand, I "believe" the RTC could >> resolve to better than 1 second but there are no "hooks" in the 3B1 to allow >> access. I use a similar clock in one of my own products for datestamping >> "events". > >Sorry Thad. I checked the Toshiba data sheet and found that there are >only readable registers allowing resolution to 1 second. There is a ... Craig is correct; the "similar" chip about which I was thinking was made by SaRoNiX (Palo Alto CA) who sold that operation to Epson a little while back. Toshiba is definitely NOT Epson (yet :-) The "1/HZ" clock provides reasonable short-interval timing as is used by the times() call and which is used in my interpretation of the gettimeofday() which I posted last year; the main purpose was for timing ftp operations with better than the 1 second stats from the 1.4 WIN/3B package. Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
thad@public.BTR.COM (Thaddeus P. Floryan) (03/11/91)
In article <5578@acorn.co.uk> agodwin@acorn.co.uk (Adrian Godwin) writes: >[...] >I need to perform something like the following code, under CTIX 5.1 on a >mini-20. This is part of ka9q's tcp/ip code, and wants its parent to be >woken up at frequent intervals. I think it's normally set to 200ms. > >My current hack for this polls times(), which is far from satisfactory. > >Is this OS sufficiently closely related to the 3b1's that the same ideas >can be used ? Programs running under CTIX on the Miniframe (and its kissing cousin, the Motorola 6300 and 6350) run just fine on the 3B1 (at least everything I've tried to date) as long as no shared libraries are being used ... this really only affects executable binary transportability from the 3B1 to CTIX. >I think one of the postings suggested using a device driver to produce >some sort of timing mark. I don't have any of the appropriate documentation >for writing a device driver under CTIX - again, is the 3b1 documentation >Thad was distributing at all relevant to my system ? Some of the code samples "should be" relevant, but I don't have sufficient experience with device drivers to say "Yes" or "No". >Here's the code distributed for systems like SVR3 : .[...] > if (poll(&fds,1,timeout) == -1) { ^^^^ I don't see anything like "poll()" in the permuted index I have for the 3B1 as of 3.51 Sigh. Short duration (under 1 sec) timing on the 3B1 is a royal pain; I've been on-and-off over the past several months attempting to get a working "ping(1)" program working on the 3B1 based on the 4.3BSD stuff at uunet. Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]