|
Grex > Coop12 > #94: Minutes March 21, 2002 Board Meeting | |
|
| Author |
Message |
| 25 new of 136 responses total. |
jp2
|
|
response 25 of 136:
|
Mar 30 00:59 UTC 2002 |
This response has been erased.
|
gull
|
|
response 26 of 136:
|
Mar 30 01:15 UTC 2002 |
The x86 architecture probably has a future. PPC may go the same way the
Alpha did. PPC machines are also behind x86's in performance per $.
|
cross
|
|
response 27 of 136:
|
Mar 30 05:00 UTC 2002 |
Also, I don't believe that the Mac systems support ECC memory.
|
mdw
|
|
response 28 of 136:
|
Mar 31 03:18 UTC 2002 |
The PPC market is split - there's IBM, and then there's apple. There's
also Motorola and a few speciality folks. IBM makes some very nice
higher end stuff, which is only mildly overpriced. Apple has
traditionally *never* included ECC or even parity. Every organization
has its corporate blind spots. Apple apparently feels it's more
important for something to keep running than to detect and report
errors. (Contrast this with the original IBM PC which included parity
in an era when personal computers *never* had parity, because they came
from a background (banking/business) where errors are simply not
acceptable.) Motorola and the speciality folks make machines for
various market speciality market niches, such as engineering, embedded
controllers of various sorts, & so forth. For a bit, it looked like
IBM, Apple, & Motorola were coming together to make up a common
motherboard standard. If this had come off, there might have been
enough mixing of these various markets to make it possible for grex to
purchase a low-cost motherboard with the appropriate features.
Unfortunately, this never happened, which is regretable on many levels.
Technical arguments, with their basis in engineering and mathematics,
are even more prone to schisms based on original premises. Any engineer
who can't admit this is so hopelessly tied up in his original premises
that his judgement can no longer be relied upon, in any field. And, in
fact, in the previous paragraph, it's easy to recognize different
rational engineering decisions being made based upon fundamentally
different initial premises. Pure science is no less immune to this
disease of the initial premise. Most of the more important scientific
discoveries are made by relatively young people, and often by people who
aren't in the mainstream. It then generally takes about a generation
for the discovery to become generally accepted, which is oddly enough
the time it takes for the old establishment to die out.
Sure, we want a fast machine, but we also want a *Consistent* machine.
I've heard from various people, at various times, that PC hardware
generally tends to behave more inconsistently and less pleasantly, under
great load. What that would translate to in human terms, is a machine
that is faster by any objective measure, but feels subjectively slower
and is more annoying to use. Measuring pure speed is easy to do.
Measuring *consistency*, load, & human factors is not nearly as easy.
Also, lest people claim I'm immune to the intel argument, allow me to
point out: I have intel hardware at home (well, actually that and AMD
K6-2). STeve is still very proud of his pentium 4 based IBM laptop,
with its 1600x1200 display and running OpenBSD. At work, I may be
switching our mail server over from running on an IBM RS/6000 530H, to
some newer intel based thing. Different hardware and software are best
at different things; there is no one best answer for all things.
|
kaplan
|
|
response 29 of 136:
|
Mar 31 12:59 UTC 2002 |
It might help give this project a focus to pick a target end date.
Haven't we been saying that we expect this project to take a year for
several months now? I'm not saying that a volunteer effort like this
needs a deadline. I'm just suggesting we should be able to pick an
absolute target date rather than continuing to use a sliding relative
time scale.
On March 21, resp:0 says, "target time a year from now." I propose we
take that statement literally and set a target of March 21, 2003.
Hopefully the transition to new hardware will be completed much sooner,
but can staff agree that a target of a next March is reasonable?
|
cross
|
|
response 30 of 136:
|
Apr 1 01:38 UTC 2002 |
Regarding the initial premise thing, it strikes me that if I have a
microcontroller running a safety critical pressure release valve, it
damn well better detect and report errors.
I've never heard this inconsistency argument before, and I've been
running Unix on x86 hardware for many, many years. Perhaps you could
be a little more specific?
|
gull
|
|
response 31 of 136:
|
Apr 1 20:22 UTC 2002 |
It's probably true that Sun hardware, with its more hardware-based
multitasking, performs better under very heavy loads than Intel systems.
Certainly, my subjective observations have been that a Sun system with a
load average of 10 'feels' as fast as an Intel system with a load average of
3 or 4. But Intel hardware is so much cheaper than Sun hardware that you
can simply purchase a powerful enough system that you never reach those
kinds of load averages. I know a lot of people will take offense at that
kind of "get a bigger hammer" approach to performance, but it works.
|
cross
|
|
response 32 of 136:
|
Apr 1 20:45 UTC 2002 |
Really? I don't know; I find Sun's feel uniformally slower than x86
machines, even under really heavy load. The Sun I'm sitting in front of
right now feels extremely slow, and the number of processes running on it
isn't that great. Hardware multitasking is nice, but really no substitute
for good context switching code. An empirical piece of evidence is
Plan 9 running on x86 hardware compared to running on, say, SPARC.
It's just not faster, no matter what kind of load is running on it.
What we're really talking about is scalability. x86 hardware really does
scale as well as other stuff these days, particularly at the level we're
talking about here. Witness that the main Plan 9 CPU server at Bell
Labs is a quad-processor Xeon machine. I can personally tell you that
that machine (which replaced an 8-processor SGI Challenge XL machine)
is hammered quite frequently, with both big compute jobs and lots of
processes. The hardware context stuff just isn't needed, but Plan 9 is
probably a lot more efficient than Unix at doing context switches.
|
srw
|
|
response 33 of 136:
|
Apr 10 04:54 UTC 2002 |
Someone was saying that Grex's new x86 donated by Remmers at 400 Mhz is
not fast. It isn't. Faster ones can be had cheaply though. 4 months
ago, HVCN bought a brand-new 900 Mhz Celeron server from Dell for $528
(including 128M Ram and 20GB HD. We would clearly add Ram for Grex)
This machine is in service, running OpenBSD 3.0 since 1/2/02.
It's very nice. http://www.hvcn.org/
|
remmers
|
|
response 34 of 136:
|
Apr 10 13:39 UTC 2002 |
Right. The intent isn't to use it as a production machine, but
rather as a testbed for OpenBSD on x86 hardware.
|
blaise
|
|
response 35 of 136:
|
Apr 10 18:18 UTC 2002 |
I just bought a brand-new 950MHz Athlon server with 256M RAM and 20G
drive for $370 (including shipping).
|
cross
|
|
response 36 of 136:
|
Apr 10 19:43 UTC 2002 |
Wow, that's cheap. Grex will likely want SCSI, which adds a bit of cost,
but only a few hundred dollars, and there's money in the bank specifically
earmarked for hardware.
|
mdw
|
|
response 37 of 136:
|
Apr 10 22:07 UTC 2002 |
Something else we'll want to add too is ECC memory. Yup, consume grade
equipment is very cheap, but there *are* things you sacrifice.
|
cross
|
|
response 38 of 136:
|
Apr 11 16:28 UTC 2002 |
ECC memory is cheap. I've seen gigabytes of it for sale on the streets
of New York for under $100. It's really not that hard to put together a
PC that's a steal that still has the features you want.
|
gull
|
|
response 39 of 136:
|
Apr 11 18:49 UTC 2002 |
Most of Dell's servers now have ECC memory as an option. Heck, even
their high-end desktop workstations do.
|
mdw
|
|
response 40 of 136:
|
Apr 12 06:03 UTC 2002 |
No wonder ECC memory is hard to get; it's only available from NYC street
vendors.
|
cross
|
|
response 41 of 136:
|
Apr 12 15:18 UTC 2002 |
Along with antiquated books on LISP systems, and movies on tape that came
out in the theater the day before. Nevermind that the picture on the latter
wobbles, and you can see all these funny shapes moving around towards the
bottom of the screen....
|
blaise
|
|
response 42 of 136:
|
Apr 12 16:58 UTC 2002 |
ECC would have been $100 more on my new system.
|
janc
|
|
response 43 of 136:
|
Apr 14 01:27 UTC 2002 |
To clarify the purpose of John's system. In the past it has taken us
about a year of work to port Grex to a new OS. So the idea is instead
of buying the latest and greatest computer now, and having it a year
old before we let people onto it, we use John's old system to port all
our software, then buy a new computer, and do a quick install of all
the stuff we worked out. Thus we end up with a better computer for our
money.
Of course, since nobody is working on doing the upgrade (so far as I
know) it may take more than a year this time.
|
keesan
|
|
response 44 of 136:
|
Apr 14 14:20 UTC 2002 |
But MDW is working on something to do with Dan Cross's donated computers?
It sounds like whoever is willing to do the work gets to choose the system.
|
remmers
|
|
response 45 of 136:
|
Apr 14 14:47 UTC 2002 |
That's not the way it should work.
|
jep
|
|
response 46 of 136:
|
Apr 14 15:41 UTC 2002 |
It's not? It sounds okay to me.
|
remmers
|
|
response 47 of 136:
|
Apr 14 22:01 UTC 2002 |
I guess it's reasonable if the result is something on which Grex
can run satisfactorily.
There's technical discussion of the platform issue somewhere in the
Garage conference. Reservations have been voiced about the wisdom
of running OpenBSD on a Sun Sparc platform, so I'm hopeful that
somebody will volunteer to check it out on the X86 platform I'm
donating. Had I been able to donate the machine a few months
earlier than this, Jan would be working on it, but he's too busy
right now.
|
jp2
|
|
response 48 of 136:
|
Apr 15 01:16 UTC 2002 |
This response has been erased.
|
cross
|
|
response 49 of 136:
|
Apr 15 01:25 UTC 2002 |
Just because someone is volunteering to do it doesn't mean that's what
should be done. I could volunteer to design a new space shuttle; NASA
would be extremely unwise if they took my design and used it. There's
something to be said for using the most appropriate tool for the job,
not just the one that's the most fun.
|