|
Grex > Coop12 > #94: Minutes March 21, 2002 Board Meeting | |
|
| Author |
Message |
| 25 new of 136 responses total. |
mdw
|
|
response 76 of 136:
| 
Apr 23 23:01 UTC 2002 |
Obviously, i386 (and z80...) is everywhere. The *design* though is,
well, unique and uncommon. 68k has at least learned about general
register architecture from the ibm 360. Digging back through history,
well, um, an interesting parallel is the ford model T -- it was also
unique yet ubiquitous.
|
styles
|
|
response 77 of 136:
|
Apr 24 06:47 UTC 2002 |
#71: you really think SPARC isn't fast? the only thing SPARC isn't is cheap,
and didn't someone actually offer to donate an Ultra-II or two for grex?
Ultra-II's are pretty damn fast. SPARC is inherently "faster" than x86
architecture-wise. x86 manufacturers have to boost clock cycles through
transistor compaction and high-throttle fsb speeds, whereas the intelligent
designed of the SPARC architecture and even the mere abundance of temporary
registers in SPARC allow for comparible speeds without making up for the
latency of a complex instruction set combined with the throughput retardation
courtesy of excess memory transfers. sure, you can accellerate bus speeds
to make your excess memory transfers faster, but ultimately you are going to
be putting the assembly programmers of the world through the pain of dealing
with a shitty instruction set. IA-64 attempts to address the innate crapiness
of x86, but the prices are outrageous (maybe it's all just several dozen grand
for the test models right now, and they're going to ditch the project anyway?
dunno...). because they recognize that you can only invest so much into
transistor packing and and bus amphetaminization before physical limits are
reached and they are left with the walls of crackheaded design that they
themselves erected. give yourself a frame of 32 general purpose registers,
and allow yourself a save instruction, and suddenly the cycles required to
perform menial tasks are extraordinarily reduced, particularly with function
calls. plus, with SPARC-V9, you have 64-bit arithmetic, so you don't have
to worry about quad_t double register operation emulation with gcc, because
a single add instruction can handle that in SPARC-V9. why go with x86?
dunno...because there's so much hardware available for it? because it's
cheap? sure (again, didn't someone offer to donate Ultra-II's?). i would
just personally rather not
a) perpetuate mainstream acceptance of piss-poor CPU architecture
b) rely on such a system whose components, although cheaper, are
are likely not going to withstand the test of time that the
current grex has endured.
/$.02
|
gull
|
|
response 78 of 136:
|
Apr 24 16:46 UTC 2002 |
Re #77: Grex has a limited budget. While to you and to Marcus this may be a
religious crusade, I like to look at it from a $ per performance standpoint.
When you look at it that way, it's hard to beat i386. i386 server-class
hardware is every bit as reliable as the Sun stuff, too. I've seen at least
as many Sun workstations break down as I have Intel machines. Some Sun
designs have contained parts that did not age well.
|
cross
|
|
response 79 of 136:
|
Apr 24 17:56 UTC 2002 |
Regarding #78; Yes, that person who offered to donate an Ultra 2, and who
did so, was me. It's much slower than the kind of x86 hardware you can get
for the same money, though.
Look, SPARC might be better than i386, but don't hold it up as some
pinnacle of good design. Take a look at MIPS for something much nicer.
In the meantime, do some benchmark comparisons. The x86 architecture
might not scale as well, but (a) it's integer performance meets or
beats comparable SPARC chips, and (b) it's high clock rate pushed it over
SPARC in terms of performance.
|
keesan
|
|
response 80 of 136:
|
Apr 24 19:06 UTC 2002 |
Dan, are you offering (in 79 first par) to donate x86 hardware which is
superior to whatever Marcus is thinking of using?
|
cross
|
|
response 81 of 136:
|
Apr 24 19:43 UTC 2002 |
Regarding #80; I donated the two Ultra SPARC workstations, with 768MB
RAM between them, and over 20 GB of disk. I understand that another user
is donating x86 hardware comparable to what I donated; I think that the
several thousand dollars worth of equipment I already donated to grex
is quite enough for right now, thank you very much.
But that's an aside; the main issue that is that x86 hardware is simply
the appropriate hardware to use for the ``main'' grex. SPARC hardware
would be fine for satellite machines, but not the main host; I've given
reasons why. Perhaps you can give us a well-reasoned engineering
rationale for why using UltraSPARC hardware is the appropriate choice?
|
jp2
|
|
response 82 of 136:
|
Apr 24 19:52 UTC 2002 |
This response has been erased.
|
cross
|
|
response 83 of 136:
|
Apr 24 21:20 UTC 2002 |
I don't know if she can or cannot reason, but I find it pretty insulting
that I donate thousands of dollars worth of equipment to grex, and this
individual thinks I should donate more. I mean, don't get me wrong, I
feel good about giving things to what I consider a worthy cause, and I
think that the debate around x86 vs. SPARC is both useful and interesting
(and perhaps the other participants feel the same way), but really, I
think it's in grex's best interest to strongly pursue x86 hardware, and
I'm not in a position to provide it. Sorry.
|
keesan
|
|
response 84 of 136:
|
Apr 24 23:02 UTC 2002 |
I was simply asking what you meant by the first paragraph - it looks like your
SPARC equipment is free but the equivalent x86 would have to be purchased.
I did not mean to insult anyone and I know nothing about the relative merits
of the two types of equipment.
|
mdw
|
|
response 85 of 136:
|
Apr 25 03:04 UTC 2002 |
As a general rule, I think x86 hardware *does* retain its value better,
precisely because it can continue to run MS windows in people's homes
years after the equivalent scientific/research hardware would normally
be replaced by something newer and the older hardware junked.
I should state that for the record, *I* certainly appreciate Dan's
generosity, and I feel it will benefit grex, one way or another. The
hardware he donated is indeed not suitable to be the replacement grex,
but will very likely be helpful for producing future grex software
offline, or may turn into a future satellite server. It's certainly
already been directly useful to the openbsd folks; I found and reported
several bugs, some with fixes, that they might not have found nearly so
fast otherwise. Even if we go strictly with i386 in the end, this
hardware will still be of benefit - a lot of OpenBSD is the same no
matter what the hardware platform, so the effort we sink into higher
level software is going to be very transportable between platforms.
|
aruba
|
|
response 86 of 136:
|
Apr 25 03:05 UTC 2002 |
Dan, we certainly appreciate your donation. It was very generous of you.
|
jp2
|
|
response 87 of 136:
|
Apr 25 04:01 UTC 2002 |
This response has been erased.
|
gull
|
|
response 88 of 136:
|
Apr 25 14:34 UTC 2002 |
Re #84: Actually, my understanding is that the Sun hardware we've had
donated isn't considered suitable for running Grex, so no matter which
direction we go we'll be buying hardware.
For the record, I think either solution can be made to work. I think
this discussion is mostly about the "best" choice. I won't be terribly
upset if the new Grex ends up on Sun hardware, I just think there's a
lot of disinformation and FUD going around about i386 machines, and that
bothers me.
|
aruba
|
|
response 89 of 136:
|
Apr 25 15:07 UTC 2002 |
My major concern is that we pick the path which makes it easier to find new
people to work on the system.
|
cross
|
|
response 90 of 136:
|
Apr 25 16:05 UTC 2002 |
Thanks Marcus and Mark. I think that grex is a great thing, and am glad
to be able to help support it in any way.
Regarding #89; from the perspective of 99% of administration tasks, which
don't involve the hardware as anything other than the black box that the
software runs on, the hardware platform is pretty much immaterial. SPARC
or x86 is only going to make a difference in that regard in a very small
percentage of cases; in particular, only when the computer hardware itself
needs to be fiddled with, which I gather is very, very rarely. Disks and
things are another issue, but those are more or less the same regardless
of wether the CPU is a SPARC or AMD i386 clone.
|
aruba
|
|
response 91 of 136:
|
Apr 25 16:10 UTC 2002 |
That's good to know.
|
mary
|
|
response 92 of 136:
|
Apr 25 18:11 UTC 2002 |
I agree with Mark's #89.
|
gull
|
|
response 93 of 136:
|
Apr 25 20:56 UTC 2002 |
I agree with #90. Administering OpenBSD on a SPARC isn't really any
different than administering it on an i386. When I tried it, the
installation went a little differently, but once the system was
installed there wasn't much of any noticable difference.
|
aruba
|
|
response 94 of 136:
|
Apr 25 21:07 UTC 2002 |
Well, certainly a big part of Grex is installation - look how long the staff
expects installation to take this time. So if being on one type of hardware
or the other would make a difference in how quickly and easily we could move
to the next machine, that's a consideration.
|
cross
|
|
response 95 of 136:
|
Apr 25 22:14 UTC 2002 |
There's installation, and then there's Installation. The installation
of the operating system on the bare hardware is a couple of hours work,
maximum. The installation of all the software, services, configuration
of those services, etc is that Installation that takes a *long* time,
but that's independent of hardware once again. About the only part of
the actually system installation that takes a while is figuring out how
to partition the disks, but that is also independent of the hardware.
|
aruba
|
|
response 96 of 136:
|
Apr 26 01:40 UTC 2002 |
Hmmm. Well, what things *will* be affected by our choice of hardware?
|
mdw
|
|
response 97 of 136:
|
Apr 26 03:28 UTC 2002 |
Performance. Reliability. Serviceability. Vandal-resistance. Spare
parts. Cost. Availability. Resale value.
Some of these are easy to quantify. Some of them are much more fuzzy.
|
gull
|
|
response 98 of 136:
|
Apr 26 13:19 UTC 2002 |
Possibly power consumption, as well. Grex's current Sun system draws a
very large amount of power, IIRC.
|
aruba
|
|
response 99 of 136:
|
Apr 26 15:54 UTC 2002 |
I'd say judging by our past record, resalability isn't a big factor, since
we've never sold an old machine. Could you explain what you mean by
servicability, Marcus?
Does anyone have anything to add to Marcus's list?
|
cross
|
|
response 100 of 136:
|
Apr 26 20:16 UTC 2002 |
No, nothing to add, but I'd really subtract that ``vandal-resistance''
statement. I've given what I think are fairly complete answers why in
the garage group. Marcus' argument as I understand it is that things
like buffer overrun attacks, which are mostly scripted and mostly for
x86, won't work against SPARC (for the basic technical reason that a
SPARC processor is not an i386 processor. Ie, if you find some way to
do something bad to a Ford, it might not do anything against a Chevy
since a Ford is not a Chevy).
My arguments in return are that it's unlikely to matter for the following
reasons: (1) most network services can (and should) be pushed off onto
other machines where performance is not as much of an issue anyway, (2)
scripted attacks are unlikely to do much already since grex doesn't seem
to like to run much in the way of stock software, (3) grex has already
chosen to run software which fixes many of potential problems proactively,
and (4) SPARC is the second most common architecture for such things; the
time lag between when an x86 exploit comes out and when a SPARC exploit
comes out is negligable in most cases, and (5) those who can get around
the first 4 reasons aren't likely to be seriously hampered by the fact
that grex is running on a SPARC processor instead of an x86 processor,
as they'll likely have the technical skills to retarget their attack.
The other things Marcus lists I think are roughly the same between x86
and SPARC. x86 clearly has a massive lead over SPARC in the spare parts
category; I'd say the two are roughly the same in terms of reliability,
though x86 is getting better and SPARC is getting worse; x86 has a clear
advantage in terms of performance, especially at the price range grex
is talking about. x86 is a clear winner in both cost in availiablity,
as well. I'm guessing that Marcus is refering to the ease with which
one can open the thing up and muck with the insides when he mentions
servicability. Nice x86 hardware is just as good as SPARC here; in
particular, all you really need is a nice case.
In terms of power consumption, either choice will draw less current
than the current dinosaur that grex is running on; I'm guessing that
x86 would be the winner, but that's only a guess; everything else is
my own personal experience and/or common industry knowledge.
|