Date: Fri, 1 Jan 93 04:30:09 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #1
To: tcp-group-digest
TCP-Group Digest Fri, 1 Jan 93 Volume 93 : Issue 1
Today's Topics:
Computer reliability
Leaving it on!!
Linking TheNet X1G and NOS
MX to yourself as alternative to SMTP gateway to yourself
NOS and Borland C++ 3.1's -3 flag
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Thu, 31 Dec 92 10:42:02 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: Computer reliability
To: tcp-group@ucsd.edu
Well I do not have any hard numbers but here are a few points...
The main killer of anything electronic is heat. In modern computers
this heat is usually at the chip level. Unless the fan has failed
the internal ambient is not much higher than external. The chip
temperatures are another story. Has anyone tried holding there finger
on a 486? The 486-33 and faster IC's really should have heat sinks
if they are not supplied with one. I put one on my 486-33. It is a
flat heatsink which covers the entire top of the chip and is bonded
on with heat conductive epoxy. Faster units could benefit from a heatsink
and fan. Heatsinks can be used on any IC that is running hot. These
IC's are spec'ed to take the heat but somehow being able to burn my
finger on them is not a good sign.
On the other hand an argument can be made for cycling an IC thru cold/hot
as would happen at computer on/off periods.
In most cases the only other concern is the hard drive. Here we have seen
BIG changes in the last year or so. Drives have gotten smaller with much
larger capacity. 200mbyte drives of today draw far less power and produce
far less heat than 20-40 mbyte drives of a few years ago. The reduction in
power is significant!
I was looking at refrigerators last week and it seems that as of 1993
a new set of efficiency standards are required. Refrigerators made in
1993 will require far less power than previous models. Since a
refrigerator can last 15 years or more the savings over the lifetime
is significant. Especially in a high energy cost area. Many thousands
of dollars could be save over the lifetime. So why worry about spending
a few hundred more dollars at purchase? Why not scrap your current 5-10
year old for a new one? People only think of the up front costs. When
a cost is spread out over a long period it is forgotten.
So now we get back to hard disk drives. A 200 mbyte low power drive
would probably pay for itself over a 5 year period in power saved over
some old full height clunker. Not to mention that most new drives have
100,000 hour or better MTBF's.
It costs approximately $100/year per 100watts. The actual power draw of
late model computer is in the 50 watt area - minus the monitor. My
definition of 'late model' is the last year or so. This is a system
with heavy LSI/VLSI and a low power hard drive. In some cases the actual
draw may even be lower. Old PC's/XT's could actually be far more expensive
to run than a new 386 or 486.
Doug
------------------------------
Date: Thu, 31 Dec 92 16:24:53 CST
From: jks@giskard.uthscsa.edu
Subject: Leaving it on!!
To: tcp-group@ucsd.edu
------------------------------
Date: Fri, 1 Jan 1993 4:41:11 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Linking TheNet X1G and NOS
To: wetmore%merlin.dnet@gte.com, tcp-group@ucsd.edu
(Fix your address. My mailer, and probably most other people's, can't
handle embedded quote marks in the "From" line where they have routing
significance.)
TheNet X1H is out now; you should probably upgrade.
This is documented in OVERVIEW.X1H (at least in the new release). Setting
"crosslink/kiss" to mode 2 will allow the KISS protocol to be used on the
diode matrix, and frames not destined for the node that are received on
the radio port will be passed to the RS-232 port (and thus to the matrix).
-- Mike Bilow, <mikebw@ids.net> (Internet)
------------------------------
Date: Fri, 1 Jan 1993 6:52:35 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: MX to yourself as alternative to SMTP gateway to yourself
To: tcp-group@ucsd.edu
From: IDS::MIKEBW "Mike Bilow, <mikebw@ids.net>" 1-JAN-1993 05:16:33.86
To: SMTP%"crompton@NADC.NADC.NAVY.MIL"
CC: MIKEBW
Subj: RE: MX in Domain.txt
Setting the smtp gateway to yourself is a very bad thing to do. What
this really means is, "Whenever you have a piece of mail to an unknown
host, send it to yourself." Obviously, if the host was unknown once,
it should be unknown again and every time the mail is processed, giving
an endless mail loop. But the rewrite file changes the destination
"host" so that the mail goes somewhere different on successive steps.
We rely on smtp gateways for a couple of important reasons. For
example, we have XT-based switches that take a fairly long time to
resolve a domain name, especially if the name is actually unresolvable.
If a piece of mail gets stuck at an unattended switch, for example, it
will usually bog down the machine so badly as to cause a crash. What I
do is set up these slow machines to have an attended machine (usually
mine) as their smtp gateway, so that the unknown mail will be passed to
me for human intervention instead of just inducing a crash. (Also,
since I am running a 486, I don't crash doing a lot of domain lookups.)
What we really want to do, I would think, is to say that only some mail
that is not addressed to recognized hosts should be looped through the
rewrite file. If I define an MX record for a certain form of address,
then that has the same effect as defining the smtp gateway as yourself,
provided that the MX record defines yourself as the mail exchanger. One
way to do this would be to create a locally significant pseudo-domain,
such as "BBS," within which all non-Amprnet "hosts" would reside.
I am not trying to pretend that this is a really clever or even correct
use of MX records, especially since MX records are not supposed to be
only locally significant. However, I really dislike the smtp gateway
kludge, and I think some alternative would be better. I also think it
might be worth considering changing the source code so that all mail is
passed through the rewrite file, but this would have some complications.
-- Mike Bilow, <mikebw@ids.net> (Internet)
------------------------------
Date: Thu, 31 Dec 92 17:37:48 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Subject: NOS and Borland C++ 3.1's -3 flag
To: tcp-group@ucsd.edu
Mike Bilow reported in November that the Borland C++ 3.1 '-3' flag
breaks NOS.
This flag tells BC++ to use 386/486 32-bit arithmetic instructions. If
it could be made to work, it would be a big size/performance win,
especially for certain routines that do a lot of 32-bit arithmetic
(such as the MD-5 hash command that I've added to my FTP server).
I have been working on this problem. It's caused by my assembler-
language interrupt handlers not saving the high 16 bits of the 32 bit
general registers. If a C function compiled with the -3 flag is then
called from an interrupt, it corrupts the high 16 bits of the
interrupted task's general registers. Of course, this may or may not
cause a crash, depending on whether the interrupted task also uses 32
bit registers. A good way to guarantee a crash is to compile with '-3'
a file like mbuf.c that has functions called both from interrupt
context and from normal context.
The solution for the hardware interrupt handlers is pretty
straightforward -- add conditional code to the assembler interrupt
handlers to use PUSHAD/POPAD instead of a series of 16-bit push or pop
instructions whenever assembling for the 386 or 486.
The FTP Software packet driver is more problematical because it
communicates with its upcalled routine via registers during a software
interrupt. I think I can manage a way to save the high order bits while
continuing to communicate through the low 16 bits of each register.
BTW, the MD5 hash command in my FTP server takes a file name and
returns the 16-byte MD5 hash of that file's contents. It's quite
useful for comparing files across the net without actually having to
transfer them. You can do this after you transfer a file (to make sure
it got there intact), or you can do it before a transfer to see if
it's really necessary.
I find it quite useful to keep my PCs at work and at home synched to
each other with NOS source files. I set an "update" flag in my FTP
client and then do a "mput" or "mget" as appropriate. The client then
automatically requests the MD5 hash from the server for each file on
the list and skips the transfer if they already match.
Once I work through a long list of fixes this weekend (including the
-3 flag fix) I plan to release my stuff on ucsd.edu. It's been some
time since my last release, so there's a lot of stuff in there.
Phil
------------------------------
Date: (null)
From: (null)
> Once and for all, does anyone have the *SCIENCE* to tell us whether leaving
> a computer on 24hrs improves or reduces its reliability?
I have been looking for the answer to this question too. The best answers I
could get were "derived" by implication.
If one looks at lab data for MTBF for all critical components in a system, all
one can do is accept the lowest MTBF number as the the "mean likely lifetime"
of that system in continuous operation on a clean power source. I am not aware
of any data that clearly shows the result of on/off cycling of, for example, a
hard disk drive. If someone knows of a study that shows the effect of
power cycling on derating the MTBF of electromechanical and solid
state components that would greatly in answering the question, if only in that
it would help establish a probability factor.
I leave my machine on all the time. ;-)
73 and happy new year!
Jack....
*********************************************************************
* Dr. John Spitznagel * Sancho Panza Institute *
* Internet: jks@giskard.uthscsa.edu * for Advanced Studies *
* AMPRNet: kd4iz@kd4iz.ampr.org * Department of Bogometrics *
* CIS: 76044,476 * *
* Tel: (210) 567-6616 * (C) JKS, 1992 *
*********************************************************************
------------------------------
End of TCP-Group Digest V93 #1
******************************
******************************