Print

Print


I wonder what it means to certify. Results are the same? Results are the same _and_ CPU performance is no worse? Results are the same, CPU performance is no worse and memory requirements are similar? Anyone know? 

--
Charles C. Young
M.S. 43, Stanford Linear Accelerator Center       
P.O. Box 20450                                         
Stanford, CA 94309                                      
[log in to unmask]                                
voice  (650) 926 2669                         
fax    (650) 926 2923                       
CERN GSM +41 76 487 2069 

> -----Original Message-----
> From: [log in to unmask] 
> [mailto:[log in to unmask]] On 
> Behalf Of Wei Yang
> Sent: Thursday, April 12, 2007 6:01 PM
> To: atlas-sccs-planning-l
> Subject: Re: Notes of ATLAS SCCS meeting (April 11, 2007)
> 
> I also get a e-mail from Frederick Luehring saying that 32bit 
> Athena and
> SLC4 64bit are certified. So I think we are safe(?) to go 
> with RHEL4 64bit.
> 
> Wei Yang  |  [log in to unmask]  |  650-926-3338(O)
> 
> 
> Gordon Watts wrote:
> > Hi,
> > 
> >   At the software week before the one that just happened in Munich, 
> > there was a long report on performance issues on 64 bit machines. I 
> > suspect there was a recent update in Munich (I was not able 
> to attend).
> > The results three months ago were quite bad - if you used a 
> normalized 
> > performance scale it looked like the 64 bit processors were more 
> > expensive for less power, actually (but not by much). And 
> the memory 
> > usage was as you report below. The general message seemed to be to 
> > stay away from 64 bit.
> > 
> >   You might look through the Munich agenda to see if there was an 
> > update (they had just setup a task force at the previous 
> workshop to 
> > address the 64 bit issue). I'm about half way through the 
> agenda -- if 
> > I find anything I'll let you know. David Quarrie is a good 
> person to 
> > contact about this issue as well.
> > 
> > 	Cheers,
> > 		Gordon.
> > 
> > 
> >> -----Original Message-----
> >> From: [log in to unmask] [mailto:owner- 
> >> [log in to unmask]] On Behalf Of Stephen J. 
> >> Gowdy
> >> Sent: Wednesday, April 11, 2007 1:34 PM
> >> To: Wei Yang
> >> Cc: atlas-sccs-planning-l
> >> Subject: Re: Notes of ATLAS SCCS meeting (April 11, 2007)
> >>
> >> We can run the 32-bit applications on the 64-bit OS. Although I get
> > the
> >> feeling most sites are using a 32-bit OS also.
> >>
> >> It is almost certain that 2GB is not enough for the 64-bit
> > application.
> >> The memory usage is doubled and the 30% gain in CPU is 
> therefore lost 
> >> (a few times) in memory cost. There is an effort kicking off to
> > attempt
> >> to
> >> reduce the memory usage and try to understand why 64-bit 
> applications 
> >> is double (you expect some things to double, but not everything I 
> >> think).
> >> Not
> >> clear to me when the results from that will be available, certainly
> > not
> >> soon.
> >>
> >> On Wed, 11 Apr 2007, Wei Yang wrote:
> >>
> >>> [JohnB, Richard, Len, Wei, Randy, Booker]
> >>>
> >>> 1. DQ2
> >>>    corrupted AOD data removed. This gave us a few days of trouble
> >> free
> >>> production until today.
> >>>
> >>> 2. Tier 2 hardware
> >>>
> >>> Storage arrived waiting for memfs machines to free power. Current
> >> plan is to
> >>> reinstall memfs machines and then move them to Building 
> 84. So Atlas
> >> storage
> >>> schedule depend on the schedule of memfs machines:
> >>>
> >>> a) 10Gb, 1Gb network cables ready from Build 50 to 84
> >>> b) JohnY reconnected console lines to all memfs machines
> >>> c) Charlie is working on subnet and dhcp for the memfs 
> machines. To
> >> be done
> >>> today.
> >>> d) Lance is working on kickstart configuration for memfs machines.
> > To
> >> be done
> >>> today.
> >>> e) Shirley will install OS, probably tomorrow.
> >>>
> >>> Randy or Wei will start a installation request in RT.
> >>>
> >>> Once Atlas storage is powered on, Lance will install 
> solaris 10 x86
> >> and ZFS
> >>> on them. Wei will work on xrootd part.
> >>>
> >>> CPU nodes are also arriving/will arrive soon. Need to 
> decide OS (see
> >> below)
> >>> 3. Xrootd/srm
> >>>
> >>> No info.
> >>>
> >>> AOB
> >>>
> >>> Tier 2 web site: we will go with our own tech base and design. Wei
> > e-
> >> mailed
> >>> Chip of TIS to go ahead with the plan.
> >>>
> >>> At today's F&O phone meeting, Wei asked what OS will ATLAS use. So
> >> far, ATLAS
> >>> uses SLC3/4 32bit. Working on 64 bit (Boston is using 
> SLC3 32 bit).
> >> There are
> >>> memory issues running (32bit or 64bit app) on 64 bit OS. Need
> >> clarification
> >>> about whether 2GB/core is enough for 64bit OS (with 
> memory problem).
> >>>
> >>> We can run SLC/RHEL 4 32bit. But the OS will be slow, and yet we
> > have
> >> to
> >>> support another OS.
> >>>
> >>>
> >>>
> >>> Wei Yang  |  [log in to unmask]  |  650-926-3338(O)
> >>>
> >>> 070321 Gordon   Discuss perception of SLAC Tier-2 with external
> > folk.
> >>>           070404 no info
> >>>           070411 no info
> >>>
> >>> 070321 Wei      Send example new web page link to list
> >>>           070404  done, no feedback
> >>>           070411  Talked to T1/T2s. Will go with our own. E-mailed
> >> Chip
> >>>                   of TIS
> >>>
> >>> 061108 Richard  Discuss with SLAC Security longterm approach to
> > ATLAS
> >> VO
> >>>          061115 No information.
> >>>          061213 Nothing happened yet.
> >>>          070103 No information.
> >>>          070110 Richard & BobC in Denver, Stephen will email them.
> >>>          070124 Don't know the status.
> >>>          070131 Don't believe this happened.
> >>>          070207 Have not done this. Randy has talked to Heather,
> >> didn't
> >>>               have any time to comment today but she is 
> aware about
> >>>               it. Will treat each VO as an enclave, if 
> you are using
> >>>               anonymous accounts need to be able to show how ran a
> >> job
> >>>               and when. The main issue is that VOs are not legal
> >>>               entities and anyone can declare themselves 
> a VO. Would
> >>>               need to actually test that the required information
> > can
> >>>               actually be found.
> >>>          070221 No info.
> >>>          070228 No info.
> >>>          070314 No info.
> >>>          070321 No info.
> >>>          070404 No info
> >>>          070411 no info
> >>>
> >> --
> >>   /------------------------------------+-------------------------\
> >> |Stephen J. Gowdy, SLAC               | CERN     Office: 32-2-A22|
> >> |http://www.slac.stanford.edu/~gowdy/ | CH-1211 Geneva 23        |
> >> |http://calendar.yahoo.com/gowdy      | Switzerland              |
> >> |EMail: [log in to unmask]       | Tel: +41 22 767 5840     |
> >>   \------------------------------------+-------------------------/
>