Discuss

discuss@lists.centos.org

5 participants
34752 discussions

Getting Mailman Running
by John Hinton 26 Jun '05

26 Jun '05

On a CentOS 4 box, I'm trying to get Mailman running. I found the apache conf file in /etc/httpd/conf.d and set the servername in that. When I try to go there, I get a 500 internal server error.. when I try to start Mailman, I get Starting mailman: Site list is missing: mailman I've never run Mailman before.. looked in the /etc/mailman/sitelist.cfg.. don't see anything in there that needs to be set. man mailman shows no entries..... I installed it via rpm at server install time. I am running sendmail. python is installed... I can't seem to find much to help. Thanks, John Hinton

2 3

Re: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 26 Jun '05

26 Jun '05

From: Peter Arremann <loony(a)loonybin.org> > Then the first AnandTech benchmark article > (http://www.anandtech.com/IT/showdoc.aspx?i=2447) is exactly what you want to > look at. Huge amount of memory (when compared to the size of the database > running on the system) on a 64bit linux kernel... > We're doing the same for one of our apps called IPM. Its a PHP app running > against a quad opteron with 16GB ram. Heavy on network IO (during business > hours its rare that we don't saturate the main 100mbit link) but little disk > activity. DB size is about 2.5GB and we end up with a couple of gig for disk > buffers. CentOS4 of course... anything specific you're looking for? I think I know where you and I are differing. When you talk about "heavy [network] IO," you refer to SQL-based applications over a primary 100mbit link. In reality, the MCH bottleneck isn't much of an issue here. When I talk about "heavy [network] IO," I'm typically referring to less intelligent applications (e.g., NFS or other "raw block" transfer) over one or even multiple GbE, possibly FC-AL links (possibly direct IP, link agregated IP, maybe 1 out-of-band channel, or possibly to a Storage Area Network, SAN). Although I have built financial transaction systems that have required GbE as well as engineering. I guess this is where my terminology really differs. A lot of people are using Linux for Internet services. I've typically been using Linux for high-performance LAN systems -- both "raw block" as well as intelligent applications. My Internet connection is not my bottleneck. BTW, despite popular thought, this can be done quite inexpensively when needed. It really all depends. But in these applications, definitely _not_ going to see Opteron doing much for you over Xeon. Let alone not when running Linux or Windows (Solaris might be another story though). -- Bryan P.S. Just a follow-up, _never_ assume you're the only EE in a thread. [ Let alone don't assume I haven't designed memory controllers as part of my job, beyond just my option in computer architecture. That's why I had to "give up" in the other thread, because everytime I try to explain something, you are going to a very simplified path and I have to stop and explain it (e.g., the fact that IA-32/x86 _can_ address beyond 4GiB). ] -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 25 Jun '05

25 Jun '05

From: Peter Arremann <loony(a)loonybin.org> > Actually apps like the one I was referring to showed about 50% > single thread performance gain when going from a 2.4GHZ Xeon > to a 2.2GHz Opteron. That's not a good comparison because the ALU-Control of the Athlon is about 50% faster MHz for MHz than P4-Xeon. So that could easily be a computational benefit and not an interconnect one. > Never assume you've done more more than others either :-) I didn't. > I've done the more difficult job with finding all the applicable documents Dude, you did _not_ send me any documentation I have not already seen. I have been using developer.intel.com years in my semiconductor design career, as well as more of an IT-level system designer. The problem here is that you can't seem to understand that a trace does _not_ indicate how something actually works in the memory logic. E.g., the existence of trace does not tell you if a normalized address that results in a PAE36 (>4GiB) address is going to either: A) Directly drive that trace and fetch for the process to use B) Be intercepted by the paging logic, referenced in a page table, then _that_ logic actually fetches the memory, which is then mapped into <4GiB for the process to use It's not just the simple trace, and it's not just the simple, programmer-level logic. If Intel PAE36 processors didn't have address lines above bit 31, they couldn't address above 4GiB at all! But just because they have those traces doesn't mean they can directly use them. First you looked at it from the "programmer" level, then you looked at it from the "board technician" level. Now I'm tell you _get_in_the_chip_! > while you just put out hearsay and "doesn't work like that" statements > without really backing it up. And yes, IA-32 _can_ address more than > 4GB - called PAE. Exactly! What I'm telling you is that _all_ Athlon "32-bit" processors can by-pass PAE36, and significantly _increase_ performance at the page table level. But it requres the platform be configured in a way that is _incompatible_ with all OSes _except_ a hack for Linux. This is rare, but it has been done in a few mainboards. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 25 Jun '05

