Report of the Athena/SGI Strategy Discovery Project
Contents
The CEASE (Convening to Examine the Athena SGI Effort) team consisted
of:
Team mailing list: cease@mit.edu
Project notebook: http://web.mit.edu/cease/www/
(includes full charter and notes from meetings)
From late September through October, 1999, we met and gathered data to
answer the discovery question:
Should we continue devoting the fiscal and human resources that are
now going toward purchase and support for the SGI/Athena platform,
or free them up for other uses?
within the confines of our scope statement:
This project is essentially a fact-finding mission, to gather
information necessary for deciding on our future SGI/Athena strategy.
In particular, this project will focus on:
- whether to freeze SGI support at IRIX 6.5
- viability and timeline of SGI/Athena support, including options
for FY2001 renewal
- scenarios for supporting academic use of SGIs in individual
departments if SGI/Athena support is scaled back
Because this question impacts Athena development, cluster machine
renewals, and departmental proposals, it is important to do this work
now so that we are prepared to allocate staff resources efficiently,
avoid disrupting the Athena release cycle, and generally be prepared
for next year's machine purchases. We have frozen this year's
departmental purchases for SGI O2s, and are accepting no new requests
pending the outcome of this discovery effort.
Recommendation Principles:
- Phase out Athena-SGI support by summer 2003. Note that this
coincides with SGI's announced end-date for active (as opposed to
maintenance) support of the
IRIX operating system and MIPS-based hardware, as well as the end
of the normal 4-year life-cycle for machines placed in clusters
summer 1999.
- For academic year 2000-2001, do NOT reduce the number
of SGIs in clusters.
- Actively work with faculty relying on SGI-only software/features
for courses to find non-SGI alternatives or develop other
transition plans.
- Plan end-of-support date for private workstations to coincide with
removal of machines from clusters.
- Make decisions on IRIX updates in the Athena release in line with
usual release cycle, balancing development effort against
importance of bug fixes or other gains.
- Keep Athena users informed of phaseout plans and transition paths
(concentrating particularly on faculty and private workstation
owners, but not to the exclusion of the general population).
Specific Recommendations:
- Cluster renewals
- Do not buy any more O2s.
- For academic year 2000-2001, retain the FY1997
Indys (for a fifth year); in summer 2001, remove all remaining
Indys.
- Private workstation support
- Announce June 30, 2001 as end-of-life for private Indys (to coincide
with removal of all remaining cluster Indys in summer 2001).
Include this information with June 2000 billing, but publicize
earlier if feasible.
- Warn departments purchasing or Athenizing O2s from this point
forward that lifetime may be less than 4 years (e.g. summer 2003, to
coincide with removal of all remaining cluster O2s), at which point
they should be prepared to revert to the vendor operating system or
replace machines with a different Athena platform.
- IRIX upgrades: Decisions should be made by release-team (see III-A
for discussion).
- Transition paths for courses
- Biosym/MSI: Launch a Discovery Project to probe migration options,
in particular vendor-planned application server; Integration should
be involved.
- Alias-Wavefront: This is available now for Solaris; ACS will
investigate. Other options: Architecture is already looking for
alternative software.
- OpenInventor: This is available from Template Graphics Software on
other platforms including Solaris, Linux, NT; ACS will investigate.
Alternative: transition to non-Athenized department SGIs (this should
be feasible for Ocean Engineering, where
dependent class sizes are on the order of a dozen students).
- MIPS (for compiler course): Assist faculty to find an alternative
(e.g., MIPS emulator or other environment) that we can support on
Suns, or give de-Athenized Indys to the department upon removal from
clusters.
- Other commercial software: Assume this will follow the devolution of
IRIX, phaseout by 2003 should allow migration to other alternatives
as vendor course becomes clear.
- Courseware: Provide ACS funds for porting to other platforms where
possible.
- Other non-commercial software: Assuming no source, some will
inevitably suffer code rot (independent of our SGI phaseout
strategy).
- Athena Desktop: Feedback re unique benefits of SGIs included
user-friendly interface and removable media support; desire for
such features might be addressed by the Athena Desktop project.
Athena-SGI stakeholders can be grouped into three categories:
- Instructors and students using SGIs for course work
- IS staff involved in Athena-SGI support
- General Athena user base
SGI systems were originally deployed in the Athena Computing Environment
as special purpose rather than general purpose client workstations.
They were originally introduced to support courses requiring specific
software applications available only on SGIs; over time, use of
SGI-specific functionality has grown (both in courses and by the general
user base), but software that requires SGIs continues to represent only
a small fraction of Athena use in academics, isolated to a few
specialized applications.
Supporting SGIs is expensive, both in terms of hardware and staff
resources. An SGI O2 workstation costs 50% more than a comparably
equipped (CPU speed, disk, memory) Sun Ultra5 and 15% more than the
Sun Ultra10 with Creator 3D Graphics. We have found the SGI to be a
more fragile platform in the clusters, with more down time and
requiring more troubleshooting; as a vendor, SGI has been relatively
uncooperative in working with our staff in tracking down bugs and
problems when they arise.
The future of SGI appears to be uncertain and their strategy is
unclear. We know that they plan to phase out the IRIX/MIPS low-end
desktop platform and are concerned about continuing support from
third-party software vendors. As we've seen in the past when DEC
moved from supporting DEC Ultrix to Digital UNIX on Alphas,
third-party vendors may stop issuing new versions for that platform,
and may not guarantee that existing versions work across OS updates.
Meanwhile, IS is actively working to bring Linux and Windows NT into
the Athena environment, and we need to think carefully about how many
platforms we can support, given the constraints of staff resources and
the limited number of seats in the clusters.
CEASE examined various scenarios for the future of Athena-SGI,
including discussion of development effort (IRIX updates), cluster
renewals, and end-of-life for private workstations.
The most recently purchased cluster SGIs will reach the end of the
usual 4-year life cycle in summer 2003, roughly coinciding with the
time we have been led to believe that active support from SGI for the
O2 platform will cease. This time frame could be used to gradually
reduce SGIs from the environment as IRIX moves towards "maintenance
mode", allowing us a natural transition period for dependent courses.
In particular, it would be prudent to tie end-of-life for private
workstation support to cluster removal dates, so that the commitment
of staff resources does not extend beyond what is necessary for
academic support.
The application of development resources to future IRIX updates should
be decided in the usual Athena release forums and time frame, but some
general considerations are discussed in part III-A.
Athena first started supporting SGIs in response to particular
departments that use specific software applications only available on
this platform (MSI and BioSym used by Chemistry, Chemical Engineering,
and Materials Science, and Alias-Wavefront and Lightscape used by
Architecture). We have since installed several SGI-only applications
which do not appear to be used currently for courses. Appendix A summarizes usage data
for Biosym/MSI, Alias-Wavefront, and other license-manager-logged
applications (the Lightscape vendor dropped out of the SGI market a
couple of years ago; it now runs only on NT).
CEASE identified the following other categories of course use:
- OpenInventor (object-oriented toolkit for 3D graphics programming,
built on top of OpenGL). There are two main groups:
- EECS:
6.837 (100 students) will be dependent on this in Fall 2000, but
plans are to move to NT or non-SGI after that.
- Ocean Engineering: 13.003 and 13.472J each have
roughly 12 students.
- MIPS architecture: 6.035 builds compilers which generate MIPS
code, needs SGIs to run.
- Homegrown software built on GL (1995 and earlier): Architecture and
Materials Science.
- Homegrown software built on SGI audio: 8.03, part of one
assignment
Some faculty responded that they have moved away from previous SGI
dependencies including Aero/Astro and Civil.
We are aware that there may be other courses using SGI-only homegrown or
other non-commercial software installed in lockers which did not surface
from our contacts, but believe the above list captures the vast majority
of course dependencies, and that good publicity and general transition
strategies for homegrown software will address any others. Appendix B outlines the process used
to collect data on course use.
Independent of course use, the following benefits unique to SGIs were
identified:
- Easier to use removable media such as zip and floppy disks; can
read Mac formatted disks
- Integrated multimedia support; cameras; easier to play
audio/video.
- User-friendly desktop, drag-and-drop and other functionality
more intuitive than stock Athena for users of Macs and PCs.
- Graphics, particularly 3d
- O2s perceived as state-of-the-art machines (unclear whether this
ties in to above items, or taps into something else)
Athena-SGI deployment is as follows:
year of purchase
FY1997 FY1998 FY1999 FY2000 Total
Public* 44 0 22 27 93*
Depts 36 3 16 5 60
Staff/SIPB 12 1 9 2 24
---------------------------------------------------- ----
Total 92 4 47 34 177
* Public SGIs: 3 in lecture halls and 90 in clusters (including 20 in
4-035, which doubles as a reservable classrooom). There are no SGIs
among Quickstations or in Dormitory clusters.
For context, total Athena deploys are:
Public Cluster 416
Eclassrooms 60
Lecture Halls 13
Quickstations 27
Dormitories 18
Depts 395
Staff/SIPB 136
Notes on clusters:
- 4-035 is heavily used as a teaching space and for special events,
both for SGI-specific needs, and as a reservable Athena cluster.
Any long-term plan should take into account both sets of customers.
- The Rotch library cluster historically contained 8 SGIs; for
academic year 1999-2000, these were replaced by Suns (based on an
analysis of usage and responses from Urban Studies and Planning
and Architecture faculty
as to machine preference). We have received no complaints about
this change.
Stakeholder engagement:
- We compiled a list of courses, faculty, and departments known to use
Athena-SGI, and sent a questionnaire to 30
faculty/TAs/administrators from this list (see Appendix B). In
addition, Naomi Schmidt had already initiated discussions with
several key faculty and has begun follow-up conversations with
others on the basis of the questionnaire responses.
- The CEASE team included members from Athena Development and
Academic Computing Support. We identified the following additional
internal stakeholders:
- Cluster Services
- Athena Consulting
- Athena Server Operations
- Unix-VMS Help
- Training and Publications
and a representative from each group was interviewed by a CEASE
member to answer the following basic questions:
- to compare time and efforts on SGI vs Sun for comparable issues
- are there unique costs or pains to supporting SGI?
- what are values that are unique to SGI?
- anything more that you want to say
Information from
these interviews is incorporated throughout the report.
- Since the entire Athena user base is a stakeholder in any decision
regarding Athena ports and clusters, part of the team's work was to
consider how to assess and weigh use of SGIs outside of courses.
Feedback from internal stakeholders provided valuable insight into
several aspects of general Athena-SGI use detailed elsewhere in
this report; it was agreed that it would be appropriate to mention
this project at a recent public feedback session for Athena users
(see below), but no more formal polling of the non-course user
base was conducted.
The Athena Feedback Forum was an open event held in late October
to gather feedback from students on all aspects of Athena
clusters. Attendance was low, but the comments on SGIs
provided some anecdotal information:
- The different UI on the SGI bothers some folks
- On the other hand, many folks like the SGI GUI
(confirmed by OLC)
- All agree that a *uniform*, user friendly desktop on
*all* platforms would be nice (plus for Athena Desktop)
- Many SGI's appear to be dead when one enters a cluster.
Reply - they're not really dead, just powered off because
the OFF button is so obvious on the front.
Hardware
The unit price of an O2 as we have configured it has varied
between $4690 and $5610 over FY1999 and FY2000.
FY1999 47 machines $254,107
FY2000 34 machines $159,346
Total (2 years, 81 machines) $413,453
For comparison, below are prices for 81 machines from other vendors:
Sun Ultra 5 @ $2,867 ea $232,227
Sun Ultra 10 @ $3,733 ea $302,373
DELL Linux box @ $2,000 ea $162,000
There are no SGI-specific cluster infrastructure costs. (The same parts
are used to anchorpad O2s as other workstations, but in a different
configuration; the vendor did special design work on this, but did not
charge us for it.)
SGI Software
SGI Varsity Packs: We paid $20,000 in FY2000 for additional licenses to
match how many machines we have in the field (having underpaid
previously). This is a one-time, per-machine right-to-use license; for
private workstations, the cost is added to other Athena fees; for
clusters and IS-support machines, the cost comes out of the ACS software
budget. However, SGI allows us to "reuse" existing licenses from
retired systems as we replace them with new SGIs, so we would incur
additional costs only if we increase the number of SGIs.
Annual fees: We paid $10,000 in FY2000 to Unix-VMS-Help for our share of
MIT's license entitling us to annual upgrades of Varsity Pack software.
It's not clear what would happen if we had fewer SGI's in subsequent
years. The per machine cost might go up. Also, if the machines were
replaced by Suns, then our share of the Sun Software Library cost might
go up.
Third-Party Software
Pricing for software on multiple platforms is generally based on number
of users, not per platform, and thus replacing SGIs with an equivalent
number of other machines would have a minimal effect on cost. As far as
third-party software which runs only on SGIs (or which we currently only
license for SGIs), whatever particular alternatives we adopt to support
the courses depending on this functionality are not likely to cost less.
Support Costs Unique to SGIs
Supporting any additional Athena platform has numerous costs across IS
groups which are not enumerated here; below are large-scale costs
unique to SGI support.
Athena Development
- SGI software packages are tightly integrated into the base
operating system rather than being separable into convenient
modules for cleaner, faster updates and troubleshooting.
- Administration and maintenance tasks must be done with SGI-unique
tools rather than generic UNIX utilities. There have been
frequent times when SGI's utilities changed in ways profoundly
disruptive to their continued interoperability with Athena
administration tools.
- Patches cannot be installed individually to address specific bugs;
instead, one must take a complete patch release which, in addition
to required
bug fixes, includes many changes which have proved disruptive.
Aside from the
additional testing entailed by larger changes, there is also a
greater likelihood of triggering new bugs, and changes in
functionality often require the development group to code
work-arounds to maintain existing services.
- SGI has demonstrated a history of unwillingness to work hard on
problems we find significant unless a very strong case can be made
that the problem is solely SGI's fault.
- For a breakdown of areas requiring significant development effort
for recent IRIX upgrades, see Appendix C.
- A number of catastrophic hardware and software faults have
occurred with SGI systems over the years; the Athena employees
responsible for correcting these faults would not classify SGI's
systems as acceptably robust nor its assistance as acceptably
helpful. For an inventory of systemic failures (both Sun and
SGI), see Appendix F.
- SGI's support and maintenance model do not mesh well with what is
ideal for Athena.
Cluster Services
- Parts: due to high cost of SGI parts from Polaris, they deal with
SGI on parts swaps and thus need to maintain relationships with two
parts vendors and follow two separate processes.
- General: R5000 SGIs and the O2s don't pose great problems
the way the original R4600s did; reducing the number of platforms
would simplify support, but SGI vs. Sun differences are not
dramatic enough at this point to weigh heavily in the decision.
Athena Server Operations
- Server support: some third-party SGI-specific software requires a
license server running on an SGI; this machine is managed by ops.
This means that they must maintain expertise in supporting SGI as
a server platform in order to support a single, special-case
machine.
- AFS space: the IRIX OS volumes occupy a large amount of space; for
IRIX 6.5, the OS image is around 5 GB. This is not quite as
serious an issue since the AFS servers were upgraded.
- SGI-specific bugs: most notable was the problem where an SGI client
would effectively take down an AFS server.
- Updates: the slow update procedure requires special measures to
ensure that machines finish updating by morning.
Athena Consulting
- A significant portion of SGI problems are Indy-specific (i.e., do
not affect O2s).
- Rough ratio of total time spent on Sun vs. SGI support: 2-to-1 for
standard Athena; 2.5-to-1 for customized private workstations,
This is disproportionately high, given the rough 4-to-1 population
ratio of Suns vs. SGIs.
Jan/Feb Decide on IRIX version for Athena 8.4
(dev, release-team)
Mar/Apr Cluster renewal discussions
(vendors, Owls, ACMG, ITLT)
May Decide on cluster renewals, place orders
We have active discussions going on with SGI to enter into appropriate
non-disclosure relations and to get the clearest and most accurate
information of their plans. We will weigh the credibility of their
plans based on past experience and demonstrated changes in SGI's
behaviors. In the absence of explicit confirmation from SGI we have
evolved the following interpretation based on public statments and our
experiences:
We expect that over the next 12 to 18 months that we will be able to
continue to buy a machine substantially equivalent to the 300 MHz R5200
O2s we have purchased thus far.
We expect that over that same time frame that additional speed and
lower cost may be available in the O2 line.
However we also expect that soon SGI will offer as their preferred
product
in the low end, single user desktop workstation market a different
product line than the O2, embodying a different CPU than the R5000
series MIPS processor and a different operating system than IRIX.
We expect, that if we do not opt to migrate to that new product line,
the O2s would be actively supported with hardware spares, system
software updates, and SGI-owned application software updates for at
least four years after our purchase of those systems.
Even so, our overall expectation is that support for the O2 line would
degrade over that time as SGI shifts its focus to its Linux/Intel
strategy.
We compiled a list of third-party software which we have installed
only for SGI (aside from the SGI-supplied Varsity Pack applications).
From this list, we eliminated those packages which were known to be
available for Sun or Linux or for which we have source code. Summarized
below are the responses we received from a
survey sent to the vendors of the remaining packages. (See
Appendix G for the survey
questions.)
- Alias-Wavefront (Studio)
No reply to our survey. They are now owned by SGI though, and very
likely will follow the path taken by SGI software.
As noted elsewhere in this report, Studio is currently available for Solaris but
in any case Architecture is already looking at alternative software
(apparently for Windows).
- BioSym/MSI (InsightII, Cerius2, Quanta)
Responses were received from both a Life Science manager and
a Materials Science manager.
- Materials Science: a new, additional product line is being developed
for PC clients based on a client/compute server model. The server will
run on either Windows NT/2000, Linux or IRIX (as long as available),
the client on Windows 9x/NT/2000 only. Functionality from existing
Cerius2 and InsightII products are being migrated into this new
one. The process is expected to take 2-3 years, with support for the
old products (but no new development) continuing for that period.
- Life Sciences: similar to Materials Science but time frame lagging by
about 6 months. They expect Cerius2 use and support to continue for at
least 5 years. First release of new product expected by about end of
00. They will not be as tightly coupled to the Materials Science
releases as in the past, but will be "compatible environments".
NOTE: this implies no UNIX
clients for the new product; one important task for the proposed follow-on
project to examine the application server would be to determine whether
Pismere will be a viable client platform.
- Gaussian, Inc. (Gaussian)
Linux and Windows 95/98/NT supported now. Windows 2000 version
is planned (but they do not expect Microsoft certification). They do
not expect platform ("generic PC" vs. SGI machine) to be significant.
They currently support Solaris (and most other commercial UNIXes). They
plan to continue IRIX support "for forseeable future". SGI version does
not depend critically on OpenGL- substitutes (Mesa?) used "when
necessary".
- Schroedinger, Inc. (MacroModel)
Intel/Linux port almost complete, expected release 1/00.
Solaris port in process, expected completion date 3/00. No current
plans for Windows 9x/NT/2000 version at this point, but might do it if
demand warrants it. Hardware platform ("generic PC" vs. SGI machine)
not significant. SGI support expected to continue for about 3 more
years. New development will probably stop sooner, but details not yet
set. They use Mesa on Linux, and OpenGL on other platforms- no specific
"unique" SGI features are necessary.
Athena 8.3 (the current release) uses IRIX 6.5.3m.
It is highly unlikely that IRIX 6.6 would be released by SGI in time for
inclusion in Athena 8.4 (to be deployed in summer 2000). Instead, the
cost-benefit analysis likely to face Athena Development and the
release-team will be whether to upgrade to a patch release such as
6.5.7m in order to address bugs, security issues, etc.
In another year, it should be clearer what practical impact SGI's
phaseout plans have on IRIX releases between now and the time when they
officially go into maintenance mode. In addition, third-party software vendor
patterns should emerge, specifically whether new releases continue to
appear for IRIX, and whether there are any dependencies on particular
IRIX versions. Revisiting the state of course-dependencies at that time
should help in the cost-benefit analysis for future IRIX updates.
At some point, Athena may elect to freeze IRIX support at a particular
version and limit development effort strictly to maintenance.
In FY2001, the cluster SGIs up for renewal (i.e., 4-year old machines)
will be 44 Indys. The CEASE team explored five scenarios for these
seats in academic year 2000-2001:
- Replace all Indys with non-SGIs.
- Keep half of the Indys, replace half with non-SGIs.
- Keep all of the Indys.
- Replace half with O2s, replace half with non-SGIs.
- Replace all Indys with O2s.
Appendix D provides more detail on all five scenarios.
Based on information from internal stakeholders and responses from
faculty, we devised a grid to compare the relative impacts of the
above scenarios on the major classes of stakeholders, and the budget
(see Appendix E).
From this analysis, our recommendation falls between scenarios 2 and 3:
do not buy any new O2s, but retain at least half of the Indys for a
fifth year. If this recommendation is followed, then following the
usual 4-year replacement cycle in subsequent years would gradually phase
out all cluster SGIs as follows:
academic year Indy O2 total
------------- ----- --- -----
1999-2000 44 49 93
2000-2001 22-44* 49 71-93*
2001-2002 0 49 49
2002-2003 0 27 27
2003-2004 0 0 0
* depends upon whether we choose to replace up to half of the FY1997
Indys with another platform (e.g., Linux or Pismere).
Usual end-of-life for a particular platform is 18 months after machines
of that type were removed from clusters, in order to allow a long grace
period for private workstation owners to replace machines. Following
this model would mean that Dec. 2004 would be the earliest date we could
stop supporting Athena-SGIs. For example:
| June 1999 |
Billing letter says we will desupport machines of type A in summer
2000. |
| Summer 1999 |
We remove all cluster machines of type A and offer to upgrade
IS-granted machines based on proposals during 1999-2000. |
| June 2000 |
We bill for 6 months, saying things are only guaranteed to continue
working until Dec. 31, 2000. |
Alternatively, we could announce end-of-life for private machines to
coincide with (or follow more closely after) removal from clusters;
notices to departments could be issued earlier, to allow them ample time
to plan for replacement platforms or reversion to vendor OS. This would
allow us to provide the most robust support up to end-of-life, as
private workstations would not lag appreciably behind the general field.
There are a small number of machines (both ACS-granted and privately
puchased) which fall into this category, i.e. which end their normal
four-year life cycle at the same time that we plan to remove the
remaining R5000 Indys (Summer 2001) or the remaining O2s (Summer 2003)
from the public environment. ACS will confer with their owners to
ensure a smooth transition (e.g. through early renewal, or reversion to
vendor OS).
Another scenario we discussed was freezing development after cluster
removals, but giving departments the option of staying with the old Athena
release for an additional 6 months. This is not tenable as a
support option, however, as SGIs are historically more sensitive than
other platforms to infrastructure changes, and we could not guarantee
that they would continue to interoperate in the Athena environment
beyond the inclusion of IRIX in the development and testing process.
Additional/future materials for Sponsor/ACMG:
- Full text of internal stakeholder interviews
- Faculty responses on course use of SGIs
- Principles for Vendor Engagement in Discovery Projects (proposed
by Greg Anderson for Magellan -- maybe
from Bill; input from Alex?)
Last modified: Fri Jan 14 13:33:59 2000
ajfox