Discuss June 2005

discuss@lists.centos.org

197 participants
362 discussions

RE: [CentOS] [OT] SPARC platforms -- WAS: Hot swap CPU
by Bryan J. Smith <b.j.smith＠ieee.org> 01 Jul '05

01 Jul '05

From: Peter Arremann <loony(a)loonybin.org> > Sun will very willingly support all certified solutions (including EMC, netApp > or Hitachi for storage) as well as provide some support with uncertified > hardware for us... no issues... You work in a Fortune 5, they will do anything you tell them. I've been there before, and that is a very nice position to hold. But not when you work for a 50 engineer semiconductor startup. Sun really pissed us off regularly, so we stuck with Fujistu. > Yep - but how is that a benefit if your stuff works? NVidia is fabless i.e. > and you surely don't want to tell me they aren't good at what they do... > Having your own fab or not has very little influence... I was just saying that anyone who only wants to go to Sun because they are behind SPARC might consider Fujitsu, who actually fabs the chips. I've walked into many shops who have had issues with Sun's support and they never knew about Fujitsu as an option. That's all. > Sbus ???? Now you're talking US-I/II again - and that is absolutely > no match for an opteron box... Sorry, I meant NUMA/UPA -- my bad. > Based on what? The Implementation of Solaris for AMD dates back to SE b68 or > 69... that's mid 2004... Compare that to an OS that already ran on the > software emulator before silicon was even out there... Solaris was _also_ running on the x86-64 emulator too. ;-> AMD and Sun were in negotiations before the first Opteron came out. > Solaris 10 on AMD64 is definitely less stable that Centos 4 on the same v40z... > Running the same apps we had 0 crashes with Linux vs. 2 explained and > patched, 1 explained still unpatched and 1 unexplained crash on Solaris10... I meant the design: "given its experience on partial mesh interconnected systems" I thought by putting that in the _same_statement_ you'd see what I meant by "mature." Sorry, I assumed wrong. ;-> > Why would you need to run on sparc to produce a stable OS for an opteron box? Re-read my full statement ... 'Solaris is probably the most "mature" OS for Opteron 200/800 right now, given its experience on partial mesh interconnected systems.' -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: [CentOS] Re: Hot swap CPU -- "build" is not a good CPU benchmark
by Bryan J. Smith <b.j.smith＠ieee.org> 01 Jul '05

01 Jul '05

From: Chris Mauritz <chrism(a)imntv.com> > <snipped> > Oy....I'm terribly sorry. Moderator, please delete my previous > message. It was supposed to be a private message to Peter. Bryan, > please accept my apology. It wasn't my intention to riducule you in > public. honest injun.... > <blush> > Must drink less coffee.... No apology required, everyone is entitled to their opinion. As far as this "thread," I think it's rather pathetic that I'm the only one being singled out when someone like Peter can take anyone's suggestion and just rip it out-of-context. Makes me wonder if Bruno is hesitant to post any suggestion again ... http://lists.centos.org/pipermail/centos/2005-June/007936.html http://lists.centos.org/pipermail/centos/2005-June/007937.html http://lists.centos.org/pipermail/centos/2005-June/007956.html http://lists.centos.org/pipermail/centos/2005-June/007974.html From: Peter Arremann > That is exactly what I said before you trimmed it off :-) No, you said ... "Compiles aren't a great benchmark for a box since its 100% cpu and neglects memory or disk performance but I had the numbers handy for that :-)" And you continue to assert that it _is_ a valid benchmark for computationally intensive server applications in your countless other posts. "Builds" _do_ often take memory and disk into account (especially memory latency, which _can_ actually be worse on P4 DDR2 platforms than some old EDO platforms ;-). I was just trying to "open your mind" to the fact that there _are_ applications where an 8-way, NUMA/SBUS solution _might_ just be usable. Maybe not for you, but for some applications, especially at the price point. That's _all_ I was saying. I noted others were also trying to give statements that were good reasons. You may think they are not solutions worth the power, but not all of us agree with you. That's _all_. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

RE: [CentOS] [OT] SPARC platforms -- WAS: Hot swap CPU
by Peter Arremann 30 Jun '05

30 Jun '05