25 Jun '05

From: Peter Arremann <loony(a)loonybin.org> > Then enlighten me - if I have 40 address bits - transmit only the higher 37 > since I don't need the lower end. Timing schemas show only one Input hold > time per address transfer for all available pins - how can that be a 32bit > bus? (ftp://download.intel.com/design/Xeon/datashts/30675401.pdf) Once again, stop assuming a trace and its specifications for board layout means that memory is directly addressable over those pins. We could go on that all night and for days, and I can give you countless examples of embedded, PC and other memory controllers, memory technology, etc... where paging and other "swap" is required. Heck, as an EE, I would ass-u-me you would have been exposed to memory controller design. It is a complex mess whereby each new change in addressing exponentially increases the transistor count. > And, if timing diagrams, pinouts and so on lie about the size of the bus, > ... cut derrogatory non-sense ... *STOP* This is why I can't even begin. I _never_ said that Intel didn't offer 64GiB (36-bit) memory addressing. The traces _must_ exist so Intel can on [A]GTL+ platforms, but it does not mean that there is not some "paging" going on at the memory _logic_. I just said it cannot address it linearly -- directly by 36-bit -- in the GTL design. It all goes back to Intel's belief that IA-64/Itanium would have taken over the i686/GTL world by now when it decide not to build a new architecture for IA-32 back in the '90s. A belief that Intel has not been paying the price for, and quickly retrofiting everything it can ASAP. AMD decided to switch to EV6 instead as its foundation for _all_ current processors back in 1996+, and that includes tunneling EV6 over HyperTransport in Athlon64/HyperTransport. This has to do with the fact that the Athlon core is a true 40-bit addressing processor, and not 32-bit with PAE36 to page in the "overhang" from a segment+offset that is normalized above 4GB. Athlon just _emulates_ PAE36 for compatibility. If you hit "/proc/cpuinfo" on _any_ Athlon, it will show that the PAE36 flag is supported. PAE36 support has _always_ been in _every_ Athlon because the core design is 40-bit EV6. AMD took the time, effort and transistors to emulate PAE36 at the control, and put in the logic in its TLB and memory controller. If they didn't, then AMD wouldn't be able to run any PAE36 OSes or applications. And even if you don't have more than 4GB of RAM, there is still the memory organization issues. E.g., Red Hat currently ships i386/i686 kernels with the 4G+4G model which hurts performance over the 1G+3G model. Why does it hurt performance? Because it either relies on the PAE36 paging logic, or a software emulation of it (if the processor does not support PAE36). With the BIOS hack and kernel, this allows Athlon MP to linearlly address directly above 4GB. Intel is _finally_ just coming out with its first, true 40-bit physical interconnect that breaks the limitations of GTL. People should be wary to _not_ go with the majority of Intel's existing platforms because of this, even those with EM64T. Only these newer platforms. > And if its not, then your whole speach about the pae36 > differences between a gtl+ or ev6 connected device is > wrong, which then in turn makes the only real difference > the iommu the newer athlon cores provide (so dma can go > above the first 4GB rather than having to be bounced)... > This is also supported by the intel, amd and redhat docs > (see links posted above and in previous mails), the post > Feizhou made in this thread convering the LKML references about > using the apggart and even microsoft > (http://www.microsoft.com/whdc/system/platform/server/PAE/pae_os.mspx) I know, I also posted it, and there are even _more_ comments in the LKML. There are comments on how AMD has extra GARTs in the Athlon (yes, even the so-called "32-bit" Athlon) to handle _all_ I/O, not just AGP (long story). But I'm not talking just about that. I'm talking about the serious limitations with GTL itself -- even on Socket-640 and Xeon EM64T. It's only the latest > *shrugs* Intel, AMD and any other spec sheet you can find down > to VIA chipset docs agrees with that... But I guess I'm still > wrong though? Dude, you are using _board_level_ spec sheets. I'm talking about the _internal_ design of the CPU/interconnect and how it handles the addressing between the systems software and interconnect. You get that from _neither_ of the "board level" spec sheets _nor_ the "programmer" guides. You have to find more eccentric docs, many times, they are not on-line. Intel is not going to boast how even their AGTL+ chipsets with first-gen EM64T can't directly address above 4GiB because of legacy design limitations in the platform. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 24 Jun '05

