[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Slow kernel clock



On Wed, Jun 12, 2002 at 11:51:52PM -0500, Donald R. Spoon wrote:
> Seneca <seneca-cunningham@rogers.com> wrote:
> 
> > -snip- <
> >
> >I was wondering about how to get the system clock to match the hardware
> >clock when the system's time is >5 min slow. I can't use the NTP clients
> >because of a rather ignorant windoze proxy (determined by trial and
> >error), and I would prefer not to have to manually set the time every
> >day or so (hwclock --hctosys).
> >-snip- <
> 
> Here are some ramblings from a "confused" mind :)
[...bits about hwclock...] 
> Here are some strategies I would consider:
> 
> 1.  Use the existing /etc/init.d/hwclockfirst.sh script to keep the 
> System Clock in synch with your Hardware Clock rather than the way you 
> are currently doing it.  There are some cautions in the hwclock man 
> pages about doing this manually while the system is running.  This is 
> probably where I got in trouble, but using existing scripts written by 
> the "experts" would seem to be much safer <g>.  You should be able to 
> include this script in a CRON job...

I took a look at /etc/init.d/hwclockfirst.sh and it is similar to what I
am doing. The problem with a cron job is that it would run every 5
minutes, or whatever I set it to, and it would run then... when cron is
running. Sometimes I change to a cron-free runlevel so that heavy tasks
don't get slowed down by swapping (remember, my system is a
cron-operated alarmclock, and what makes it that is thrashing on cron
jobs). I'm not sure about adding another cron job to my tiny crontab of
one line. I also only want the system time to change whenever it is over
5 minutes off of the more accurate hardware clock.

> 2.  This is from my admittedly weak memory... so use accordingly <g>.  I 
> seem to recall that the NTPDATE "client" program would work without any 
> special ports being opened... specifically port 123.  The NTP server 
> program, OTOH, required this port to be opened.  It is possible that 
> your intervening M$ proxy would pass this un-noticed... dunno.  Worth a 
> shot if you have not tried it already.

I tried ntpdate about a week ago. I looked up a number of time-servers,
and I couldn't connect to any of them. The way it looks from my end is
that if the proxy isn't specifically configured to handle one type of
traffic, that type of traffic gets dropped. Its rather annoying really,
ports have been opened to allow some people to play games over the
internet, or to use stuff like KaZaa, but nothing to let me get the
time.

> 3.  Do some snooping of the network on your side of the M$ Proxy and see 
> if there happens to be a time-server available.  Many Universities and 
> local businesses (Banks??) have one for their "customers".  If one is 
> there, you could use the NTP  or NTPDATE programs on it and not worry 
> about the M$ Proxy.

I know what is on my side of the proxy (7 systems, 6 of which are
windoze). No time-server. Mostly people playing M$ games over the
network, and using stuff like KaZaa.

> 4. Bug your ISP to either offer a time service or allow you to access  a 
> public time server.

Bugging ISPs about time service isn't exactly highest on my list of
priorities. A slightly higher priority is their webmail interface. I
can't even login to it with my favoured browsers. I can type in my
username and my password, but it is impossible for me to push the login
button. I hate it when people require the use of a GUI browser.

> Just some thoughts... HTH.
Some of your thoughts were the same as mine.

-- 
Seneca
seneca-cunningham@rogers.com


-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: