9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] time stamps
@ 2000-06-13 13:38 arisawa
  0 siblings, 0 replies; 4+ messages in thread
From: arisawa @ 2000-06-13 13:38 UTC (permalink / raw)
  To: 9fans

Hello,

I said:
       >>The kernel says:
       >>ether8003: warning - 0xD0000 unavailable#IO: ....
And jmk replied:
>despite the warning does the card work?

Yes. I have confirmed just now. Thanks.

By the way, time stamps are something curious.

term% cd /sys/log
term% ls -l
a-rw-rw-rw- M 3 sys sys   0 Jun  8 00:23 auth
a-rw-rw-rw- M 3 sys sys   0 Jun  8 00:23 cs
a-rw-rw-rw- M 3 sys sys 174 Jun 14 06:44 dns
a-rw-rw-rw- M 3 sys sys   0 Jun  8 00:23 ftp
...
term% date; date -u
Tue Jun 13 21:59:52 JST 2000
Tue Jun 13 12:59:52 GMT 2000
term% cat dns
pc Jun 14 06:44:55 starting dns on 192.168.1.2
pc Jun 14 06:44:55 rereading /net/ndb
pc Jun 14 06:44:55 rereading /lib/ndb/local
pc Jun 14 06:44:55 rereading /lib/ndb/common
term% cat /adm/timezone/local
JST 32400 JST 32400
term%

where `pc' is a sysname of my home computer.
# Time stamps are just 9 hours faster than local time in Japan!

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9fans] time stamps
@ 2000-06-13 22:11 presotto
  0 siblings, 0 replies; 4+ messages in thread
From: presotto @ 2000-06-13 22:11 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

The problem is knowing what the time it is at boot.  The file system disk/kfs
is started before the system knows anything about the local time.  The
system starts out with the local time as the last change time of the
root of the file system.  Later on, the system figures out the
real time via ntp and from that point on everything (file creation, etc)
should have reasonable time stamps.

This is a consequence of a change made since the previous release.  There
was much pain caused by our using the real time clock on the PC's as our
source of GMT time.  Microsoft keeps that clock in local time, literally.
That is, they advance or retard it to correspond with daylight savings time.
Only windows can make this switch since they record the info somewhere on
their file system so that they won't repeat it.  When we set the clock
to GMT and used it as a GMT clock, we confused Windows.  When we left
it alone, we only knew within an hour what the right time since we didn't
know when Windows had last done a savings time correction.  This doesn't
bother us much since we generally run our machines diskless off of a central
file server and usually get the initial time from that central server.  It's
off by at most a second since it stays up between the reboots of its clients
and does use a real time clock as a GMT source.

I think a better fall back position is possible.  I'm open to suggestions.

[-- Attachment #2: Type: message/rfc822, Size: 2413 bytes --]

From: arisawa@ar.aichi-u.ac.jp
To: 9fans@cse.psu.edu
Subject: [9fans] time stamps
Date: Tue, 13 Jun 2000 14:06:30 GMT
Message-ID: <20000613131151.366.qmail@nx.aichi-u.ac.jp>

Hello,

I said:
       >>The kernel says:
       >>ether8003: warning - 0xD0000 unavailable#IO: ....
And jmk replied:
>despite the warning does the card work?

Yes. I have confirmed just now. Thanks.

By the way, time stamps are something curious.

term% cd /sys/log
term% ls -l
a-rw-rw-rw- M 3 sys sys   0 Jun  8 00:23 auth
a-rw-rw-rw- M 3 sys sys   0 Jun  8 00:23 cs
a-rw-rw-rw- M 3 sys sys 174 Jun 14 06:44 dns
a-rw-rw-rw- M 3 sys sys   0 Jun  8 00:23 ftp
...
term% date; date -u
Tue Jun 13 21:59:52 JST 2000
Tue Jun 13 12:59:52 GMT 2000
term% cat dns
pc Jun 14 06:44:55 starting dns on 192.168.1.2
pc Jun 14 06:44:55 rereading /net/ndb
pc Jun 14 06:44:55 rereading /lib/ndb/local
pc Jun 14 06:44:55 rereading /lib/ndb/common
term% cat /adm/timezone/local
JST 32400 JST 32400
term%

where `pc' is a sysname of my home computer.
# Time stamps are just 9 hours faster than local time in Japan!

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9fans] time stamps
@ 2000-06-13 16:12 Russ Cox
  0 siblings, 0 replies; 4+ messages in thread
From: Russ Cox @ 2000-06-13 16:12 UTC (permalink / raw)
  To: 9fans

	By the way, time stamps are something curious.

That's likely because dns got started
before aux/timesync had been started
and gotten a chance to correct the
machine's time.

Russ



^ permalink raw reply	[flat|nested] 4+ messages in thread

* [9fans] time stamps
@ 2000-06-13 14:06 arisawa
  0 siblings, 0 replies; 4+ messages in thread
From: arisawa @ 2000-06-13 14:06 UTC (permalink / raw)
  To: 9fans

Hello,

I said:
       >>The kernel says:
       >>ether8003: warning - 0xD0000 unavailable#IO: ....
And jmk replied:
>despite the warning does the card work?

Yes. I have confirmed just now. Thanks.

By the way, time stamps are something curious.

term% cd /sys/log
term% ls -l
a-rw-rw-rw- M 3 sys sys   0 Jun  8 00:23 auth
a-rw-rw-rw- M 3 sys sys   0 Jun  8 00:23 cs
a-rw-rw-rw- M 3 sys sys 174 Jun 14 06:44 dns
a-rw-rw-rw- M 3 sys sys   0 Jun  8 00:23 ftp
...
term% date; date -u
Tue Jun 13 21:59:52 JST 2000
Tue Jun 13 12:59:52 GMT 2000
term% cat dns
pc Jun 14 06:44:55 starting dns on 192.168.1.2
pc Jun 14 06:44:55 rereading /net/ndb
pc Jun 14 06:44:55 rereading /lib/ndb/local
pc Jun 14 06:44:55 rereading /lib/ndb/common
term% cat /adm/timezone/local
JST 32400 JST 32400
term%

where `pc' is a sysname of my home computer.
# Time stamps are just 9 hours faster than local time in Japan!

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2000-06-13 22:11 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-06-13 13:38 [9fans] time stamps arisawa
2000-06-13 14:06 arisawa
2000-06-13 16:12 Russ Cox
2000-06-13 22:11 presotto

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).