24 Jun '05

From: Peter Arremann <loony(a)loonybin.org> > Thanks - but both links again talk about a 32bit/4GB schema and don't talk at > all about addressing >4GB without the need for paging - that was the > statement Bryan made when posting. Correct. The links to the posts he provided were the _same_ as the the posts at the bottom of my original link. I'm still trying to find the post I was referring to. As I said, apparently it was _not_ in the 2004Feb17 thread on Intel EM64T. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: Opteron Mobo Suggestions -- the follies of typical tape backup (it's the 21st century)
by Bryan J. Smith <b.j.smith＠ieee.org> 24 Jun '05

24 Jun '05

From: Kirk Bocek <t004(a)kbocek.com> > Another poster (sorry, could find the name, was it Peter?) mentioned the > lack of hot-swap support in most of the hardware raid out there. If this > is the case, what's the point of raid 1 or 5 if a failed drive will hang > the system? What's your experience with the 3Ware cards? "Hot-swap" is like saying "3D accelerator," there are different features and, sometimes, if you don't have them all, they don't work. #1 is dealing with transient power #2 is dealing with the hardware ATA disconnect #3 is dealing with the software ATA disconnect While many carriers claim to solve #1 for ATA, _only_ SATA with its staggered data/power (using the 15-pin power, and not the legacy 4-pin Molex) is the _best_ guarantee. But typically #1 is not that much of an issue, because the carrier does a decent job at this (some better than others though). The big issue with "FRAID" is at #2. A biggie is when you use the master/slave and remove one. But even if you do master-only, how do you take out a device and replace it -- virtually "resetting" the ATA-PCI arbitration. It typically does _not_ work if the ATA controllers are directly connected to the system's PCI interconnect. But let's say you get #2 to work, now #3 is the biggie. How to you get the OS to "reload" what it thinks is a fixed ATA channel with a fixed drive. Sometimes the FRAID driver does a _poor_ job of it. This is what I see get people all-the-time. In the case of 3Ware cards, the system _never_ -- let me repeat that -- _never_ sees the ATA channel. The system, including the PCI interconnect, _only_ talks to the on-board ASIC. The ASIC then drives the ATA channels. In FRAID, the system, it's CPU and the PCI bus drive and talk _directly_ to the ATA channels. Intelligent RAID uses its on-board intelligence instead. FRAID doesn't have any. > Okay, okay, you win! You're right and I'm wrong! Dude, this isn't about "right and wrong." It's _never_ about that. It's about my sincerest wish not to see you with downtime. It's one thing for me to argue "good" v. "ideal," take it as you wish. But that's very, very, _very_ different than this. In this case, I'm arguing "proper" v. "risky" system design. But it's your system. > I will never consider IEEE-1394 again. You and the other posters > have convinced me. Every USB cable in my server room will be > removed and destroyed. Every USB port will be filled with glue. :) I don't think we _ever_ said that. We just said don't use IEEE-1394 or USB for removable storage on a server. You can continue to use IEEE-1394 and USB for non-storage devices, including input and media as necessary. GOLDEN RULE: As long as the server doesn't "mount" the IEEE-1394 or USB device, then you're "safe." If it "mounts," then you just put your entire kernel at the mercy of its availability. ;-> > What about LVM snapshots? I've been using these for awhile with no > problems. Yes, I understand that it will consume disk bandwith but > that's not a limitation in my installation. Snapshots are an "on-line" backup and they only work if your filesystem isn't _toast_. They aren't the same as "near-line." Again, read the "document" I sent you off-line. ;-ppp -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 24 Jun '05

24 Jun '05

From: James Olin Oden <james.oden(a)gmail.com> > Any idea what the BIOS actually does to enable "linux" memory mode? > That is what registers are poked in the MCH (I assume it would be the > MCH)? Do you think this could be done post bios by say a boot > loader? It completely _breaks_ Intel GTL compatibility at the APIC level IIRC. You can _not_ run Windows on it or a "normal" Linux kernel. From: Feizhou <feizhou(a)graffiti.net> > http://marc.theaimsgroup.com/?l=linux-kernel&m=107759901509280&w=2 > The Linux option in bios is mentioned here. > http://marc.theaimsgroup.com/?l=linux-kernel&m=107757492125437&w=2 > I think what Bryan here is talking about is called IOMMU by the kernel guys. No, that was already at the bottom of the link I sent before. I was referring to _another_ thread where a gentlemen from AMD (with an amd.com address) was talking about the hack that enables this. It is a little known feature because only 2-3 mainboards have the BIOS hack as an option. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

[OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 24 Jun '05

24 Jun '05

From: Maciej ?enczykowski <maze(a)cela.pl> > That's a good point - does anyone know what the new Intel > Virtualization thingamajig in the new dual core pentium D's is about? It's all speculation at this point. But there are _several_ factors. But I'm sure the first time Intel saw AMD's x86-64/PAE52 presentation, the same thing popped into my mind that popped into Intel's mind ... Virtualization - The 48-bit/256TiB limitation of x86-64 "Long Mode" There is a "progammers limit" of 48-bit/256TiB in x86-64 "Long Mode." This limitation is due to how i386/i486-TLB works -- 16-bit segment, 32-bit off-set. If AMD would have choosen to ignore such compatibility, it would have been near-impossible for 32-bit/PAE36 programs to run under a kernel of a different model. But "Long Mode" was designed so its PAE52 model could run both 32-bit (and PAE36) as well as new 48-bit programs. We'll revisit that in a bit. Now, let's talk about Intel/AMD design lineage. - Intel IA-32 Complete Design Lineage IA-32 Gen 1 (1986): i386, including i486 - Non-superscalar: ALU + optional FPU (std. in 486DX), TLB added in i486 IA-32 Gen 2 (1992): i586, Pentium/MMX (defunct, redesigned in i686) - Superscalar 2+1 ALU+FPU (pipelined) IA-32 Gen 3 (1994): i686, Pentium Pro, II, III, 4 (partial refit) - Superscalar: 2+2 ALU+FPU (pipelined), FPU 1 complex or 2 ADD - P3 = +1 SSE pipe, P4 = +2 SSE pipe Intel hasn't revamped it's aging i686 architecture in almost 12 years. the Pentium Pro through Pentium III are the _exact_same_ 7-issue (2+2+3 ALU+FPU+controll) design (the P3 slaps on one SSE unit), and the Pentium 4 was a quick, 18-month refit of longer pipes (with associated reduction in ALU/FPU performance MHz for MHz) that extended pipes for clock (and added a 2nd SSE unit). I'm sure Intel's reasoning for not bothering with a complete generation redesign beyond i686 is because it thought EPIC/Predication would have taken over by now. The reality has been quite the opposite (which I won't get back into). Since then, Intel has made a number of "hacks" to the i686 architecture. One is HyperThreading which tries to keep its pipes full by using its control units to virtualize two instruction schedulers, registers, etc... In a nutshell, it's a nice way to get "out-of-order and register renaming for almost free." Other than basic coherency checking as necessary in silicon, it "passes the buck" to the OS, leveraging its context switching (and associated overhead) to manage some details. That's why HyperThreading can actually be slower for some applications, because they do not thread, and the added overhead in _software_ results in reduced processing time for the applications. "Yamhill" IA-32e aka "EM64T" was just a P4 ALU refit for x86-64/PAE52, but it lacks many design considerations that the Athlon has -- especially outside the programmer/software considerations, and definitely more at the core interconnect/platform.. I.e., because Intel continues to use a single-point-of-contention "memory controller hub" (MCH), memory interconnect and I/O management, among other details, are still left to the MCH. This is going to become more and more of a headache. The reality is that the Intel IA-32e platform _must_ get past the "northbridge outside the CPU" attitude to compete with AMD. As such, I have _always_ theorized that "Yamhill" is a 2-part project. Part 2 is the first redesign of a x86 core in almost (now) 12 years, which goes beyond merely adding true register renaming and out-of- order execution (which are largely hacks in the P4/HT), but goes directly to the concept of virtualizing cores. More on that in a bit, now AMD ... - AMD x86 Complete Design Lineage AMD Gen 1 (1992*): i386/486 ISA -- 386, 486, 5x86, K5* - Non-superscalar: ALU + optional FPU (std. in K5) AMD Gen 2 (1994*): i486/686 ISA -- Nx586+FPU/K5*, Nx686/K6 - Superscalar: 3+1 ALU+FPU (ALUs pipelined, FPU _not_ piplined) AMD Gen 3 (1999): i686/x86-64 ISA -- Athlon, Athlon64/Opteron - Superscalar: 3+3 ALU+FPU (pipelined), FPU 2 _and_ 1 ADD/MULT - Extensions are microcoded and leverage ALU/FPU as appropriate *NOTE: The NexGen Nx586 released in 1994 forms the basis for latter K5 (i486) and the K6 (i686). AMD had scalability issues with its original non-superscalar K5 design and purchased NexGen. SIDE NOTE: SSE Comparison - P4 can do 3 MULT SSE (1 FPU complex + 2 SSE pipes) - Athlon can do 3 MULT SSE (2 FPU complex + 1 FPU MULT) Contrary to popular opinion, Athlon64/Opteron is the _same_core_ design as the 32-bit Athlon platform. It is still the same, ultra- powerful 3+3 ALU+FPU core, with its 2 complex + 1 ADD/MULT FPU able to equal Intel's 1 complex _or_ 2 ADD FPU plus 2 SSE pipes at doing the majority of matrix transforms (which are MULT -- hence why Intel's FPU can't do 2 simultaneously, and relies heavily on its precision-lacking SSE pipes). Also contrary to popular opinion, 40-bit/1TiB Digital Alpha EV6 interconnect forms the basis for _all_ addressing in _all_ Athlon releases, including the 32-bit. There are a few mainboards that allow even 32-bit Athlons to safely address above 4GB with _no_ paging or issues (with an OS that offers such a supporting kernel, like Linux). The 3-16 point EV6 crossbar and not "hub" architecture, forced Athlon MP to put any I/O coherency login in the chip, so the AGPgart control is actually on the Athlon MP, and not in the northbridge. This has evolved into a full I/O MMU in Athlon64/Opteron. Because Athlon is 5 years newer than Intel i686, and there is a wealthy of talent influx from Digital (even though Intel did get some as well, they haven't redesigned i686 completely), Athlon has some of the latest, run-time register renaming and out-of-order execution control in the core itself. This is why doing something like HyperThreading would benefit AMD _very_little_ and largley introduce self-defeating (and even performance reducing) overhead. In addition to the design of PAE52, the #1 reason why you can safely assume AMD is moving towards virtualization is because of the design limits they put on Athlon64/Opteron. E.g., although the original 32-bit Athlon platform used logic that allowed up to the full EV6 8MB SRAM addressing (cache), Athlon64/Opteron has been artificially limited to 1MB SRAM (saving many considerations and other benefits). This clearly indicates AMD did not consider Athlon64/Opteron - The Evolution to Virtual Cores AMD's adoption of '90s concepts of register renaming and out-of-order execution are great for a single core. And Intel's HyperThreading with the minor P4 run-time additions passes-the-buck decently in lieu of a complete core redesign (which they haven't done since 1994). But the concept of extending the pipes any further for performance has been largely broken in the P4, and Intel is actually falling back to its last rev of the i686 original, P3. Multiple, _physical_ cores have been the first step. This is little more than slapping in a second set of all the non-SRAM transistors, plus any additional bridging logic, if necessary. AMD HyperTransport requires none -- as HyperTransport can "tunnel" anything, EV6 memory/addressing, I/O tunnels/bridges, inter-CPU, etc... all "gluelessly." Intel MCH GTL+ cannot, and requires bridges between the "chipset MCH" and the "multi-core MCH," adding latency. And there are nagging 32-bit limitations with GTL+ as well (long story). The next logical evolution in microprocessor design is to blur the physical separation between cores. It's the best way without tearing down the entire '70s-induced concept of machine code (operator+ operand, possibly control, at least microcoded internally) and the resulting instruction sets. Instead of discrete, superscalar units of a half-dozen to a dozen, pipelined units, there will be numerous, independent pipes, possibly with their own registers or a number of generic registers, as a single unit. Other than the controlling firmware and/or OS, this is _not_ what software will use. What the software will use are the virtual instantiations that partition this set of pipes and registers, which may very well be dynamic in nature. Let's say I boot Windows, I might instantiate a virtual i686/PAE36 core guaranteeing 100% full Win32 compatibility. Depending on what resources the chip physically has, I will likely even instantiate multiple i686 processors. The concept of multi-CPU and multi-threading has evolved into virtual-cores with virtual-threading. Virtualizing more CPUs with a total number of more pipes/registers than is actual will allow more registers and pipelines to be executing instead of the common 40-50% for superscalar CISC or 60-70% for superscalar RISC. As an "added bonus," this means the 48-bit/256TiB constraint for PAE36 compatibility is _removed_. I.e., you can have a much larger, true memory pool, and any required windowing/ segmentation is done with_out_ paging by the "host" memory model, even though the OS is virtually running in a PAE36 or PAE52 model. This also gives rise to an entirely new platform for virtualization of simultaneous OSes -- be it the same OS, or different OSes. Because cores are virtual, you can have multiple, independent processors with their own registers, memory windows into physical RAM, etc... On the more "consumer" front, this will allow it to work with existing OSes as-is. On the more "load balancing server" front, this will often be paired with software (think EMC/VMWare *SX products) so numerous instances can be dynamically load-balanced across virtual cores -- but far more overhead and increased efficiency is put on the chip. But it is still managed by software (just with reduced context switching overhead in the software). Again, it's really just a consolidation of all the run-time optimizations we have now, along with both multi-core and multi-threading approaches, into a general pool of pipes, registers and organization. Additionally, it breaks the physical constraints of the memory model for the physical hardware, which is a very big issue for our future. To ensure x86/PAE36 and x86-64/PAE52 compatibility in the future, such machines will need to be virtualized or we'll be stuck at 48-bit/256TiB. > As in is it worth anything? Yes -- and almost everything to the future of Microsoft being able to sustain much their existing Win32 codebase which does _not_ port to PAE52 very easily and definitely _not_ with full compatibility. And we have to break the 48-bit/256TiB limitations of PAE52, while still ensuring PAE52 OSes/applications, as well as some legacy PAE36 OSes/applications, still run. The only way is to virtualize the whole freak'n chip so we can instantiate a processor, registers and its memory model -- even if dynamically assigned/ shared. And that's just for end-users, possibly workstations and entry servers. For load-balancing servers, you'll still need a software solution for management. It will be that the hardware just offers far greater efficiency and reduced context switching. In fact, the next consolidation are these virtual core chips in blades, where you not only manage the virtual cores in the individual chips/ blades, but an entire rack of blades as a single unit with multiple OSes spread across. This already exists, but this takes it one step further -- because the processors themselves are virtualized with greatly reduced overhead on the part of the software. > Will it allow a dual simultaneous boot of Linux+WinXP+MaxOS > under Xen or something along those lines? Yes. It will both give more virtualized processors to a single executing OS, as well as create segmented, virtualized processors for independently and simultaneously operating processors. > Even on an SMP machine? First off, remove the Intel-centric notion of "Symmetric" MP (SMP). Secondly, multi-processing and multi-threading are going to merge with traditional register renaming and out-of-order execution. So the traditional concept of "MP" is _dying_. In fact, in the '90s, it really died in general. I know it's hard to think outside the box and traditional thought, but most users don't understand superscalar design in the first place. Those who do understand why AMD has _not_ bothered to adopt Intel SMT (HyperThreading) in Athlon, because it won't benefit (because AMD's cores are 5 years newer in design, and put far more optimizations in the chip to keep pipes full and registers used that to virtualize two sets for the OS to use). > Anyone have any experience/knowledge about this? I can only speculate based on the history of the players involved, as well as what AMD's PAE52 design as well as limitations of the current Athlon core (which is largely the _same_ between both the 32-bit and newer 64-bit versions). But the concept of adding more pipes with lots of stages for timing is only leaving more and more stages in pipes empty, or doing little. There has to be a consolidation of many run-time optimizations inside of the chip, and the best way to do that is to create a bank of pipes, registers, etc... and virtually assemble them into virtual cores that are partitioned with memory as a traditional PAE36 or PAE52 processor (or multi-processor). It's going to solve a _lot_ of issues -- both semiconductor and software. > What level of CPU/hardware(?) does the virt-core support? > And is the virt-core 32bit? You can be certain that the "host" OS (possibly firmware-based?) will be able to instantiate multiple PAE36 and/or PAE52 virtual systems with their own and -- I'll use legacy terminology here (even if it's not technically correct) -- "Ring 0" access. So, technically, there should be possible to run any PAE36 or PAE52 OS simultaneously on the same hardware as any other PAE36 or PAE52 OS. The larger issues of firmware-OS interoperability as well as partitioning resources (memory, disk, etc...) is really more of a political/market issue. I.e., AMD and Intel can provide the platform, but people have to work together to use it. Furthermore, it also means that Intel can continue to best AMD in funding of OEMs and firmware/software vendors, so it still has an advantage in that capacity. I'm sure Apple will be protective of its firmware, and Intel's new, supposed "open" firmware is rather proprietary. As I've repeatedly commented elsewhere, the 2 "most open" hardware vendors right now are AMD and Sun, x86-64 and SPARC, respectively. Intel has not only protected non-programmer aspects of IA-64 heavily, but most of their new platform developments for even IA-32e (EM64T) are _very_proprietary_. IBM is partially doing the same with Power in a microelectronics offering, but it is _not_ the same in its branded Power solutions (among others). So it's not going to solve vendors who require firmware and data organization that is not open and stanardized. We're fine on legacy Win32 platforms, but it's not going to address Mactel, nor solve the problem of existing OSes that don't run under current virtualization solutions because of such proprietary requirements. -- Bryan J. Smith mailto:b.j.smith@ieee.org

5 9

Net installations failing
by Andy Pace 24 Jun '05

24 Jun '05

Why is it that my netinstalls are failing? It's saying that the downloaded image does not match the booted media. i'm using mirror: http://mirror.trouble-free.net/centos/3.4 I've tried installing 4.0 and 3.4 with the same result. Weird huh. This happened to me last week also. Any insight would be greatly appreciated.

4 4

Re: [CentOS] Re: Opteron Mobo Suggestions
by Bryan J. Smith <b.j.smith＠ieee.org> 24 Jun '05

24 Jun '05

From: Kirk Bocek <t004(a)kbocek.com> > Yes, I understand. I also don't have an unlimited budget > If I can get most of the benefit without needing a $300-800 > add-on, that's a big plus. You're talking about an $500-600 mainboard. Then you're talking about $500-800 _per_ dual-core CPU. And then you're gotta factor in the Registered ECC RAM costs. And you're worried about a $125 (3Ware Escalade 8006-2) or $300 (3Ware Escalade 8506-4) controller? Furthermore, the SATA on the nForce MCP is typically only a single, 133MBps PCIe x1 channel. You'll get 533MBps out of the 8506-4 in a PCI slot at 64-bit @ 66MHz. > I conceptually understand iSCSI, but how would I use a GbE > NIC in a backup solution? What do you think iSCSI is? It's storage over IP, but just with an additional a host processor in the GbE to off-load overhead. If you don't have the money for a HBA GbE, then just do straight GbE. Build an out-of-band IP network segmented off on a 2nd GbE connection in each system. [ HINT: I'm exploring the issues of real-time backup and discuss near-line storage, virtual tape libraries and, in a future article after that, out-of-band networks and "cheap" SANs. All from the standpoint of a sysadmin, and not so much network/storage engineering. ] > Don't forget that a backup solution would depend on > hot-pluggability. That's why I was thinking of USB/IEEE- > 1394. Mistake on a server. You don't want to hot-plug consumer interconnects. One issue, bam! Kernel panic. Use an out-of-band IP network over a 2nd GbE connection to what you need elsewhere on the network. I have been recommending this where cost is a factor. > Cool, I will take a look at HP's offerings. Do you have any > motherboards alone that you would recommend? It's difficult because of the limited designs. A lot of mainboards "cut corners" for cost considerations. Even the Tyan 4885 puts _all_ I/O on _one_ CPU. The HP DL585 follows the AMD reference. -- Bryan J. Smith mailto:b.j.smith@ieee.org

5 5

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