Bryan J. Smith b.j.smith at ieee.org wrote: >Not only that, but people forget that SPARC is not sold by just Sun. >SPARC is an IEEE standard licensed under "fair and non-discriminatory" >terms. The SPARC ISA and most architectural details are freely >available. Yep - but what is your point with bringing that up? >The _majority_ of my Solaris/SPARC experience in more recent years has >been on Fujitsu/HAL solutions. I not only prefer the Fujitsu/HAL >products over Sun, I not only prefer Fujitsu's "openness" to support >SPARC solutions with non-Fijitsu networking, storage, etc... attached >(whereas Sun likes 100% Sun equipment from a support perspective) Sun will very willingly support all certified solutions (including EMC, netApp or Hitachi for storage) as well as provide some support with uncertified hardware for us... no issues... > but >Fujitsu has taken over packaging design and fabrication of SPARCs for >Sun itself. I.e., Sun used to design their own SPARC packages and TI >was their foundary, but Fujitsu has almost always designed their own >SPARC modules/ daughtercards, and fabbed them themselves. Yep - but how is that a benefit if your stuff works? NVidia is fabless i.e. and you surely don't want to tell me they aren't good at what they do... Having your own fab or not has very little influence... >Sun even >sells Fujitsu PRIMEPOWER products on their site now. They don't - they had info for it a while ago but even that has been removed. >sun4u (UltraSPARC) is planned through UltraSPARC V US-V has been canceled... >, with UltraSPARC III >(and lightweight IIIi) and IV available today. The 1-2 way UltraSPARC >IIIi is more comparable to the cost/design of the Pentium III and IV, as >well as the Xeon. US-IIIi is up to 4 way... >The UltraSPARC III and IV, and their platform, are >_clearly_superior_ to even OEM proprietary NUMA Xeon implementations Yep >(you really have to start looking at proprietary IA-64/Itanium II to get >a good comparison). > >But the design of the Opteron is why Sun is moving forth with it's move. >The typical UltraSPARC NUMA/SBUS server architecture really doesn't >offer much over Opteron in a 2-8 way. Sbus ???? Now you're talking US-I/II again - and that is absolutely no match for an opteron box... >And to be honest, Solaris is >probably the most "mature" OS for Opteron 200/800 right now, given its >experience on partial mesh interconnected systems. Based on what? The Implementation of Solaris for AMD dates back to SE b68 or 69... that's mid 2004... Compare that to an OS that already ran on the software emulator before silicon was even out there... Solaris 10 on AMD64 is definitely less stable that Centos 4 on the same v40z... Running the same apps we had 0 crashes with Linux vs. 2 explained and patched, 1 explained still unpatched and 1 unexplained crash on Solaris10... >Linux will get >there, but it takes time and experience on a platform like SPARC >(Windows never well, not even thanx to SGI's past, although brief, >donations). Why would you need to run on sparc to produce a stable OS for an opteron box? Peter.

1 0

What is the latest STABLE release?
by M.C. Luigi Palmiero 30 Jun '05

30 Jun '05

Hi all, i want to install CentOS on my server in production. What is the latest stable release? Thanks Luigi

3 2

Re: Hot swap CPU -- "build" is not a good CPU benchmark
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: Peter Arremann <loony(a)loonybin.org> > Compiles aren't a great benchmark for a box since its 100% cpu and > neglects memory or disk performance but I had the numbers handy > for that :-) BTW, it is 100% ALU and a major strain on the ALU LOAD. In other words, it's not a good benchmark for even CPU. That's why the 3-issue ALU in the Nx586 on-ward blows the 2-issue ALU in PPro on-ward (especially the P4) to crap. But that's all besides the point because it has _0_ to do with server performance period, even computationally intensive. -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 3

Re: [CentOS] Hot swap CPU
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: Peter Arremann <loony(a)loonybin.org> > Actually that was exactly the point. The email I responded to was > mentioning ancient US-I/II frames as a solution for the hotswap issue. My > point was that for the same cost I can get a 8way E4500/400/4MB or a nice > P4 PC... > From the speed perspective you'll be hard pressed to find an app > that is faster on the sun and the age of the E4500 negates any advantage > it used to have in reliability. The E4500 doesn't even have redundant > power :-) Be careful with your continued assertions. I/O on the P4 (and the PC platform) _sucks_ compared to many of these solutions. PCIe is _not_ the "holy grail" for a platform that has some severe bottleneck issues in its design, let alone when we're talking a single processor versus a partial mesh system with a _real_ "system interconnect." ;-> Reality: Even a 200MHz, non-superscalar microcontroller prototype boards can handle 500MBps+ of storage I/O, but many PC mainboard I/O designs can_not_. ;-> > I was giving the E4500 as a comparison because it costs the same. > Unfortunately we got apps here that outgrow F15K frames - performance > can't ever be good enough. > But even if you get a V440 (from integer processing the currently fastest > cpu Sun has to offer) you're still so much slower when doing compiles. Once again, I will re-iterate, build times are _not_ a good "server benchmark" at all. If they were, then I don't know why _anyone_ would buy Intel -- AMD _roasts_ P4 _over_ 2:1 MHz for MHz. > Anyway, point I was trying to make is that if anyone points a US-II based > frame today they are mistaken about its performance and reliability. I don't think people were asserting "build" time at all, let alone performance in general. But there are some advantages to deploying even older SPARC platforms in some areas. It's obvious your experience has largely been in "build" or "dynamic web app" benchmarks. Please be considerate that it's not the _only_ "performance" consideration out there. ;-> > Just the disks in D1000 trays are so much of a headache that you > wouldn't believe it. And Sun doesn't support booting of EMC on the > smaller frames - so you need some local attached storage... There are options around that in various hardware selections. But yes, Sun does have some stock SAN limitations. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: Directory Server for CentOS 4.1
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: alex(a)milivojevic.org > Nope. On Windows during login users usually selects domain part from > drop-down box (yes, you can type it too if you want). [ Not that this matters, but ... ] First off, that's _only_ for the GINA portion, and not always. Unless you take the time to distribute all domains either at the server or client, you won't always see all domains. Secondly, inside of various apps, credentials are not always passed correctly, which requires the nomenclature. Of course, the application can save the username and other settings in the application itself. E.g., try to login to IIS' FTP server when you have multiple domains. ;-> You'll have to pass the DOMAIN/user nomenclature in many cases. > And usually whatever domain is selected in that drop-down box by > default is the correct one for the owner of the particular PC. [ Again, not that it matters, but ... ] And the same can be said for applications on a UNIX system with a particular user's login, and their configuration files (and mounted home directory -- you are automounting home directories, yes?). I'm kinda scratching my head here. I can setup a user's IMAP credentials in various applications (both Windows and UNIX/Linux) to remember their username for the setup, so that is avoided. I don't see the difference between multiple REALMs and multiple NTDOM/ADSDOMs. If you properly configure the login/apps to remember the user's domain, then it's not an issue. > Anyhow, historically real Unix accounts were used on email servers, > so after switch to virtual accounts requirement was that users don't > notice the change. Higher authority decided that it would be too > complicated for non-technical population to swtich from "username" > to "username@REALM". [ Lastly, also mot that it matters, but ... ] What are you using multiple REALMs for anyway if everyone was under a "real UNIX" account before? NOW WHAT MATTERS ... _Please_ read up on how NsDS works. It's _extremely_ "enterprise class" and much more capable than OpenLDAP, which was more of an "open framework" of different capabilities (not always well integrated). http://www.redhat.com/docs/manuals/dir-server/ag/ssl.htm "Netscape Directory Server Administrators Guide Chapter 11 ... Configuring Kerberos Kerberos v5 must be deployed on your system to utilize the GSS-API mechanism for SASL authentication ... ... Realms A realm is a set of users and the authentication methods for those users to access the realm. A realm resembles a fully-qualified domain name and can be distributed across either a single server or a single domain across multiple machines. A single server instance can also support multiple realms. Realms are used by the server to associate the DN of the client in the following form, which looks like an LDAP URL: uid=<user_name/[server_instance]>,cn=realm,cn=mechanism,cn=auth " Is that more of what you were looking for? How to put the Realm in the uid? -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: [CentOS] Directory Server for CentOS 4.1
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: alex(a)milivojevic.org > As I said, there are multiple domains, so IMAP server can't simply slap > @REALM to the end of user supplied username and do the check directly. Ahhh, a key point I missed. My apologies. > For historical reasons, IMAP server uses flat userspace (while in reality it > is more tree-like). And nope, having users type the @REALM part during > login is not acceptable solution (most of them don't even know what > @REALM should be, nor should they be bothered with such details). Hmmm, most usrs have to do DOMAIN/user for Windows DCs so I don't know how "unacceptable" is is to require "@REALM," but that's just my view. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: Software RAID muck up
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: Dan Pritts <danno(a)internet2.edu> > I just looked at that a few weeks ago - it doesn't seem to have reached > critical mass. Would sure be nice. Oh, it _has_ reached "critical mass" among a lot of embedded and application-specific capabilities. But like most distribution channel issues, you can be sure that AMI, Phoenix and others are fighting it quite hard. Even Intel's so-called "open" initiatives are still in the "tight knit group" of BIOS vendors. And Microsoft would love nothing more than to make it impossible to access system configuration outside of Windows, Windows systems unable to boot be damned. Most hardware vendors are _also_ more than happy to see this, because they can start tying hardware to specific Windows versions. Hence the entire "superstore" hardware/distribution issue that will always plague Linux and partnerships to create Linux drivers. > heck, i'd settle for getting serial-bios capability out of commodity > motherboards. "server" systems (and maybe high-end "workstation" > motherboards) have it but things like the via c3 boxes i have posted > about before generally don't. I'm waiting to see what Apple cooks up. They won't share it, but it will possibly create enough stir to change the industry in general. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Re: Installing Dag's RPMs
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: alex(a)milivojevic.org > Which is the smallest problem with Sun'S Java. They don't do "alternatives" > either (you have to set them up manually, if you want to have GCC's Java in > parallel). And Sun's license doesn't allow anybody to repackage it so that it > blends with the rest of the particular distribution (basically, fixing the > problem you had and the alternatives issue). Yeah, that's the #1 issue most everyone has with Java. Sun allows the JRE to be bundled with Solaris and Windows applications, but not Linux. And you have to be the size of Red Hat or SuSE to negotiate otherwise, and that's just for retail distributions. If they SCSL/whatever it into an MPL-like, that should change though. Java seems to be the _only_ thing Sun hasn't GPL'd or at least MPL'd. While I can understand some aspects of their viewpoint, the explicit denial of redistribution on Linux is just entirely inexecusible when they allow it to be bundled with Solaris and Windows applications (let alone the OSes). -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss June 2005