Newsgroups: comp.sys.next
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!ubc-cs!sritchie
From: sritchie@cs.ubc.ca (Stuart Ritchie)
Subject: Re: Spotted Workspace ? Why? (and BlastApp??)
Message-ID: <1991Apr5.075135.23325@cs.ubc.ca>
Keywords: memory errors, non-parity memory, spotted display
Sender: usenet@cs.ubc.ca (Usenet News)
Organization: University of British Columbia, Vancouver, B.C., Canada
References: <5596@media-lab.MEDIA.MIT.EDU> <1991Apr3.230504.27819@mp.cs.niu.edu>
Date: Fri, 5 Apr 91 07:51:35 GMT

In article <1991Apr3.230504.27819@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes:
>In article <5596@media-lab.MEDIA.MIT.EDU> simsong@daily-bugle.media.mit.edu (Simson L. Garfinkel) writes:
>>Sounds like you have memory problems.
>
>     And further, if you get no error messages when it happens, I'd lay
>some cash down that you have non-parity memory.  And if that is indeed
>the case, just how intact would be willing to bet your software and 
>data are by now?  To limit the damage, I would not boot the system again
>until it has been fixed, if I were you.
>
>
>                                  Scott Bennett, Comm. ASMELG, CFIAG

Hey guys, if the problem was actually bad DRAM, with visible spotting
on the screen, do you think that the system would even run?  I mean,
it's kinda like executing random code hmm?

If software still runs, it sounds to me like the VRAM is shot.
After all, it is the screen that's being affected.  But I'm no
expert, only guessing like everyone else.

---
As for the latest threads about "NeXT should produce a cheaper
machine with slower CPU" I do not agree with at all.  Don't
forget how badly the 030 cube was criticized for poor perceived
performance.  The last thing NeXT needs is another target for
cheap shots from other vendors.

The RISC vs CISC debate is moot.  I think it would be a really
bad move for NeXT to abandon the 680x0 series as their
general purpose application CPU, especially after only 2 years!

Notice that I say _general purpose_.  I would certainly welcome
multiprocessor support based on other chips.  The DSP, i860 and
C-Cube are fine examples.

Personally, I would like to see NeXT offload networking support
to a dedicated CPU.  Protocol performance inside the Unix kernel
is relatively poor (that's an understatement) compared to more
special purpose implementations.

Just like their special purpose Mach and DPS implementation on
the i860, one could see a lightweight Mach and x-kernel running
TCP/IP on an 88000 based board.  Hell, even a 68020 would probably
be better than sucking cycles from the 040 at each Ethernet
interrupt.

Of course, you must add the possibility for extensibility.  Users
and third parties must be able to run their own protocol suites.
But those are details that o/s types like me love to figure out.

If NeXT did this, I would be really impressed.  Finally our machines
could reach Ethernet speeds!

Out-on-limb-statement:  Dedicated multiprocessors are the way to go.
Of course, a few 040's for general application use would also help :-)

In fact, writing the o/s for a dedicated multiprocessor FDDI board is
my thesis topic.  If anyone experienced with hardware and software
issues related to dedicated multiprocessing would like to comment,
please do!  I would love to hear how it _really_ works.

Later dudes!
...Stuart   <sritchie@cs.ubc.ca>     Wot's... uh the deal?
