The main issues were in various bits of LCG-packaged software - boost was one that I remember being mentioned. The current gcc defaults to P4 optimisations, and so many libraries are practically untested with P3 code generation - so in a sense, the issue goes even deeper than Bob mentioned about SSE: even rebuilding for P3 (quite a substantial effort in itself) may not necessarily produce verifiably, correctly working code. While catching the occasional crash is painful enough, the doubt of unknown, non-fatal issues was the nail in the coffin for our legacy P3 SBCs.
Cheers, Sergio On 22 December 2014 23:52:06 CET, Robert Blair <[email protected]> wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >We don't run firefox (imagine the performance) or the like on them >either, but we do run our DAQ runcontrol bits and pieces on them and it >was there that we had problems. I sort of remember it being the lack >of >SSE2 that produced the problems we saw. That usage was buried deep in >some support libraries. > >On 12/22/2014 03:15 PM, Konstantin Olchanski wrote: >> On Mon, Dec 22, 2014 at 09:20:28AM -0600, Robert Blair wrote: >>> >>> Some experiments (ATLAS as a for instance) have decided to simply >>> upgrade their SBCs to 64 bit capable rather than suffer through the >>> various problems associated with trying to hang on to the old >hardware. >>> We saw issues beyond just 32 bit vs. 64 bit. The older systems >were >>> many generations back in terms of capability which caused numerous >hard >>> to diagnose problems. In our case the pentium4 default broke some >code >>> since the SBCs we had were pentium3 only. Most things worked but a >few >>> applications simply crashed. The cost of upgrading was lower than >the >>> human cost of finding and fixing this sort of thing. >>> >> >> Ahem, we see no special problems with running SL6.6 on Pentium3 >(1GHz, SDR RAM) >> and 32-bit Athlon (DDR1 RAM) machines, even with low ram (0.5GB >typical). Most >> problems we do see are rooted in the old "laptop" chipsets used by >these SBCs >> that were never properly documented by Intel and properly supported >by Linux. >> >> But of course we do not run any full-featured applications (firefox, >etc). >> >> Upgrading to new hardware depends on the depth of your pockets of >course, >> but we also see technical problems - some new 2GHz+ 64-bit SBCs >overwhelm >> power supplies originally built to run 0.1GHz motorola 68020 SBCs. >Also they are much >> more sensitive to good air flow for cooling. Also we see a very high >failure >> rate of our chosen 64-bit VME SBC (vendor unnamed, suspect faulty >PCBs or bad BGA soldering). >> >> K.O. >> >> >>> >>> On 12/18/2014 02:59 PM, Ian Murray wrote: >>>> On 18/12/14 20:16, Konstantin Olchanski wrote: >>>>> On Mon, Dec 15, 2014 at 04:51:19PM -0800, Keith Lofstrom wrote: >>>>>> Again - the reason for 32 bit is not that I cherish old CPUs ... >>>>>> And that is why I ask here; if anybody runs old machines for >>>>>> compatibility reasons, it would be experimental scientists ... >>>>>> >>>>> On target you are. >>>>> >>>>> Us experimental scientists have embedded computers (VME form >factor) >>>>> with 32-bit CPUs and 0.5GB/1GB RAM. We run 32-bit SL4, SL5 and SL6 >>>>> on them today and I expect we will still be using these machines >>>>> when SL6 becomes obsolete in 1-2-3 years. By then, I fully expect >a 32-bit >>>>> port of SL7/CentOS7 to become available, somehow. >>>> Some talk of it here, with people having a first pass at it:- >>>> >>>> http://www.karan.org/blog/2013/12/15/where-is-the-i686-in-rhel-7/ >>>> >>>> >>>>> >>>>> But for today, I have not even digested the 64-bit SL7 yet, 32-bit >SL7 >>>>> is not even on the wish list yet. >>>>> >>>>> Now, the ARM SL7 is a different matter. *that* I want yesterday. >>>>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2.0.14 (GNU/Linux) >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>> >>> iQEcBAEBAgAGBQJUmDa7AAoJEPQM1KNWz8QalnEIAMaCjtomFbU/xDLyhCtIzKWb >>> F48m7wjIS7QHJgmBarj40Oz7jCS6XIJz5VtXD2hh4WwwZsgnvLZvx5fy3bCKZ8xC >>> /36MXaXCHeNBVr1KtgZDAedYpWVoJgn21t3yWlQnEjxiPqBFZogJRAU/ISrscXwJ >>> vWCX7E1u8vwNUmBjUkYedNrWqcFUYDtFDIwkKXTqL4H4TZkBce4pDbpkYc607kIx >>> h8G5EGBgDGc8MatkWrcCz2ISZI939USlzc0YLjDDfYIMN1zYaRwSS9zlpfmueG+/ >>> eQifhTtJ2bHB6tG3LKxrPTx5t8pZJDSTmtcYtjzHCkEJuTDSpxulopj9jaaXyM8= >>> =Es3t >>> -----END PGP SIGNATURE----- >> >>> begin:vcard >>> org:Argonne National Lab.;HEP >>> adr:9700 S. Cass Avenue;;Room F-213, Bldg. 360;Argonne;IL;60439;USA >>> title:Physicist >>> note;quoted-printable:Personal PGP key available at >https://www.hep.anl.gov/reb/key.asc=0D=0A= >>> DOE certificate available at >https://www.hep.anl.gov/reb/certificate.asc >>> url:http://www.hep.anl.gov >>> version:2.1 >>> end:vcard >>> >> >> >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v2.0.14 (GNU/Linux) >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >iQEcBAEBAgAGBQJUmKCVAAoJEPQM1KNWz8QauKIIAMSoM5O0iKyeOUA+gqhKy+2Q >xfM3pfWNtv20oP8iU8DEXYE7UBuzeiPtkuoFujA08eNOztWS/1cjDk4+JdqY5kwX >WGXeZNQ3H0QD66yTVNYHUg7YYIFeHCIrU+vROMwvRdN0HLJb4blu8qUCAWGOVlBM >NfJx4QqB8NgfSRJ1bbV6kahEh5LrRHvGqYI11WLQiOi0ZBVgU5qobgVre8F7FTMT >JbxQa9I5gWvnB4Gq8dlSDTFklAqfabZiIuXA5x+3a7inlkJ5SaqLUQlA08rjovZI >ZoMzzlYGD9HXmp3cSE6giIBiOKicR9iRYpjIRUX1iCv3ZykZHcH1CSPQXIpME4k= >=4nNz >-----END PGP SIGNATURE-----
