Computer architectures and operating systems How many do we have to support in HEP

1
Computer architectures and operating systemsHow
many do we have to support in HEP?

• HEPCCC meeting
• CERN - 9 April 1999
• Les Robertson
• CERN/IT

2
Summary

• A claim that PCs with Linux and Windows are
  enough for all of HEPs needs
• An assorted collection of caveats
• A suggestion that HEP needs to begin to
  standardise platforms now, to ensure that we all
  have the same history when decisions for LHC are
  made
• A proposal for how to begin

3
What is likely to happen over the next few years?

• PC hardware
• cheapest, best price/performance, as fast as is
  needed
• Windows ----gt Windows 2000
• consolidating its 100M unit market
• Linux establishing itself as
• by far the biggest ever Unix
• the standard for Intel architecture
• Hard times for the RISC vendors

4
The Platform

• PCs are and will remain (one of the) best
  price/performers for HEP codes
• They may not be the fastest, but they will be
  fast enough
• Reliability and support are as good as for RISC
  systems
• even when buying from small European assemblers
• PCs get us into the REAL COMMODITY market, with
  benefits like -
• standard products
• competitive pricing support
• multi-sourcing (of a sort)
• choice of operating systems

5
The Platform - II

• A real choice of operating systems - with two
  complementary environments
• Windows for -
• productivity tools
• engineering applications
• mass market leverage
• Unix (Linux) for -
• server strength
• scalability
• preferred physics environment
• legacy applications (and experience!)
• (support of multiple architectures - but is that
  what we want?)

6
The Platform - Conclusion

• PCs with Linux and Windows are just fine
• price
• reliability
• usability functionality
• support
• Why would we need to support anything else?

7
Doing more with less .
March 97 - first PCs for physics batch April 99
- 200 PCs (400 processors) gt 50 of installed
capacity
8
The other side of the coin

• RISC hardware and software provide -
• Solid, reliable hardware, designed to maximise
  performance
• Industrial strength operating systems
• clear functionality spec
• performance-tuned
• multi-processor tested
• deterministic support, with clear escalation
  process
• Certified hardware software combinations
• Focus on system (as opposed to component) design
• and willingness to discuss product strategy,
  requirements, joint developments, etc. with HEP
  labs (or is that just a marketing ploy?)

9
Does Java change the landscape?

• SUN, Oracle, etc. propose light-weight Java
  stations
• Really low cost, with zero administration
• All the applications are down-loaded as needed
• Generally, there is a thin client, with all the
  smart stuff executing on a server
• .. but everything has to be written in Java
• Good for applications which naturally require a
  central server (e.g. database applications), or
  are naturally distributed (e.g. Web browsing)
• Not so obvious for applications that do not have
  a natural client-server model, and/or use
  multiple languages (like most HEP applications)
• There is some argument about Java being more
  portable than other languages and there are
  other positive aspects of it as a language

10
Does Java change the landscape?

• low cost Java stations will keep up the pressure
  on Wintel
• but otherwise, for HEP applications and HEP users
  .

NO
11
Is Linux ready for HEP?

• Linux and the rest of Free Software offer
• high quality design
• excellent functionality
• the products of massive intellectual investment
• a sustainable environment - its free because
  the development support are contributed by the
  user community, not because the developers do not
  get paid
• The functionality as a desktop system, or simple
  server are fine but many
  proprietary Unix systems have much better server
  functionality however, the
  evolving farm models place limited requirements
  on data servers
• Linux tape and disk server evaluations at CERN
  look promising

12
Is Linux ready for HEP?

• Support is still a problem
• especially for load-related, configuration-related
  issues on servers
• But there is a rapidly growing number of
  commercial offerings (including IBMRed Hat,
  HPRed Hat)and HEP could probably justify a
  kernel programmer or two (since there is no
  licence fee for the OS)
• Lacking third party products
• or well-supported ports of third party products
  (and in particular Objectivity)
• changing fast - but this is clearly still a
  concern

13
Is Linux ready for HEP?
Not quite for all applications, but it looks very
promising
14
Are we sure that Linux is the right choice for
Unix on Intel?

• No - we cannot be surethere will be competition
  from the suppliers of proprietary Unix (Compaq,
  IBM, HP)Linux is the clear and growing leader
  today - it will be hard to beat

15
Do we also need Windows?

• The majority might say No
• Windows is hard to use for physics batch,
  especially when we try to make it look like Unix
• It probably is not much better (maybe even worse)
  as a server than Linux
• Support for complex environments is not any
  clearer
• But there are so many excellent productivity
  tools and applications sustained by the 150
  million unit Windows market
• How can people get by without Developers Studio?
• How can Star Office keep up with MS Office?
• .
• How can we ignore the biggest ever operating
  system, just as the various versions come
  together in Windows 2000?

16
Did we forget about the Mac option?

• No, it is not really an option
• Or is it?

17
An opportunity for standardisation in HEP
requirement

• We (HEP) are running far too many operating
  systems, in many cases with only slightly
  different functionality or hardware cost benefits
  - - and at a high cost for users and support
  teams
• PCs Linux Windows offer an historic
  opportunity to reduce the solution set
• The requirements of LHC computing -
• massive numbers of processors/boxes
• integration of regional computing centres and
  CERN
• demand a common agreement on what will be
  supported
• We need to start the dialogue now, to avoid the
  old problem of history dictating our choices

18
Proposal for a policy

• Restrict ourselves to PC hardware
• with Linux or Windows 2000
• Develop a migration plan -
• progressively freeze support for other Unixes,
  announcing end-dates which are reasonable for
  old experiments,
• but discourage strongly further investments in
  RISC systems by current and future experiments
• Beef-up investment in Linux and Windows
• bring support up to the standards of proprietary
  Unixes
• tackle the problems of scaling the management and
  performance of desktops and physics farms
• engage HEP in the community
• emphasise the importance of minimising
  differences between HEP labs
• Focus on the Web as the user interface

19
Just to be clear ----

• This is a proposal for a convergence policy
• which looks realistic now
• and will provide a single starting point for LHC
  computing
• but we can be sure that the business will not
  stand still, and we shall sooner or later have to
  expand the systems and architectures supported

Digital Unix
SPARC
AIX
MAC-OS
WNT
- - - ?
Alpha
Linux
Intel IA-32
Intel IA-32/64
Solaris
Irix
Windows 2000
Windows 95
MIPS
Power PC
Linux
HP-UX
PA-RISC
20
Conclusion

• PCs, Linux and Windows 2000 enable a major
  simplification of the environments supported for
  HEP, where our needs mostly coincide with those
  of many other users
• We should take the decision to standardise on
  these within HEP - following and stimulating the
  mass market in most cases - restricting HEP
  specials to really, really special issues
• And we should start talking now about how LHC
  computing centres evolve to a standard approach
  which enables them to work with each other