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 |
>> \------------------------------------+-------------------------/
|