Discuss

discuss@lists.centos.org

5 participants
34752 discussions

CentOS newbie question - updates
by Chris (CentOS list) 01 Jul '05

01 Jul '05

Pardon the newbie question, but I thought I'd check with you guys here since I couldn't find the answer to this one on CentOS web site. I installed CentOS 3.4 (needed an equivalent of RHEL 3.4 for a very specific purpose - not interested in newer releases at this point) and downloaded all available up2date stuff. However, Apache is at v2.0.46, php is at 4.3.4, and so on - which are all quite old versions. I was under the impression that Red Hat rolls updates into existing versions and what may show as Apache 2.0.46, may indeed include updates and patches that are available in the most current release, 2.0.54..... Is this the case here, with CentOS, or should I be looking somewhere for actual rpms for Apache, php, and so on, to bring them up to 'latest' standards? If so - where?? up2date doesn't seem to be loading anything more current than what I mentioned above. If current patches are rolled into old versions, how does one distinguish between the "old" Apache 2.0.46 and "new/patched" 2.0.46?? Thanks, Chris

3 3

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

Good, concurrent I/O design in a server -- WAS: SPARC platforms
by Bryan J. Smith <b.j.smith＠ieee.org> 01 Jul '05

01 Jul '05

From: Peter Arremann <loony(a)loonybin.org> > When have I ever argued about that chipset design is better? :-) > Opteron is a great example that you can do it better... > Where did you even get the idea I am fixated on that??? http://lists.centos.org/pipermail/centos/2005-June/007341.html "<even more anal>Except the iommu, those are limitations of chipset, bus and whatever, not EM64T.</even more anal>" It very much has to do with how EM64T differs from AMD64. GARTs and I/O MMUs are even more capable than the Opteron. The issue has not yet been forced on Intel _because_ they still use a "single point of contention" design. All CPUs share one bus, all memory shares another, etc... into a "hub" (with exception of a proprietary NUMA solution, but all I/O still goes through that MCH "hub" on even those designs). http://lists.centos.org/pipermail/centos/2005-June/007662.html "Lets be realistic here... all I/O on one CPU only makes a difference for the most IO intensive apps (talking several hundret MB/sec or more)..." avoid boards that attach all memory to one cpu - unless they cost .. so much less that you can add another gig or two in memory... I/O on the other hand, while not ideal, will have much lesser effect on your performance." This is very much an issue. If I have an OS that has processor affinity for I/O, like Solaris, on a partial mesh platform like most SPARCs (non-"i" versions), or the newer Opteron (with multiple AMD8131/8132 or even the nVidia Pro 2200+2050 combo), then I'm going to be able to handle _concurrent_ I/O for independent (and sometimes even inter-dependent) processors. You think of "raw throughput" like 8.4GBps FSB can easily handle a 0.5GBps transfer, but what you don't realize that the 0.5GBps transfer holds up the _entire_ 8.4GBps bus for _just_ 0.5GBps. I.e., it takes 1 second for a 0.5GBps burst from the I/O, which means you do _not_ "get the other 7.9GBps" while it's tied up. Now on workstations, not too much of an issue (except for when you need all: video, NIC, storage). And maybe not a web server where your Internet pipe is only 100Mbps. But if you are a major communications carrier, or even just a heavily trumped file server, near-line server (with both in-band and out-of-band connects), possibly multiple DB, etc..., it really _does_ make a _lot_ of different. http://lists.centos.org/pipermail/centos/2005-June/007668.html "The board: Asus K8N-DL" A board recommendation you ahd to quickly backtracked on after a post by myself. You even said: http://lists.centos.org/pipermail/centos/2005-June/007674.html "But give me some credit - after all it was you who threw out the $300 price mark and besides that, the original poster said he had no real IO requirements ... Completely agreed - spend the extra money if you want to build a serious server... " Which made me scratch my head, because there were other $300 boards with 8-16x the PCI I/O capability because they had an AMD8131. And that's just to start. Which is what these threads are all about, how to build high performance servers, which may not be the same as for yourself. The hot-plug thread, that's just the total icing on the cake because you can't possibly see why someone might want an old NUMA/SBUS platform. You can assume I'm "wrong," or go out-of-your-way to talk about it. But that's _not_ while I'm posting. I'm posting so people are aware that there _are_ applications where you _might_ want such capabilities. Your continued insistence in asserting there is no application whatsoever is what *I* have a "problem" with. It's not about "wrong" -- it's about what people _might_ need. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

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: Peter Arremann <loony(a)loonybin.org> > It is a valid benchmark though :-) compile speed is a actually a > good measure for any integer app that is small enough to run in > large cache... Image processing, oil companies for their simulations, > cad... they all act very similar to compile benchmark - if a compile > is twice as fast, a software image rendering is usually twice as fast > too :-) Now hold on. Did I just here you state that the ALU is used for CAD, and most scientific and engineering applications? Now I'll grant you that _some_ image processing _can_ be 32/64-bit integer transforms. But most high-quality, 64-bit precise transforms use the FPU. Not even Intel's SSE (on the P3/P4) is good when you need such precision. In fact, I don't know how many times I've caught errors because someone threw the "-O3" switch on "-march=p4". You do _not_ want to use SSE for scientific computing -- it's for when you want performance in exchange for loss of precision (let alone accuracy). > If you run databases or so, then yes, your comment is valid. Thank you. > Fair enough :-) And people say *I* go off on tangents. No offense, you were already in 2 posts before I even responded. If you look at other threads, I'm typically responding "OT" after 2-3 people have done so, and I largely see an inaccuracy, or I see a correction very much necessary. [ My posts on that thread _prior_ had just been to inform people that yes, there _were_ Xeon and Itanium systems with hot-swap capability. ] That's all I was trying to do in this case. Not "prove you wrong." -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

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> > US-V has been canceled... By Sun, yes. They believe they will transition to Opteron sooner than they thought. All I said was that it had been "planned through" US-V, including the design work done. My bet is that the engineers had finished the core design, even if not fully optimized, and that's when they were canned. It's still an option in the back of Sun's pocket. [ I.e., the core design occurs _years_ before products become available. E.g., even the latest Opterons are based on the 1997 core design. And until the Pentium 4 came out (just a refit), the Pentium 3 was still based on the 1994 Pentium Pro core. ] Fujitsu has yet to weigh in and possibly pick up the design. They have been designing SPARC modules (better ones IMHO) for a long time. All it takes is 1 customer who needs SPARC binary compatibility. There was an equal battle over the Alpha 364, with OpenVMS the driver. Especially since OpenVMS/Itanium was _slower_ (than an Alpha 264 from 3 years earlier no less!). But once [quality] emulators became available, that killed it. I don't think you'll see the same with SPARC, but I could be wrong. If the need by just 1 major user is there, you can be sure Fujitsu will come out with a PRIMEPower upgrade that uses the design. I never said Sun would release an UltraSPARC V, I just said it has been planned (i.e., designed). Sun has made it known that as of right now, UltraSPARC IV is the "end-of-the-line" for Solaris, and given how Solaris is working on Opteron, I don't blame them. But HP is _still_ selling Alpha 264s because of OpenVMS. ;-> A platform they have tried to kill off again and again and again. > US-IIIi is up to 4 way... I _never_ said it wasn't. I just said the 1-2 ways are comparable to a typical PC design**. But after 2-way, it's much better to go with a US-III or US-IV, kinda like it's much better to go with an Opteron instead of a Xeon beyond 2-way**. ;-> -- Bryan **NOTE: This is a recurring theme. You seem fixated on the assumption that a system that uses a single-point-of-contention design (namely the Intel MCH aka "northbridge") approach would _always_ be faster. You seem to lack the understanding beyond the real design contraints of a partial mesh interconnect on a real system interconnect (and not just a peripheral interconnect hacked on as a system interconnect). You have degraded most of my commentary as a "that's a chipset issue." You seem to have a very limited understanding outside of the traditional PC CPU-to-memory or CPU-to-I/O via a "chipset" and that's why you keeping missing my points on Opteron, UltraSPARC, etc... Not to mention this thread was just about finding a solution with hot-swappable components. I left it at that _until_ you wanted to assert all sorts of things (using "builds" as a benchmark for servers, even computational ones). -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss