Does anyone know what the status is on the 50 mHz iAPX 486?

   It was rolled out with much fanfare, in early summer last
year.  About 6 weeks later they recalled all 50mHz product,
because a small number of them would randomly reset themselves
when running at top speeds, at temperatres close to the
maximum rating.

   This is, I believe the first "recall" of an Intel product,
certianly in the CPU arena.  I know that several people who
have 50 mHz Compaq's said "no way!" to their request to send
them back...

   So whats the deal this week?  Think Intel's tri-metal
process is going to get ironed out?  Or will the 66 mHz
effective-speed units get out first?

21 responses total.

They didn't recall the early 386's with the screwed up math?

re #0:  Shouldn't that be 50 MHz??  50 mHz would be awfully slow.  :)

   As far as I know, mHz was the correct case--thought that was
weird when I first saw it.

   Anyway, Intel has again released the 50mHz 486, and this time
they say it'll work correctly over the entire temperature range.
Gateway 2000 will start selling them next week.

Wonderfull,  any news on solaris ports to 486?

   Solaris has done that already.  Don't know if they're selling it
or still testing yet.

(Be aware, though, that Solaris 2.0 is nothing like Solaris 1.0, aka
SunOS 4.1.  SunOS 4.1/Solaris 1.0 was based on 4.3BSD Unix.  Solaris 2.0
is based on SysVr4 Unix.  There is a *big* difference.  I would not
be surprised to learn that Solaris 2.0 on the SPARC is quite unstable,
at least until they get up to Solaris 2.1/SPARC.  Solaris 2.0/i386
should be a bit better, since Interactive (or whatever Sun is calling
the Solaris/i386 division that they purchased from Kodak) has more
experience with SysVr4 on the Intel chip than Sun does with SysVr4
on the SPARC chip.

50 mHz? Geez, what's that...20 seconds per clock cycle? Man.

Which one is the one that doesn't link files accross file systems?

Do they always have a limit of 65K for a filesystem (maybe inodes??).

re #3,8:  MHz is the proper abbreviation.  mHz is 1/1000 of a Hertz.

The AA News just made the same mistake, and published my letter 
correcting them.  

   Yeah?  OK. MHz it is.

   How much is Solaris 2.0?

re 8: neither, and not always.

I read on usenet that someone ran out of inodes and had to create another
filesystem.  But then, the newssoftware tried to link files accross
filesystems, and failed.  That was 386 version, and someone was saying that
the bsd version would not have that problem.  Now I don't know if that
refers to the inode numbers or linking accross filesystems.

Does unix let you create files that go accross files /disks/filesystems ?

So far, from reading all the questions answers on unix, it looks like
the bsd version is better.  However, there must be a reason for it being not
as popular as the AT&T version.  Is that similar to the msdos story or
is there really some tecnical motivation behind it?

   I don't know of any version that does.  Yet.  bsd unix is indeed
popular; if you go back in history in time, a lot of the machines
out there used BSD unix.  There hasn't been a migration down twoards
the little machines 'till lately.  But thats all changing now.

What is the deal with inodes. Is it something like file allocation table
entries?  Would that change if one used a defragmenter?  I understand
even then there would be a limit to the count of files on the filesystem.

An inode is the reference to a physical file -- it stores the
information about the file, such as its permissions, its owner,
which disk blocks belong to it, etc.  Directory entries just contain
the name of the file and the inode number.  You can "link" files by
making more than one directory entry that references the same inode
number.

Unfortunately inode numbers are not unique across filesystems, which
is why cross-device links didn't work until recently.

A "symbolic link" is a bit different.  Symlinks (as they're usually called)
consist of a special type of file, which contains the *filename* (instead
of the inode number) of the real file to access.  So, using symlinks,
you can link to any file you can reference by pathname -- directories,
files on other filesystems, even files on filesystems that are NFS-
mounted from other hosts on the network.

The 65K inode limit comes from the fact that on SysVr3 and below
systems, a 16-bit field was used to store the inode number.
Naturally, this means that you can't have an inode number bigger
than 2^16-1, or 65,535.  Newer systems use 32-bit inode numbers,
so they have a much larger limit on the number of inodes per filesystem.

Very enlightening, thank you.

There are some versions of Unix that will allow you to create
filesystems that span multiple drives.  Historically, such games have
been limited to unusual applications like the telephone directory
assistance program.

How do the distributed file systems link to this subject (altough I am not
familiar with nsf-net, etc)?  Do they have to be linked over ethernet?
What if you fake it, that is let it think that there are actually two
fileservers connected thru a fake ?socket? which connects input with
output and vice versa.

Well, the particular variety of distributed filesystem most people are
talking about here is Sun's NFS, or Network File System.  NFS
operates over UDP, which operates over IP, which operates over just
about any kind of networking medium you want to put it on.  Ethernet
is by no means required; there are people running NFS over token-ring,
FDDI, and even dialup PPP and SLIP links.

You could, I suppose, use NFS to mount a local filesystem, and have
the system be none the wiser.  Dunno why you'd want to, though.
(Just do something like "mount localhost:/ /mnt" to get a mirror
of your root filesystem in /mnt.  Interesting Question: What does
/mnt/mnt contain at this point?)

If I recall, NFS doesn't follow mount points, so /mnt/mnt should be an
empty directory.

AFS also uses UDP.  The mechanics inside the protocol are a bit
different.  NFS uses something called Sun RPC, and is specifically
designed to be stateless.  In theory, the file server can crash at any
point, come up "some time later", and if the client is still trying,
will pick right up where it left off.  "In theory" - there are some
interesting practical problems.  AFS uses something called RX, and
maintains state information on the file server - while you are in the
process of writing the file, the "official" copy of the file lives on
your workstation.  If you read a read/write file, the file server
remembers you read the file, and maintains a table of "call backs" on
that file -- if somebody else writess that file, it will contact your
client and tell it that the cached read-only copy of the file you were
using is now invalid.  The overall scheme is more complicated (and you
can get much more interesting errors) - but it does perform a lot better
than NFS.  NFS, with 20-30 clients, can do a fairly good job of
saturating a local ethernet.  AFS, on the other hand, can do tolerably
well with hundreds of clients, and some of those clients can be located
at some distance from the file server - such as across the country.

One of the bigger problems with NFS -- other than network saturation --
is error-correction.  Since NFS was designed to be run over Ethernets
or similar local-area networking media, there was never any attempt
made to build error-detection or -correction into the NFS or RPC
protocols.  (Ethernet, you see, already has error-detection as part of
the Ethernet frame.  So if you get a mangled Ethernet frame, it never
gets passed up to the higher parts of the protocol stack, and so NFS
eventually retransmits it.)  However, now that people are trying to
run NFS over wide-area links that may not be 100% error-free (at least
from NFS's point of view), it becomes a problem.  It becomes even more
of a problem when people turn off UDP checksums, which are (in the
absence of something at the hardware level, like Ethernet frame
checksums) the only error-detection you've got.

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss