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