mrk@gvgspd.GVG.TEK.COM (Michael R. Kesti) (02/08/89)
I have found that my 3b1's real time clock gains about a minute per week, and
was wondering if any of you hardware types out there might be able to steer
me toward a trim cap or something to correct this annoying, if not monumental,
problem.
Thanks.
--
============================================================================
Michael Kesti Grass Valley Group, Inc. | "Like one and one don't make two,
@gvgspd.GVG.TEK.COM | one and one make one."
!tektronix!gvgpsa!gvgspd!mrk | - The Who, Bargaingmark@ihlpf.ATT.COM (Stewart) (02/10/89)
In article <671@gvgspd.GVG.TEK.COM>, mrk@gvgspd.GVG.TEK.COM (Michael R. Kesti) writes: > I have found that my 3b1's real time clock gains about a minute per week, and > was wondering if any of you hardware types out there might be able to steer > me toward a trim cap or something to correct this annoying, if not monumental, Actually, a simpler way to do this (my opinion) is to just look in crontab and modify the job that updates the display and have it reset the time. Write a simple program that takes the time you type in at one-week or even one-month intervals that you consider correct and calculates the deviation of the date stored over that period. In other words, you type in a time, program checks if it agrees, and if not, checks the last time it was updated (timestamp on a file you created at the last update) and figures the percentage deviation. Putting this percentage into a file, modify the crontab file to not only update the display, but to update the time setting by this percentage each time, or a separate entry to fudge it every day or week or so. This has the advantage of being dynamic and correcting for things like thermal fluctuation (I don't know how significant that is on the UNIX-PC). I have found that all the UNIX-PCs I know about have positive deviations. Do others find that's true? Maybe they run hot? - Mark G. Mark Stewart ATT_BTL, Naperville, Ill. ix1g266 ihlpq!gms (312)979-0914
kirkaas@oahu.cs.ucla.edu (paul kirkaas) (02/10/89)
In article <671@gvgspd.GVG.TEK.COM> mrk@gvgspd.GVG.TEK.COM (Michael R. Kesti) writes: >I have found that my 3b1's real time clock gains about a minute per week, and >was wondering if any of you hardware types out there might be able to steer >me toward a trim cap or something to correct this annoying, if not monumental, >problem. How about just running a cron daemon once a week to roll back your clock by a minute? It's not pretty but it might do the trick. (I guess you would want to be careful about how you go about it -- if your program runs at 12:00 & sets the clock back to 11:59, you might get a nasty loop... Maybe let it sleep for a couple of minutes first?) Paul Kirkaas kirkaas@cs.ucla.edu
lenny@icus.islp.ny.us (Lenny Tropiano) (02/10/89)
In article <671@gvgspd.GVG.TEK.COM> mrk@gvgspd.GVG.TEK.COM (Michael R. Kesti) writes: |>I have found that my 3b1's real time clock gains about a minute per week, and |>was wondering if any of you hardware types out there might be able to steer |>me toward a trim cap or something to correct this annoying, if not monumental, |>problem. |> |>Thanks. |> I'm not sure why the UNIX pc software clock seems to mindlessly speed up. It happens here pretty regularly. I've seen it elsewhere, but I've also seen it where it runs perfectly. In the stock /usr/lib/crontab there is an entry: 3 3 * * 0 /bin/su root % /etc/clockupd.wk > /dev/null #sccs "@(#)fndetc:clockupd.wk 1.7" # Write to the hardware clock every Sunday morning to accomodate # synchronization of time between s/w and h/w clock in case day light # saving time is being used. Wait a minute to prevent recursion. # Note: backslash needed to avoid SCCS conflict sleep 60 date `date +%m%d%H\%M` ... Which is run Sunday at 3:03am ... it basically get's the time, and then sets it back... I have a feeling that this set's the clock ahead more often than not. The reason for sleeping, as they explain is to prevent the time from going back one minute and running this script over and over from the cron facility. This is the problem with the program that someone posted (fixrtc.c) a while back... It could actually put the time back in the past and will run the program over and over and over ... The "date(1)" command has an option "-" that is explain in the manual as: date - sets the system time from the real time clock This is done on bootup in the /etc/rc file. I run periodically here manually a "date ; date - ; date" to see what the difference in the hardware and software clocks are ... and to reset the software clock. I don't have an automatic feature for this right now, maybe someone can suggest something more reliable. Maybe I can write something with my Voice Power board to call up the Recorded Time message, do some speech recognition, and set the time ... I guess not, it's too hardware dependent :-) -Lenny -- Lenny Tropiano ICUS Software Systems [w] +1 (516) 582-5525 lenny@icus.islp.ny.us Telex; 154232428 ICUS [h] +1 (516) 968-8576 {talcott,decuac,boulder,hombre,pacbell,sbcs}!icus!lenny attmail!icus!lenny ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752
ralph@jolnet.ORPK.IL.US (Ralph Allas Jr) (02/10/89)
In article <671@gvgspd.GVG.TEK.COM> mrk@gvgspd.GVG.TEK.COM (Michael R. Kesti) writes: >I have found that my 3b1's real time clock gains about a minute per week, and >was wondering if any of you hardware types out there might be able to steer >me toward a trim cap or something to correct this annoying, if not monumental, >problem. > >Thanks. > >-- >============================================================================ >Michael Kesti Grass Valley Group, Inc. | "Like one and one don't make two, > @gvgspd.GVG.TEK.COM | one and one make one." > !tektronix!gvgpsa!gvgspd!mrk | - The Who, Bargain On my Unix-pc, there is a file /etc/clockupd.wk that supposedly takes care of that problem with the clock. I never leave my machine on for a week at a time, so I haven't yet noticed if it actually is off by a minute. If this file does exist on your machine, then there should also be an entry in /usr/lib/crontab that looks like this: 0 3 * * * 0 /bin/su root % /etc/clockupd.wk > /dev/null This will make the /etc/clockupd.wk run every sunday at 3:00am. Now, I don't know exactly what this file will do, but this is what it looks like. (maybe it is the reason the machine is off a minute after a week) #sccs "@(#)fndetc:clockupd.wk 1.7" # Write to the hardware clock every Sunday morning to accomodate # synchronization of time between s/w and h/w clock in case day light # saving time is being used. Wait a minute to prevent recursion. # Note: backslash needed to avoid SCCS conflict sleep 60 date `date +%m%d%H\%M` I hope this helps you in some way... -Ralph
wtm@neoucom.UUCP (Bill Mayhew) (02/11/89)
It seems to be an endemic phenomenon among Unix PCs that the kernel
gains time at the rate of about a minute per week. It sort of
louses up one's uucp schedule on a busy machine after a couple of
weeks.
What is interesting is that the battery-backed RTC chip seems to
keep quite good time. /etc/clockupd.wk is run from the crontab
every Sunday morning at 3:00 AM, thus ensuring that that the RTC
chip accruately relfects the kernel's incorrect notion of time;
keeping a reboot from restoring correct time.
In actuality, the clockupd.wk is supposed to make sure that the RTC
chip gets switched over to daylight savings time, as the kernel is
smart enough to know about savings time, but the RTC chip isn't.
BUT... there is a syslocal (2) call that allows you to read the RTC
chip. What I do is read the chip clock on Wednesdays and Sundays
at midnight, waiting until the seconds are at 00, then I execl
/bin/date to set the kernel and (also unavoidably) the RTC chip.
The RTC chip probably loses 50 to 100 mS per invokation of my
program, but that is nothing compared to the 1 minute/week that the
kernel gains!
I'll attach a very quick 'n dirty c program I wrote that
accomplishes the fix. Note that I busy-wait for the RTC to come
around to 00, but what the heck, it's only about two minutes a
week!
------------------- cut here for fixtime.c ----------------------
/********************************************
* fixtime.c *
* Bill Mayhew wtm@impulse.UUCP Jan. 1989 *
* *
* Target machine: AT&T Unix PC / 7300 *
* Target O/S: Unix relase 3.51 *
* *
* This program should be compiled and run *
* from your crontab biweekly (at 00:01?) *
* in order to keep the kernel's notion of *
* time in sync with the rtc battery clock *
* chip. A 60 second sleep is included at *
* start-up to avoid recursion of crontab *
* re-read. *
********************************************/
#include <stdio.h>
#include <sys/syslocal.h>
#include <sys/rtc.h>
main(argc,argv)
char *argv[];
int argc;
{
struct rtc now;
char sbuf[16];
/* avoid possible recursive crontab activations */
sleep(60);
/* since /bin/date ignores secs, hang around 'til 00 */
do {
syslocal(SYSL_RDRTC,&now);
}
while ( now.sec10 | now.sec1 );
sprintf(sbuf,"%1d%1d%1d%1d%1d%1d%1d%1d\0",
now.mon10,now.mon1,now.day10,now.day1,now.hr10,
now.hr1,now.min10,now.min1);
execl("/bin/date","/bin/date", sbuf,0);
/* can only reach this code if execl failed; most likely
because /bin/date is screwed up for some reason */
fprintf(stderr,"%s: failed to execl(/bin/date).\n",argv[0]);
return(-1);
}ebh@argon.UUCP (Ed Horch) (02/13/89)
In article <600@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: >[stuff about 3B1 clock] > >Maybe I can write something with my Voice Power board to call up >the Recorded Time message, do some speech recognition, and set the >time ... I guess not, it's too hardware dependent :-) There are several 300/1200bps dial-up "time broadcast" services around, with varying levels of sophistication, a couple of which work quite nicely for automated clock setting. Send me mail for details. -Ed
jon@jonlab.UUCP (Jon H. LaBadie) (02/13/89)
In article <600@icus.islp.ny.us>, lenny@icus.islp.ny.us (Lenny Tropiano) writes: > Maybe I can write something with my Voice Power board to call up > the Recorded Time message, do some speech recognition, and set the > time ... I guess not, it's too hardware dependent :-) > There was a posting to comp.sources.misc, or alt.sources some 6 - 9 months ago. As it was Xenix based, it did not use the VP board. Rather than using the call the local recorded time message, it called the National Bureau of Standards atomic clock (I think in West VA) to get the REAL time and set the system clock. Anyone work on this program to adapt it to the UPC? I played briefly, but it had too many xenix'isms for me. -- Jon LaBadie {att, princeton, bcr}!jonlab!jon {att, attmail, bcr}!auxnj!jon
ralph@rtech.rtech.com (Ralph Harnden: I don't wanna badger you (ext3430)) (02/15/89)
In article <631@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: ... >There was a posting to comp.sources.misc, or alt.sources some 6 - 9 >months ago. As it was Xenix based, it did not use the VP board. > >Rather than using the call the local recorded time message, it called >the National Bureau of Standards atomic clock (I think in West VA) to >get the REAL time and set the system clock. > Rick Kimball posted ``usnotime'' to unix-pc.sources on 20-Nov-88. This program calls the US Naval Observatory (in DC?), and sets the current time. Works great on my unix-pc. (Thanks, Rick!) Email me at the address below if you want me to send you a copy.... -- "People will do anything for a potato" {amdahl, mtxinu, pacbell, sun}!rtech!gusano!ralph ralph%gusano@rtech.com
todd@ivucsb.UUCP (Todd Day) (02/15/89)
In article <1497@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes:
~It seems to be an endemic phenomenon among Unix PCs that the kernel
~gains time at the rate of about a minute per week.
I have a program that calls a Navy cesium clock in Washington, D. C.
I set it up in my cron so it calls on the 15th of each month. It
only costs me 16 cents per call at night, and I'm in California.
Anyway, this software updates the internal clock, so using this
with the previous posted program that syncs the software clock on
the internal clock would keep your UNIXPC current fairly well.
If anyone wants a copy of this program, I'll email to you. It's
fairly short.
Todd Day | ..!pyramid!nessus!ivucsb!todd | todd@ivucsb.UUCP
^^^^^^ new! ^^^^^^^^^^^ maybe?gmark@ihlpf.ATT.COM (Stewart) (02/15/89)
In article <2668@rtech.rtech.com>, ralph@rtech.rtech.com (Ralph Harnden: I don't wanna badger you (ext3430)) writes: > time. Works great on my unix-pc. (Thanks, Rick!) Email me at the > address below if you want me to send you a copy.... I sure do! I'll send a potato, if you'd like. - Mark G. Mark Stewart ATT_BTL, Naperville, Ill. ix1g266 ihlpq!gms (312)979-0914 (please include phone for response)
ralph@rtech.rtech.com (Ralph Harnden: I don't wanna badger you (ext3430)) (02/21/89)
In article <7704@ihlpf.ATT.COM> gmark@ihlpf.ATT.COM (Stewart) writes: >In article <2668@rtech.rtech.com>, ralph@rtech.rtech.com (I) wrote: >> time. Works great on my unix-pc. (Thanks, Rick!) Email me at the >> address below if you want me to send you a copy.... > >I sure do! I'll send a potato, if you'd like. I received over 20 requests for this package (usnotime). I don't need that many potatoes! Unless I hear otherwise, I will repost the article containing this program to unix-pc.sources on 2/27/89. It's about 8K. Let me know if this is a gross violation of netiquitte, or if those who responded did so because they don't get unix-pc.sources. -- "People will do anything for a potato" {amdahl, mtxinu, pacbell, sun}!rtech!gusano!ralph ralph%gusano@rtech.com