Talking so much without saying anything...
on
Nvidia Apologizes
·
· Score: 4
I can only shake my head after reading Hypothermia's summary. Did he have the same conversation he posted on his site? Are the Slashdot posters reading the same thing I read? This is what I saw in that conversation:
Here at NVIDIA we have over 60 people in marketing and unfortunately, someone who thought he was doing the correct thing was not. The contract that is on Hypothermia (sp?) is a document that we use for corporate to corporate promotions. Translation: Someone here really f**cked up. (Note lack of apology).
Let's say if and OEM would like to do a banner for a show this agreement assures us that we have top billing with that promotion. Then why is there all this text in the agreement about web sites? What does this have to do with a show?
Whatever you review is whatever you review...we've never asked anyone to pull a review for competitive reasons. Yeah, but you guys sure have no problem pressuring reviewers into biasing for your card's strengths.
I feel really bad in your situation, because for the last 7 months you have been misled by a non-NVIDIA employee (intern, contractor, etc...). To Hypothermia, who had thought that this was an accurate PR rep, I apologize and for all of the grief/headache this has caused I apologize for that too. What kind of company allows this to happen? Is NVIDIA such a loose operation as to allow non-NVIDIA employees to use their corporate email? Note that this does not satisfactorily explain Hypothermia's situation, because in the evolution of this whole ordeal Hypothermia clearly states that he spoke to at least two different people.
So this apology means nothing to me because none of Derek's explanations hold water. The apology I see only really applies to allowing someone to impersonate an NVIDIA employee.
All the opinions expressed above do not necessarily represent those of my employer.
Disclaimer: I am an IBM employee working on the PowerPC 40x cores. Adjust interpretation accordingly.
spoonboy42 sez:
For battery operated devices such as handhelds and webpads however, they use considerably more power than their competition: The StrongARM, the Crusoe, and the (admitedly far less powerful) Dragonball and Coldfire. Performance-wise, the StrongARM is in about the same class as embedded PowerPC models, and the Crusoe is set to blow everyone away
Not totally true. The IBM 40x series does compete directly with ARM. Performance-wise, we do have a small edge over ARM. Power-wise, ARM has a small edge over PPC 40x. However, neither are anywhere close to realm of Crusoe in terms of power consumption.
I don't know Dragonball and Coldfire that well, but I am reasonably sure they don't compete well with ARM or PPC 40x in either power or speed.
Crusoe consumes, IIRC, in the realm of 4W avg. 40x chips consume less than 1W (including on-chip peripherals), and ARM is even less (500mW I think). So it's a big tradeoff. You pick your chips based on where you want to be in that power/speed curve.
So in short, if there's a power outlet handy, go with PowerPC, but to maximize battery life, StrongARM and Crusoe are the way to go.
That's a myth. Don't know where you got that idea, but I'm glad I could dispell it for you:).
Disclaimer: I am a design engineer on the embedded PowerPC team, interpret this accordingly.
Before I begin: don't be misled. The 68HC11 and the 405gp are two totally different ballparks. They do not compete in the same space.
faeryman sez:
I've followed the development of the for a while now, even having a few email conversations with Jonathon Thompson, Quong Ho Thoc, and Hagr Itstein (three lead developers). I told them about a few of my concerns but it looks like marketing prevailed:( I am relatively new with the 4xx PowerPC team, but I've never heard of any of those people; I don't think they are developers (much less lead ones).
I don't see Linux being the right tool for this. I don't want to see this product fail since I know IBM is a good company. By all means everything else they made was a success, but the IBM 405GP looks like it will be a flop. Umm, our customers sure seem to think it's the right tool. We got so much demand for Linux on 405 that we had to hire extra people to fully support Linux. As for 405gp being a flop, I don't know what planet you are on. 405 is selling so fast that it put a strain on our short term capacity. I don't consider a chip to be a 'flop' when Ericsson, Nokia, Cisco, and Alcatel use them in their products...
(1) Security - This is a big concern for me. Imagine some evil hacker getting control of this baby...now imagine if this was used in your bank or a military instituion. See the problem? Umm, no, I don't. How exactly do you associate a SOC device with an Ethernet port automatically vulnerable to hackers? Is the 405gp somehow deficient in this regard?
While I commend the design of Open Souce, perhaps allowing the innerworkings of this to be accessable by a hacker is not good, even more so when it's an embedded system. You are confusing connectivity with security. This article is about SOC's, and as far as their design is concerned they must be properly secured like any other computer system. Save the security tirade for a different forum.
(2) Expansion architecture - Check the specs on this thing. While a PCI slot is normally a good thing, wouldn't MCA or a propietary bus be better suited for this? Are you f*cking kidding me? MCA? How many MCA devices can you buy? Not just cards, I means chips (which is what the vast majority of 40x's will be talking to). Almost zippo. Now how many different PCI devices do you think you can find?
Linux runs on the MCA fine, and I think it's low overhead and fault-tolerant properties are better than a run of the mill PCI slot for this. Or a new bus design could be implemented. IBM benefits with better performance, we as a comunity benefit from more GPL code being released. Sound good? Absolutely not. The whole point of choosing PCI is because it is commodity, fast, reliable, and supported by almost every modern OS. It seems that you are desperate to reinvent the wheel here.
3) Operating system - [flamesuit] I like Linux, but I don't think Linux is the best tool for this. IBM has made the decision to go with Linux, so I'll respect that. Like I said before, our customers want Linux. Linux is not the only OS we support. Actually you can put damn near any OS on the planet on it; IBM doesn't have support for them all however. You want a lighter weight OS than Linux? Fine, use OS/Open, which is IBM's little creation (works very well and supported too).
Scalibility and performance are key here, and QNX can deliver better than Linux. Well, if you think so, then there's no reason you can't run it on 405gp.
Again, I don't like being negative but I don't think the IBM 405GP will do that well. I want to be proved wrong though, I want to see Linux progress and gain market share, and I want to see IBM be profitable....but Linux just ain't gonna cut it for this one my friends. Please tell me I'm wrong. Well, since you asked so nicely...:)
Being an IBM employee, I feel the need to stand up for the good Mr. Ayd:).
Aww, talk about sour grapes! They've hurt IBM's feelings, because IBM sells really smokin' computers too.
Seriously, I think David misclassified GRAPE 6 quite a bit. I don't think it's quite David's fault, because the article writers don't know the difference between 'supercomputer' and 'attached processor'. ABC News didn't really apply the term 'supercomputer' correctly either.
The term 'supercomputer' is more of a marketing term than anything else. Technical people only use it when they want to describe a general capability. AFAIK there is no concrete definitions of 'supercomputer', and if there were they would likely change daily. GRAPE 6, from the information I can see, is really an attached processor.
Attached processors can be an ARM chip on your network card to a GRAPE 6. Interanally, GRAPE 6 is a full custom, superscalar, massively pipelined, systolic array (say that 5 times fast). That basically means that data comes in one side of the board, and after n clock cycles the answer comes out the other side. There is no code other than a program running on the host computer which generates and consumes data, and every piece of the algorithm is done in hardware.
"What happens when the algorithm changes?" you might ask. Well, then you're screwed. You have to do a whole new board. Many boards use programmable chips as their processing elements, and can reprogram them when bugs or features get added, but these guys appear to be using ASICs. Great for speed, bad for flexibility.
Even though David Ayd was mistaken about the architecture, this idea has been around for quite a while also. The SPLASH 2 project was one of the first successes with this idea. There is also a commercial company selling boards using that idea but with completely up to date components (compared to SPLASH).
Still, in July of 1995, the GRAPE 4 became the world's fastest computer, breaking the 1 teraflop barrier with a peak speed of 1.08 TFLOPS.
Well, we really can't argue with that, can we, Mr. Ayd?
This architecture lends itself to extremely high throughput. It's no surprise that these perform so well. NSA uses architectures just like this to do it's crypto crunching. Brute forcing doesn't look so bad after trying one of these:).
Okay, this is one post too many with this kind of gripe. To be honest I am very tired of seeing them. Something needs to be said about this, so it might as well be me.
I respect your right to post your opinion on this subject in the Slashdot forum. However, there is a lot that needs to be said in defense of the Slashdot admins. The following important facts are never considered in posts like yours:
They are only human, they also make mistakes.
There are several different admins, not just one of them. Sometimes they don't each know what the other admins have reviewed or posted recently. One admin may accept a story another rejects.
Guestimating the amount of crap they must have to filter out on a daily basis, I figure their record is pretty good.
They probably gauge the importance of a topic on how many submissions they get. Being the first submitter gets you nothing. If you are the first one (or the only one), you probably won't get the credit unless it's earth-shattering news.
If you feel slighted by having them reject your stories, you really need something better to do with your time (unless you are a journalist;) ).
If you're looking to make an impression on the/. community do it with well written posts rather than with story submissions.
I do agree with you though about the double posting of stories (IBM supercomputing, patents). The last few have been only characterizable as gross errors.
Ol' Tom has a good point. Sysmark really isn't the right solution for comparing processors. What he proposes is a realistic, achievable goal, but you have to define the playing field first.
The Good:
There already is a great benchmark for processors, and it's called SPEC. Yes, it's not open source, but it's really quite reliable for comparing CPUs of any architecture. As slashdot user "cweber" pointed out in his post, they have been doing this for 11 years, and they periodically revise their benchmark suite to stress CPUs more uniformly.
The open-source method. This is really good to ensure that there are no cheaters at the benchmark level.
Tom's interesting ideas on Crusoe. This stems from the fact that SPECmarks don't quite approximate real usage that Crusoe depends on to use it's hotspot optimizations. However, we are interested in the raw sustained speed of the processor (in this case), not the speed of the OS or it's task swap latency. Tough problems to solve.
Open-source means that the benchmark code will be able to take advantage of the best compiler available for the target CPU (see comment at end).
The Bad:
Anyone who has done benchmarks knows that even small variations in system config can have strage or harmful effects on the benchmark results. This open-source effort is going to have to have a database of hardware configs in order for this to be useful.
The Ugly:
Vendors are going to oppose this (at least not support it). Why? Because plain and simple they have an interest in promoting the most favorable statistics possible about their products. They want to keep feeding you "polygon fill rates" and "texels per second" because their card may not stand up in a direct test program comparison. Plus, they are just dying to convince you that they have new BogusMarketingAcronym (tm) technology and their competitor does not. Nevermind that SSE and 3Dnow do pretty much the same thing -- companies have an interest in differentiating themselves as much as possible.
If this benchmark actually takes off (and gets widely accepted), we might get cheaters at the firmware or hardware level. This has happened before -- although which company it was and which benchmark they cheated I can't remember. I can't find it on the net or remember to save my life (sigh)...
I also need to say something to the people who think a processor should be judged independently of a compiler. This is just plain dumb. Why? Because a processor and it's compiler are a team. You can't use one without the other. When a chip is designed, there is a direct information dependence between the chip architects and the compiler writers. They are designed as a pair (ideally), and they should be tested as such. If a given compiler has great optimizations, then great! That means the compiler understands its target real well. It is a win for both the CPU and the compiler for pulling it off. This compiler is going to do the same kinds of optimizations when vendors use it to write programs, so that helps the comparison between benchmark code and apps.
However, I can see the need to compare not only the best compiler, but GCC as well, because of its broad acceptance. But if you are serious about performance, and want to get every once of juice out of your chip, you use the vendor provided compilers, not GCC. Don't get me wrong, GCC is great for compliance and portability, but it usually doesn't compare well with vendor compilers for generated code speed (with the possible exception of IA-32).
Ars Technica also published, a while back, some good information regarding CPU benchmarks. Check it out if you are interested in SPEC or CPU benchmarks in general.
This is correct. As an IBM microelectronics employee I can say:
I don't remember hearing about any agreement between IBM and AMD.
AFAIK, this is true. We (IBM) have no manufacturing relationship with AMD.
This technology is intellectual property of IBM and would not be available to anyone unless IBM decides more can be obtain from licensing the process.
This is also correct. However, something important does need to be pointed out though. This process will (AFAICT) be the next generation technology for IBM's processor and ASIC designs. Again, IIRC, CMOS-8S is our latest and greatest, so this process will likely be called CMOS-9(S|SF).
This means that any customers using IBM for their manufacturing (and back-end) can use this technology, not just IBM. Since Transmeta uses IBM manufacturing, they have the option of using this process (if they choose to, right now I think they're in CMOS-8SF). Lou Gerstner has declared that there will be no sacred cows in IBM, so everything we make as a product must be available for sale outside the company as well. [Shameless plug: All the more reason for companies to go with us, because our silicon roadmap kicks ass].
Anyways, as is public knowledge, the Power4 is currently using a modified version of CMOS-8S, which provides low runtime electrical failure rates. CMOS-8S technology is basically 0.18 micron junction and trace widths, using copper metal over insulator (SOI). For the final release, they will probably use this process (CMOS-9S?).
Disclaimer: All this is public knowledge, none of it is IBM confidential stuff.
Don't make opinions without the data to back it up.
Oohhh, you opened yourself up on this one...:)
Fallacy #1:
The CPU's are *MORE EXPENSIVE* yes, overpriced, no. Look at a comparison in the CPU's on just a very simple level. The CPU has 8 Megs of L2 Cache. Not 256k, not 512k, not 1 meg, 8 Megs. That Cache is running at CPU Speed. If there's anything at all that's slowing their speed down, its the large amounts of L2 Cache they run with their servers.
Remind me again why 8Mb of L2 is needed when programs have 95+% cache hit rates with 1Mb (often less; hmmm...)?
They really are overpriced. I am certain an Alpha 21264 can be had for a fraction of the price of these things, and its specmarks are int-27, fp-58, which is too close to make a big deal out of.
Fallacy #2:
Now getting back to PCI cards being overpriced, in Sun's specifications, it dictates that all hardware MUST have a PROM with the drivers on it to be certified as Sun Compatable. At boot time, all of the PROM's are polled and all of the drivers are loaded at the hardware level. Plug and play that really works, imagine that...
Gee that's funny, I don't remember anything in the PCI spec about having to have PROMs...;P
This is bad for two reasons. First, I hate it when vendors screw with the PCI specs. It was adopted as a spec for a reason, not so vendors can then change it so it only works with their HW. Just ask linux-kernel how much they love broken PCI workarounds...
Reason 2 is that "plug and play" (a Micro$soft term BTW) can be had for PCI without having those PROMs on board. The reason Sun uses those PROMs is to get licensing fees from hardware vendors to get that "Sun Compatible" moniker. Creative revenue generation no doubt, but it prevents PCI interoperability, which is a Bad Thing.
Fallacy #3: > The OS is waaay overpriced.
Free, yeah way too expensive.
Wow! You got Sun to give you free copies of Solaris for Sparc? Last I checked you still had to pay a hefty $90k (!) for an OS with nearly equivalent functionality as Linux. I call that a bad deal.
Fallacy #4:
First, all of the workstations and servers have TRUE plug and play. There processors scale from Laptops (anyone remember Tadpoles) all the way up to Mainframe-sized computers (E10k). Also - hot-swappable I/O and CPU/Memory in the Enterprise systems. The E10K can scale up to 64 450 Meg processors with 8 megs of L2 Cache, 64 Gigs of Ram, and can run 4 Virtual Machines that can be dynmically allocated on the fly.
Don't be fooled into thinking only Sun has hot swappable drives and IO. Geez, Dell Proliants have had hot swap SCSI since 1997. Hot swap IO? That has IBM written all over it as well. However, the best argument is scalability. Forget laptops to E10ks, how about Linux on a Palm to Linux on an IBM/390 Mainframe? What two extremes could you possibly supply that's wider than that? (E10ks are toys compared to S/390s).
My money's on Linux. If you want scalability and interoperability, Linux is the answer. As for reliability, Linux has a little ways to go to catch up to Solaris/VM/MVS/BSD, but it's getting there.
With all that said, the UltraSparc-III looks like a very good design from Sun. You rarely see appropriate amount of thought applied to the reality of processor shortcomings these days, and they hit the right aspects.
Um, I think my friend Mr. Malda has confused some/. readers. The announcement, as stated, applies to Enterprise Servers, which in IBM lingo means RS/6000, AS/400, and OS/3[7-9]0 machines.
As far as I can tell, this does not affect notebooks, PCs, and Netfinitys. They fall under a separate division of IBM and have their own "master plan". This is somewhat moot however, since Linux does run fairly well on these machines anyways.
As some readers insightfully pointed out, there are obvious motives for this. AIX, VMS, and VM are expensive to develop and time consuming to maintain, and IBM makes more money off the hardware anyways. IBM still has very strong hardware expertise, and the best reason to buy a RS6k is the hardware architecture (that and all the reliability aspects).
Don't have the misconception that IBM's enemy is Microsoft. Although we compete with them, our real competitor is Sun. Sun competes heavily in all the same areas we do, and Linux is the perfect way to help us fight the the workstation battle.
Since it is obvious to me that Sun has no intention of really supporting Linux until it begins to threaten their survival, I'm all for IBM and Linux partnership. This means IBM will contribute to linux kernel development for all of the products mentioned above, which should be quite valuable to Linus and Alan.
As for applications, that too falls under a different IBM division. I can't tell you if Notes or Smartsuite are coming for sure, but I wouldn't be suprised to see some changes in light of this announcement.
I actually just interviewed with Lucent. Allow me to explain how this fits with their product line:
As mentioned several times previously, the main box featured in this article is a DWDM router, not an IP router. There is a big difference, because they do very different things. See previous posts for details.
Lucent just recently finished their purchase of Nexabit, a private datacomm company. Nexabit currently is shipping the NX64000, a true 6.4 terabit IP router mentioned at the bottom of the article.
Lucent is the only company I know of capable of routing OC-48 IP at line speed. They have imminent plans to route OC-192 IP at line speed, and I expect them to release it soon. Some can route gigabit ethernet, but routing OC-48 and up is where the men are separated from the boys.
Lucent has one other competitor in the terabit routing space, and that is Juniper. Juniper is the only other company actually shipping a product. Avici, Zuma, NEO, Ironbridge, and Pluris all claim to have products, but aren't actually shipping anything capable of routing more than 1 terabit across their backplane/switch fabric.
In any case, Lucent's box has the most single-chassis bandwidth of any competitor. Several of the aforementioned companies are trying to play PR games by stringing multiple boxes together, but you definitely can't achieve terabit speeds by daisy-chaining boxes.
All of this information is true to the best of my knowledge, as I have personally talked with all companies I mentioned above. If I were an ISP, the box of choice would be a no-brainer.
In a widely awaited move, Microsoft has announced it's new nervous operating system version 1.0, Microsoft Brain (tm). Co-developed in Redmond, WA and Reading, PA, this new operating system is designed with human efficiency in mind.
"No more unecessary arm movements!" proclaims John Q. McFoo of Microsoft. "We have achieved partial control of humankind, and we eagerly await leg control as well" says McFoo. "Unnecessary arm motion is now a thing of the past. This is an energy savings for all consumers" McFoo adds.
Microsoft is widely expected to deploy Brain 1.0 in time for Christmas, so users can purchase as many Microsoft products as their budgets allow. "With control of the arms, we anticipate a huge increase in Microsoft product purchases" says industry analyst Bob Smith. "Without leg control, however, getting them to the store is another matter" cautions Smith.
Citing a stunning 90% uptime figure, Microsoft is touting this as a real win for reliability. "Losing use of the arm for only 10% of the time isn't so bad" claims McFoo. "Besides, with the new Microsoft Nerual Uptime (tm), you can have friends paged to reboot you" during downtime, he concluded.
RAMBUS is still a bleeding-edge technology. Signal integrity is a major headache, and Intel has the unlucky fortune to be the first to try it; there are bound to be problems.
RAMBUS is not a serial at the physical level, it is a parallel channel with a 16-bit width.
To offset the relatively small bus width, a super fast clock is used. Currently I think the i820 is designed for 600MHz, but I'm not 100% sure on that.
RAMBUS is a packet-based scheme, where multiple transactions can be pending at any given point in time (similar to TCP/IP). This allows non-blocking memory accesses and better bus utilization.
Intel's current RAMBUS implementation might not be cost effective over SDRAM, but given a year or two probably will be (if they can get past the current problems).
I don't know what you guys are thinking of when you say RAMBUS sucks. RAMBUS isn't another USB (yuk) -- it is an extremely well thought out technology that is (admittedly) somewhat ambitious. RAMBUS scales much better than any existing memory technology. I see people bitching about RAMBUS, but SDRAM will probably max out at 150 MHz next year.
Please understand that Intel != RAMBUS. Don't hate RAMBUS because you hate Intel; RAMBUS was founded by two people who were very smart guys and as a separate entity.
Intel's problem is probably not with the i820 itself, but the way the RAMBUS signals behave on the bus. They have noise and termination problems, which are very similar to SCSI problems. This is why the last slot on the bus is problematic -- having a RIMM or nothing at all makes a big difference to the the signalling scheme.
This problem will not affect SDRAM, even with an i820 (unless there is a different problem I don't know of).
Re:too much misinformation...
on
CNN On IPv6
·
· Score: 1
You posted some great comments; but since you don't have an email listed, I will respond here and try to keep it brief.
For one thing, allowing an outside entity to control an appliance which you have purchased sounds like a potential privacy issue to me - without some really strict regulations on what a company can do with the information, do I really want a company to know when & how much toast I make? (Slightly more seriously, think DIVX...) I agree with your fears. However, I feel that this will be inevitable, regardless of the privacy implications.
In any case, I see NAT as a highly desirable way for me to control what is talking on my subnet to stuff outside the subnet, regardless of whether you're talking IPv4 or IPv6. NAT is not designed for security, it just coincidental that it is more secure than traditional means. If you want security, IPsec is the best way to go (and is much easier on IPv6 anyway).
Why is there some limit of effort @ opening NAT walls to different protocols? If the protocol is simple, then you can communicate through a single connection, and the owner of the NAT box can open that single port & attach it to the proper machine. The limitation I speak of is a manpower/development limitation. It is not efficient to have someone spend their valuable time fixing the current NAT implementation for the latest and greatest vendor protocol. Often, vendor protocols embed the source/destination address somewhere inside the packet, which is why NAT fails. IPsec is a great example; it needs to embed the source and destination IP inside an encrypted packet. No NAT program will ever be able to route this correctly, which means people running NAT can't use IPsec, which won't fly economically.
Maybe I'm not quite understanding what you mean by "IP expansion" using ports, but as far as I'm concerned NAT is _supposed_ to make your subnet look like a big server on a single IP address, and I can't think of any performance/utilization metrics used by ISPs where this paradigm would cause "Bad Things" to happen. By "IP expansion" I meant the mapping of unused ports on one host to ports on a different host (NAT), thus virtually giving you "more IP addresses" (bad phrase, sorry).
ISP metrics depend heavily on being able to uniquely identify evey host in the network, internal and external, for a variety of very good and time-tested reasons (I won't go into detail). NAT is designed to obscure this, and thus represents a problem for any network admin.
too much misinformation...
on
CNN On IPv6
·
· Score: 4
Seeing some discussion of IPv4/v6 in this forum is starting to scare me, so I thought I'd try and clear up some major misunderstandings.
I see a lot of posts saying that IPv4 is just fine and we should stick to it. Wrong, wrong, wrong. I realise that people on this group don't design routers every day, but I think you would be amazed at how much protocol hacking goes on under the covers. The vast majority of routers out there do some amazing things to try and hack together things like quality of service (QoS) and NAT that IPv4 just isn't designed to do.
Yes, IPv4 is working. But the amount of time now spent in the design phases to kluge together ways for NAT and QoS to work is becoming way more than most design houses will stomach. Features like VoIP, VPN, and QoS have major cash potential for ISP's, and they in turn will pay to get capable equipment. Doing this with IPv4 is a bitch, and a lot designers secretly wish IPv4 would go away and use IPv6 instead, because VPN and QoS are much easier to do.
One other major piece of misinformation here is that all boxes need to be replaced for this to happen. Not so. The vast majority of routers, hubs, switches, and all desktop computers are perfectly capable of running IPv6 right now. It involves a code load change, not a hardware upgrade. On a related point, most ISPs completely replace all their network boxes every 2 years anyways, so the threat of scrapping all hardware for IPv6 won't faze them much anyway (it's part of their cycle).
The last point is that people don't think that their toasters need IP addresses. This is also not so! Yes, in the next 10 years your toaster will need an IP address. Why? Because ToasterCompany will want you to do a firmware upgrade on your toaster because their have been field problems (like toasters burning operators). You will go across the wire, flash your firmware, and now your microprocessor-controlled toaster has CrispyToaster(tm) v1.16b firmware. We've already seen web servers implemented in ~4mm PIC processors, so expect them to become popular in the near future in your favorite household appliance.
To do this, you need an IP address (to speak IP of course). Please don't tell me how great NAT is... yes, I also run a Linux ipMasq box which works fine, but NAT fundamentally breaks many of the underlying IPv4 mechanisms. We can't keep dumping more patches to the NAT engine every time someone wants to NAT some new protocol; eventually we are going to reach a limit of effort.
Also note that using ports as a means of "IP expansion" is also a Very Bad Idea. A port is specifically designed (in TCP/IP spec) to represent a different service on a given host, not across different hosts. Yes, you can use this technique in NAT, but it tends to make performance/utilization metrics used by ISP's blatantly wrong, which leads to Bad Things.
Please also read Singal11's message above, he is right about the routing table issue. There is no current proposal (beyond CIDR) which can solve this problem. Also, see jd's post, it is a good summary of why IPv6 is needed.
You might notice I am the one who submitted this story. I am also an employee of IBM's Networking Hardware Division, and I think I can shed some light on this "partnership."
Let me be blunt. My division has been dying a slow death for several years now, and this is the last nail in the coffin. Up until this agreement, we produced hubs, routers, and switches, which is now (almost) entirely sold to Cicso. Our division of 2000+ people are now all spending the next two weeks cleaning up our resumes.
Cicso made out like champs on this one. They have no obligation to support our old boxes, which has been kept squarely on IBM (at great support cost as well). Cisco has acquired every design aspect of our data networking products, right down to the source code.
IBM Global services, however, will sell Cicso stuff, and Cicso will make huge inroads into the Mainframe and Channel Attached markets (i.e. ESCON and parallel channel) which were previously dominated by us (for whatever that was worth).
Don't be fooled by the large $2 billion number -- they would have spent that much anyway on our chips. $2 billion over 5 years comes out to $400 million per year, which is not much for someone with volumes like Cicso. They have already been making deals with IBM Microelectronics before this was announced.
Token Ring and SNA, however, will remain the IP of IBM. There will be a small group of people left here to maintain development on these fronts, but don't expect any significant new designs on this front. Which is fine with Cicso, because these technologies aren't really going anywhere anyway.
Ironic, really, because at one point in our division's history we had the perfect opportunity to buy Cisco, lock, stock, and barrel. Needless to say we have been kicking ourselves daily for that screw up.
And on a lighter note, if anyone reading this is interested in hiring a hardware systems/low level code design engineer, mail me here:).
Nearly everyone has remarked how extremely awful his writing is, so I won't add to the pile here. People have also noticed his startling revelation that "The distinction [between decimal and binary] is that, this is a Logical expression, that has no Equivalence. [LOL]"
If you actually want to read his paper, just skip to the bottom where he displays his amusing tables . Any ideas what those small numbers in the last column mean (the 1, 10, and 110 ones)?
However, if you were at all like me and dissected his "paper" for what he was really trying to say, you may have actually noticed (if you were successful) that he considers the subnet mask part of the address (look at Table 1 in his "appendix"). Since TCP/IP fundamentally routes a IP datagram around using only the destination IP address, this won't work at all. Datagrams don't keep a subnet mask around with them, they are nodal notions only. His scheme will actually yield several thousand hosts which have the same IP address, which definitely won't work.
Oh and I love : "To render a more pointed fact, I needed to pass a CISCO Certification Examination." That says it all:).
Nearly everyone has rightly remarked how extremely awful his writing is, so I won't add to the pile here. People have also noticed his startling revelation that "The distinction [between decimal and binary] is that, this is a Logical expression, that has no Equivalence. [LOL]"
However, if you were at all like me and dissected his "paper" for what he was really trying to say, you may have actually noticed (if you were successful) that he considers the subnet mask part of the address (look at Table 1 in his "appendix"). Since TCP/IP fundamentally routes a IP datagram around using only the destination IP address
I realize there are a decent amount of posts about why this strategy is good for Linux, but maybe a closer look reveals why this is so good.
SGI, currently, has two things Linux desperately needs. The first is a journaling file system. I don't think I really need to explain why this is a good thing; all it takes is one bluescreen with NT and you'll understand me completely. SGI's is mature and stable, and has a very good reputation among the workstation community. Nuff said.
The second, IMHO, is even more important. SGI has (again IMHO) the most outstanding implementation of thread-level parallel processing. Almost all the other platforms you care to look at (IBM, older Sequent, Sun) either depend on MPI coding or are designed using close-coupled SMP, which tend to reach their limits quickly. It seems SGI has profited greatly from their acquisition of Cray Research.
SGI has a great thread library which they have mapped to their NUMA implementation, which scales a little better than SMP does (I'll skip the technical explanation here in favor of the point). SGI's extensive knowledge with multiprocessing comes at the perfect time for Linux, which is this very minute undergoing heavy kernel modifications to better facilitate thread level parallelism.
SGI has so much to offer in terms of technical skill that Linux could absorb at this point in time. Make no mistake, this is a perfect opportunity for Linux to milk the expertise from SGI, who needs Linux to survive.
Funny to see that article by the EFF. They have no idea how much they have underestimated the NSA.
I used to work for a company called Annapolis Micro Systems (Annapolis, MD). They specialize in selling high performance configurable computing boards (both VME and PCI versions). These boards are especially suited to numerically intense algorithms (image processing, encryption).
It's no big surprise that the single biggest customer of AMS is the NSA. They routinely bought Wildfire arrays (see website) by the dozens. Two guesses as to what they were using them for, and the first doesn't count...
It must be emphasized what kind of power these arrays confer. Anyone familiar with configurable computing knows several things: 1) It's not for the light of wallet. 2) It requires a hefty design overhead for each application. 3) It presents the fastest known solutions to almost every NP-complete and iterative solution problem ever posed.
I am a hardware designer by trade, and I can tell you that is almost beyond my ability to measure what kind of processing power these boards can enable, purchased in groups.
Be afraid, be very afraid...
(Author's note: from my limited knowledge of encryption, keys larger than 1024 bytes probably aren't crackable by brute force in this day).
Let me start by saying this article has quite a bit of capitalistic merit. My company (IBM) should certainly pay more attention to this.
HOWEVER, I feel I must post a "caution" (for lack of a better term) about this feature, which has evolved through years of Finding-Out-the-Hard-Way.
There are two problems that this article does not address. By releasing a driver for a piece of your hardware in Open Source form, you open up a big can of worms in two areas: customer support and hardware damage.
I will speak on the second topic first because it's probably less obvious. I have worked in houses which design some pretty complex devices. These devices typically make network cards look like a child's plaything. With this hardware, it is often possible to apply certain register settings that will destroy the boards, aside from the possibility to hang your machine. Please note that this possibility is more common than you might expect. Also note that these kinds of boards are now becoming more common, and are more likely to make their way into the Open Source/Free Sofware/etc. community.
Given the trial-and-error nature of Open Source debugging, there would exist a significant possibility users would start frying their boards after tinkering with it. They would then direct all their anger toward the manufacturer, and the end result is obviously not good for either party. In this case, keeping the drivers closed protects the consumers from damaging their products and contains the damage to those few unlucky prototypes in the lab.
One other major concern for businesses is the cost of customer support. When drivers become Open Source, any Joe User now feels he has the right to call the design engineer and speak his mind at all hours of the day. Nevermind that Joe doesn't have the number; he'll find out if it kills him. Since Joe can't get his poorly formed hack to work, he has no compunction about calling Mr. Design person at 4 am to bitch about how bad Mr. Design's hardware is.
I am not making this stuff up. It happens every day to design engineers, who end up spending their entire working lives answering tech support questions to people that really aren't qualified to hear them. There is no way to move on to new designs when your email address is at the top of a Linux driver header file. Your life will be consumed with inane and demoralizing questions like "how to I run make?".
Engineers are blissfully shielded from all this when it's done in house, which keeps them happier and more good products rolling out the door. They don't have to support 10 thousand different compilers, repeatedly tell people not to use -O99 when they compile, or explain to people that you need version x.y of the foo library.
Granted, this is NOT an argument against Open Source support for hardware -- I sincerely hope that effort continues to succeed as well as it has been of late, because I plan on running Linux forever:). But everyone needs to consider these things when you start ranting "Give us all your source or we'll say bad things about you."
I thought I'd add some additional thoughts from inside Big Blue to this interesting conversation.
It should be noted that IBM has no plans to offer a commercial PC OS. This should come as no surprise, given our past failures and recent support of Linux (I think after we handed a big fat layup to M$ and the recent rise of Linux have squished that idea quite nicely).
However, it is also worth noting that IBM has created more than a dozen different OSes during its lifetime (AIX, VM, OS/2, OS/Open, OS/390, OS/400, the list goes on...) . It would be fair to say that we have no real emotional attachment to any one of them, which is why I think we're in a better position to support Linux than Sun or HP, who are clinging to their *NIXes like they're going out of style (- hey, a colloquialism that really fits!). Don't be fooled by their flashy press releases patting Linux on the back; I don't expect to see them really put Linux in the driver's seat for many years. Granted, IBM will probably follow the same road map, but at least we're more used to cutting our losses and switching out OSes than our other workstation buddies.
It is also very true that IBM once attempted to make everything electronic IBM proprietary. That mentality still survives in some areas in IBM, but being that IBM is primarily composed of engineers, most of us are completely sold on IEEE, ITU, and ISO standards. I hear a lot of people shouting vehemently of how IBM is the evil proprietary empire, but I don't think that's a fair assesment anymore.
I work in the Networking Hardware division (Slashdot reader: Networking? I didn't know IBM MADE switches and routers...), and there's only a few products I know of that use proprietary tech, and they are all going end of life. Gone are the glory days of 3270 and 3274. Everything else is purely IEEE and ITU, or else the safety and homologation guys come back and yell at us. All ATM, Ethernet, Token-ring, ISDN, FDDI, and T1/E1 are all our bread and butter now, not proprietary busses.
Anyways, I don't think IBM is worth criticizing anymore for proprietary behavior. We pretty much lost that battle soundly.
Comments welcome.
Re:hmmm... Now where have I seen this test before?
on
NOS Crossroads
·
· Score: 1
Your tone is curiously negative. I will overlook this and attempt to argue your points one at at time.
You assert that this is a "standard" setup for a large scale server. This is certainly not true. I have administered many systems, and there is no standard I would say predominates, and I'm sure most Slashdot readers would agree with me. Many times CPUs other than Intel are found, especially the much prized Alphas, are used (not PII/PIIIs). And do not believe with any certianty that Fast Ethernet is the connection of choice for a server that size. ATM, FDDI, or frame relay is certainly a better choice for what the server is supposed to be.
In addition, don't be fooled into thinking those Intel network cards were chosen at random. As posted many times before by astute Slashdot readers, NT has the ability to aggregate multiple Intel 100B links into a virtual fatter pipe, which is a driver tweak Linux currently doesn't have. I certainly would not think Intel cards are common fare (I would choose the DEC-Tulip cards if I had to use Fast Ethernet and wanted performance).
As for source level tweaking, since the testers are not regular Linux source contributors I highly suspect the value of these "tweaks". Yes, I did bother to read the ZD article, and I noticed a distinct lack of kernel MODULE tweaks (in the form of changing important module constants), which is where all of your performance boosts will come from (speaking generally, please no flames over this).
Now, as for their rating of SMP, I would much prefer to judge it against Linux's competitors than rely on ZD's judgement on this. Yes, they gave it a B, but I personally think it should be lower than that. Linux SMP still has a long way to go, and certainly Solaris and definitely IRIX will beat it quite handily in this category. IRIX has arguably the best thread performance of any other architecture I have used, which is no big surprise given their multiprocessor (Cray) designs. Having good SMP is CRUCIAL to scalability and superscalar performance, and Solaris and IRIX have been working on their implementations LONG before it surfaced in Linux.
As I said in my previous message, we just need to focus on SMP first and foremost. Once we have that down, our drivers (notably RAID) will probably be the next most significant performance yielding subsystem.
You say yourself at the end of your message that these are legit problems with Linux. I agree absolutely, and said the same thing in the first message I wrote. As for FUD, yes, I believe it IS FUD. FUD = fear, uncertainty, doubt. That is exactly what this test (and Mindcraft's) was. Those tests were deliberately crafted to expose Linux's greatest weaknesses to pursuade admins & users that it is not a viable platform. Propaganda, pure and simple, although to a lesser extent in the ZD test.
As for your suggestion about moving Samba into the kernel, I won't get into why that's a bad idea, but you might want to check out http://www.tux.org/lkml/ for a good explanation of kernel development.
Have a nice day.
hmmm... Now where have I seen this test before?
on
NOS Crossroads
·
· Score: 3
Why is it that all companies insist on picking hardware on which Linux performs the poorest? It seems our friends at ZD have been chatting with our friends at Mindcraft methinks (or perhaps M$ themselves).
Despite the fact that we seem to compare more favorably in this study than we did in the Mindcraft study, there is an extrememly important lesson we need to take away from this "losing in the benchmarks" experience as of late: we need to take these deficiencies and turn them into future strengths.
It was put very well by Linus himself in a previous poster's message. To paraphrase, anything that can be interpreted as a weakness in Linux by a media or testing agency must be improved. These are worthy pusuits, and if we keep doing them at the rate they are discovered, (unlike our M$ friends), we will eventually surpass all other OSes in every respect that matters.
We should probably place a particular emphasis on improving our SMP code, because that's the area we probably have the most to gain. All those other driver optimizations will only help us if by some luck the testing agency picks the same ones.
Anyways, I hope everyone won't get discouraged over this recent benchmarking FUD. The acceptance of good things is not always an easy road.
Slashdot Mirror
I can only shake my head after reading Hypothermia's summary. Did he have the same conversation he posted on his site? Are the Slashdot posters reading the same thing I read? This is what I saw in that conversation:
Here at NVIDIA we have over 60 people in marketing and unfortunately, someone who thought he was doing the correct thing was not. The contract that is on Hypothermia (sp?) is a document that we use for corporate to corporate promotions.
Translation: Someone here really f**cked up. (Note lack of apology).
Let's say if and OEM would like to do a banner for a show this agreement assures us that we have top billing with that promotion.
Then why is there all this text in the agreement about web sites? What does this have to do with a show?
Whatever you review is whatever you review...we've never asked anyone to pull a review for competitive reasons.
Yeah, but you guys sure have no problem pressuring reviewers into biasing for your card's strengths.
I feel really bad in your situation, because for the last 7 months you have been misled by a non-NVIDIA employee (intern, contractor, etc...). To Hypothermia, who had thought that this was an accurate PR rep, I apologize and for all of the grief/headache this has caused I apologize for that too.
What kind of company allows this to happen? Is NVIDIA such a loose operation as to allow non-NVIDIA employees to use their corporate email? Note that this does not satisfactorily explain Hypothermia's situation, because in the evolution of this whole ordeal Hypothermia clearly states that he spoke to at least two different people.
So this apology means nothing to me because none of Derek's explanations hold water. The apology I see only really applies to allowing someone to impersonate an NVIDIA employee.
All the opinions expressed above do not necessarily represent those of my employer.
Disclaimer: I am an IBM employee working on the PowerPC 40x cores. Adjust interpretation accordingly.
:).
spoonboy42 sez:
For battery operated devices such as handhelds and webpads however, they use considerably more power than their competition: The StrongARM, the Crusoe, and the (admitedly far less powerful) Dragonball and Coldfire. Performance-wise, the StrongARM is in about the same class as embedded PowerPC models, and the Crusoe is set to blow everyone away
Not totally true. The IBM 40x series does compete directly with ARM. Performance-wise, we do have a small edge over ARM. Power-wise, ARM has a small edge over PPC 40x. However, neither are anywhere close to realm of Crusoe in terms of power consumption.
I don't know Dragonball and Coldfire that well, but I am reasonably sure they don't compete well with ARM or PPC 40x in either power or speed.
Crusoe consumes, IIRC, in the realm of 4W avg. 40x chips consume less than 1W (including on-chip peripherals), and ARM is even less (500mW I think). So it's a big tradeoff. You pick your chips based on where you want to be in that power/speed curve.
So in short, if there's a power outlet handy, go with PowerPC, but to maximize battery life, StrongARM and Crusoe are the way to go.
That's a myth. Don't know where you got that idea, but I'm glad I could dispell it for you
Disclaimer: I am a design engineer on the embedded PowerPC team, interpret this accordingly.
:(
:)
Before I begin: don't be misled. The 68HC11 and the 405gp are two totally different ballparks. They do not compete in the same space.
faeryman sez:
I've followed the development of the for a while now, even having a few email conversations with Jonathon Thompson, Quong Ho Thoc, and Hagr Itstein (three lead developers). I told them about a few of my concerns but it looks like marketing prevailed
I am relatively new with the 4xx PowerPC team, but I've never heard of any of those people; I don't think they are developers (much less lead ones).
I don't see Linux being the right tool for this. I don't want to see this product fail since I know IBM is a good company. By all means everything else they made was a success, but the IBM 405GP looks like it will be a flop.
Umm, our customers sure seem to think it's the right tool. We got so much demand for Linux on 405 that we had to hire extra people to fully support Linux. As for 405gp being a flop, I don't know what planet you are on. 405 is selling so fast that it put a strain on our short term capacity. I don't consider a chip to be a 'flop' when Ericsson, Nokia, Cisco, and Alcatel use them in their products...
(1) Security - This is a big concern for me. Imagine some evil hacker getting control of this baby...now imagine if this was used in your bank or a military instituion. See the problem?
Umm, no, I don't. How exactly do you associate a SOC device with an Ethernet port automatically vulnerable to hackers? Is the 405gp somehow deficient in this regard?
While I commend the design of Open Souce, perhaps allowing the innerworkings of this to be accessable by a hacker is not good, even more so when it's an embedded system.
You are confusing connectivity with security. This article is about SOC's, and as far as their design is concerned they must be properly secured like any other computer system. Save the security tirade for a different forum.
(2) Expansion architecture - Check the specs on this thing. While a PCI slot is normally a good thing, wouldn't MCA or a propietary bus be better suited for this?
Are you f*cking kidding me? MCA? How many MCA devices can you buy? Not just cards, I means chips (which is what the vast majority of 40x's will be talking to). Almost zippo. Now how many different PCI devices do you think you can find?
Linux runs on the MCA fine, and I think it's low overhead and fault-tolerant properties are better than a run of the mill PCI slot for this. Or a new bus design could be implemented. IBM benefits with better performance, we as a comunity benefit from more GPL code being released. Sound good?
Absolutely not. The whole point of choosing PCI is because it is commodity, fast, reliable, and supported by almost every modern OS. It seems that you are desperate to reinvent the wheel here.
3) Operating system - [flamesuit] I like Linux, but I don't think Linux is the best tool for this. IBM has made the decision to go with Linux, so I'll respect that.
Like I said before, our customers want Linux. Linux is not the only OS we support. Actually you can put damn near any OS on the planet on it; IBM doesn't have support for them all however. You want a lighter weight OS than Linux? Fine, use OS/Open, which is IBM's little creation (works very well and supported too).
Scalibility and performance are key here, and QNX can deliver better than Linux.
Well, if you think so, then there's no reason you can't run it on 405gp.
Again, I don't like being negative but I don't think the IBM 405GP will do that well. I want to be proved wrong though, I want to see Linux progress and gain market share, and I want to see IBM be profitable....but Linux just ain't gonna cut it for this one my friends. Please tell me I'm wrong.
Well, since you asked so nicely...
Being an IBM employee, I feel the need to stand up for the good Mr. Ayd :).
:).
Aww, talk about sour grapes! They've hurt IBM's feelings, because IBM sells really smokin' computers too.
Seriously, I think David misclassified GRAPE 6 quite a bit. I don't think it's quite David's fault, because the article writers don't know the difference between 'supercomputer' and 'attached processor'. ABC News didn't really apply the term 'supercomputer' correctly either.
The term 'supercomputer' is more of a marketing term than anything else. Technical people only use it when they want to describe a general capability. AFAIK there is no concrete definitions of 'supercomputer', and if there were they would likely change daily. GRAPE 6, from the information I can see, is really an attached processor.
Attached processors can be an ARM chip on your network card to a GRAPE 6. Interanally, GRAPE 6 is a full custom, superscalar, massively pipelined, systolic array (say that 5 times fast). That basically means that data comes in one side of the board, and after n clock cycles the answer comes out the other side. There is no code other than a program running on the host computer which generates and consumes data, and every piece of the algorithm is done in hardware.
"What happens when the algorithm changes?" you might ask. Well, then you're screwed. You have to do a whole new board. Many boards use programmable chips as their processing elements, and can reprogram them when bugs or features get added, but these guys appear to be using ASICs. Great for speed, bad for flexibility.
Even though David Ayd was mistaken about the architecture, this idea has been around for quite a while also. The SPLASH 2 project was one of the first successes with this idea. There is also a commercial company selling boards using that idea but with completely up to date components (compared to SPLASH).
Still, in July of 1995, the GRAPE 4 became the world's fastest computer, breaking the 1 teraflop barrier with a peak speed of 1.08 TFLOPS.
Well, we really can't argue with that, can we, Mr. Ayd?
This architecture lends itself to extremely high throughput. It's no surprise that these perform so well. NSA uses architectures just like this to do it's crypto crunching. Brute forcing doesn't look so bad after trying one of these
I respect your right to post your opinion on this subject in the Slashdot forum. However, there is a lot that needs to be said in defense of the Slashdot admins. The following important facts are never considered in posts like yours:
They are only human, they also make mistakes.
There are several different admins, not just one of them. Sometimes they don't each know what the other admins have reviewed or posted recently. One admin may accept a story another rejects.
Guestimating the amount of crap they must have to filter out on a daily basis, I figure their record is pretty good.
They probably gauge the importance of a topic on how many submissions they get. Being the first submitter gets you nothing. If you are the first one (or the only one), you probably won't get the credit unless it's earth-shattering news.
If you feel slighted by having them reject your stories, you really need something better to do with your time (unless you are a journalist ;) ).
If you're looking to make an impression on the /. community do it with well written posts rather than with story submissions.
I do agree with you though about the double posting of stories (IBM supercomputing, patents). The last few have been only characterizable as gross errors.
The Good:
There already is a great benchmark for processors, and it's called SPEC. Yes, it's not open source, but it's really quite reliable for comparing CPUs of any architecture. As slashdot user "cweber" pointed out in his post, they have been doing this for 11 years, and they periodically revise their benchmark suite to stress CPUs more uniformly.
The open-source method. This is really good to ensure that there are no cheaters at the benchmark level.
Tom's interesting ideas on Crusoe. This stems from the fact that SPECmarks don't quite approximate real usage that Crusoe depends on to use it's hotspot optimizations. However, we are interested in the raw sustained speed of the processor (in this case), not the speed of the OS or it's task swap latency. Tough problems to solve.
Open-source means that the benchmark code will be able to take advantage of the best compiler available for the target CPU (see comment at end).
The Bad:
Anyone who has done benchmarks knows that even small variations in system config can have strage or harmful effects on the benchmark results. This open-source effort is going to have to have a database of hardware configs in order for this to be useful.
The Ugly:
Vendors are going to oppose this (at least not support it). Why? Because plain and simple they have an interest in promoting the most favorable statistics possible about their products. They want to keep feeding you "polygon fill rates" and "texels per second" because their card may not stand up in a direct test program comparison. Plus, they are just dying to convince you that they have new BogusMarketingAcronym (tm) technology and their competitor does not. Nevermind that SSE and 3Dnow do pretty much the same thing -- companies have an interest in differentiating themselves as much as possible.
If this benchmark actually takes off (and gets widely accepted), we might get cheaters at the firmware or hardware level. This has happened before -- although which company it was and which benchmark they cheated I can't remember. I can't find it on the net or remember to save my life (sigh)...
I also need to say something to the people who think a processor should be judged independently of a compiler. This is just plain dumb. Why? Because a processor and it's compiler are a team. You can't use one without the other. When a chip is designed, there is a direct information dependence between the chip architects and the compiler writers. They are designed as a pair (ideally), and they should be tested as such. If a given compiler has great optimizations, then great! That means the compiler understands its target real well. It is a win for both the CPU and the compiler for pulling it off. This compiler is going to do the same kinds of optimizations when vendors use it to write programs, so that helps the comparison between benchmark code and apps.
However, I can see the need to compare not only the best compiler, but GCC as well, because of its broad acceptance. But if you are serious about performance, and want to get every once of juice out of your chip, you use the vendor provided compilers, not GCC. Don't get me wrong, GCC is great for compliance and portability, but it usually doesn't compare well with vendor compilers for generated code speed (with the possible exception of IA-32).
Ars Technica also published, a while back, some good information regarding CPU benchmarks. Check it out if you are interested in SPEC or CPU benchmarks in general.
This is correct. As an IBM microelectronics employee I can say:
I don't remember hearing about any agreement between IBM and AMD.
AFAIK, this is true. We (IBM) have no manufacturing relationship with AMD.
This technology is intellectual property of IBM and would not be available to anyone unless IBM decides more can be obtain from licensing the process.
This is also correct. However, something important does need to be pointed out though. This process will (AFAICT) be the next generation technology for IBM's processor and ASIC designs. Again, IIRC, CMOS-8S is our latest and greatest, so this process will likely be called CMOS-9(S|SF).
This means that any customers using IBM for their manufacturing (and back-end) can use this technology, not just IBM. Since Transmeta uses IBM manufacturing, they have the option of using this process (if they choose to, right now I think they're in CMOS-8SF). Lou Gerstner has declared that there will be no sacred cows in IBM, so everything we make as a product must be available for sale outside the company as well. [Shameless plug: All the more reason for companies to go with us, because our silicon roadmap kicks ass].
Anyways, as is public knowledge, the Power4 is currently using a modified version of CMOS-8S, which provides low runtime electrical failure rates. CMOS-8S technology is basically 0.18 micron junction and trace widths, using copper metal over insulator (SOI). For the final release, they will probably use this process (CMOS-9S?).
Disclaimer: All this is public knowledge, none of it is IBM confidential stuff.
Don't make opinions without the data to back it up.
:)
;P
Oohhh, you opened yourself up on this one...
Fallacy #1:
The CPU's are *MORE EXPENSIVE* yes, overpriced, no. Look at a comparison in the CPU's on just a very simple level. The CPU has 8 Megs of L2 Cache. Not 256k, not 512k, not 1 meg, 8 Megs. That Cache is running at CPU Speed. If there's anything at all that's slowing their speed down, its the large amounts of L2 Cache they run with their servers.
Remind me again why 8Mb of L2 is needed when programs have 95+% cache hit rates with 1Mb (often less; hmmm...)?
They really are overpriced. I am certain an Alpha 21264 can be had for a fraction of the price of these things, and its specmarks are int-27, fp-58, which is too close to make a big deal out of.
Fallacy #2:
Now getting back to PCI cards being overpriced, in Sun's specifications, it dictates that all hardware MUST have a PROM with the drivers on it to be certified as Sun Compatable. At boot time, all of the PROM's are polled and all of the drivers are loaded at the hardware level. Plug and play that really works, imagine that...
Gee that's funny, I don't remember anything in the PCI spec about having to have PROMs...
This is bad for two reasons. First, I hate it when vendors screw with the PCI specs. It was adopted as a spec for a reason, not so vendors can then change it so it only works with their HW. Just ask linux-kernel how much they love broken PCI workarounds...
Reason 2 is that "plug and play" (a Micro$soft term BTW) can be had for PCI without having those PROMs on board. The reason Sun uses those PROMs is to get licensing fees from hardware vendors to get that "Sun Compatible" moniker. Creative revenue generation no doubt, but it prevents PCI interoperability, which is a Bad Thing.
Fallacy #3:
> The OS is waaay overpriced.
Free, yeah way too expensive.
Wow! You got Sun to give you free copies of Solaris for Sparc? Last I checked you still had to pay a hefty $90k (!) for an OS with nearly equivalent functionality as Linux. I call that a bad deal.
Fallacy #4:
First, all of the workstations and servers have TRUE plug and play. There processors scale from Laptops (anyone remember Tadpoles) all the way up to Mainframe-sized computers (E10k). Also - hot-swappable I/O and CPU/Memory in the Enterprise systems. The E10K can scale up to 64 450 Meg processors with 8 megs of L2 Cache, 64 Gigs of Ram, and can run 4 Virtual Machines that can be dynmically allocated on the fly.
Don't be fooled into thinking only Sun has hot swappable drives and IO. Geez, Dell Proliants have had hot swap SCSI since 1997. Hot swap IO? That has IBM written all over it as well. However, the best argument is scalability. Forget laptops to E10ks, how about Linux on a Palm to Linux on an IBM/390 Mainframe? What two extremes could you possibly supply that's wider than that? (E10ks are toys compared to S/390s).
My money's on Linux. If you want scalability and interoperability, Linux is the answer. As for reliability, Linux has a little ways to go to catch up to Solaris/VM/MVS/BSD, but it's getting there.
With all that said, the UltraSparc-III looks like a very good design from Sun. You rarely see appropriate amount of thought applied to the reality of processor shortcomings these days, and they hit the right aspects.
Disclaimer: I am an IBM employee
/. readers. The announcement, as stated, applies to Enterprise Servers, which in IBM lingo means RS/6000, AS/400, and OS/3[7-9]0 machines.
Um, I think my friend Mr. Malda has confused some
As far as I can tell, this does not affect notebooks, PCs, and Netfinitys. They fall under a separate division of IBM and have their own "master plan". This is somewhat moot however, since Linux does run fairly well on these machines anyways.
As some readers insightfully pointed out, there are obvious motives for this. AIX, VMS, and VM are expensive to develop and time consuming to maintain, and IBM makes more money off the hardware anyways. IBM still has very strong hardware expertise, and the best reason to buy a RS6k is the hardware architecture (that and all the reliability aspects).
Don't have the misconception that IBM's enemy is Microsoft. Although we compete with them, our real competitor is Sun. Sun competes heavily in all the same areas we do, and Linux is the perfect way to help us fight the the workstation battle.
Since it is obvious to me that Sun has no intention of really supporting Linux until it begins to threaten their survival, I'm all for IBM and Linux partnership. This means IBM will contribute to linux kernel development for all of the products mentioned above, which should be quite valuable to Linus and Alan.
As for applications, that too falls under a different IBM division. I can't tell you if Notes or Smartsuite are coming for sure, but I wouldn't be suprised to see some changes in light of this announcement.
As mentioned several times previously, the main box featured in this article is a DWDM router, not an IP router. There is a big difference, because they do very different things. See previous posts for details.
Lucent just recently finished their purchase of Nexabit, a private datacomm company. Nexabit currently is shipping the NX64000, a true 6.4 terabit IP router mentioned at the bottom of the article.
Lucent is the only company I know of capable of routing OC-48 IP at line speed. They have imminent plans to route OC-192 IP at line speed, and I expect them to release it soon. Some can route gigabit ethernet, but routing OC-48 and up is where the men are separated from the boys.
Lucent has one other competitor in the terabit routing space, and that is Juniper. Juniper is the only other company actually shipping a product. Avici, Zuma, NEO, Ironbridge, and Pluris all claim to have products, but aren't actually shipping anything capable of routing more than 1 terabit across their backplane/switch fabric.
In any case, Lucent's box has the most single-chassis bandwidth of any competitor. Several of the aforementioned companies are trying to play PR games by stringing multiple boxes together, but you definitely can't achieve terabit speeds by daisy-chaining boxes.
All of this information is true to the best of my knowledge, as I have personally talked with all companies I mentioned above. If I were an ISP, the box of choice would be a no-brainer.
I can see the headline now...
In a widely awaited move, Microsoft has announced it's new nervous operating system version 1.0, Microsoft Brain (tm). Co-developed in Redmond, WA and Reading, PA, this new operating system is designed with human efficiency in mind.
"No more unecessary arm movements!" proclaims John Q. McFoo of Microsoft. "We have achieved partial control of humankind, and we eagerly await leg control as well" says McFoo. "Unnecessary arm motion is now a thing of the past. This is an energy savings for all consumers" McFoo adds.
Microsoft is widely expected to deploy Brain 1.0 in time for Christmas, so users can purchase as many Microsoft products as their budgets allow. "With control of the arms, we anticipate a huge increase in Microsoft product purchases" says industry analyst Bob Smith. "Without leg control, however, getting them to the store is another matter" cautions Smith.
Citing a stunning 90% uptime figure, Microsoft is touting this as a real win for reliability. "Losing use of the arm for only 10% of the time isn't so bad" claims McFoo. "Besides, with the new Microsoft Nerual Uptime (tm), you can have friends paged to reboot you" during downtime, he concluded.
this is a joke, and you should take it as such
RAMBUS is still a bleeding-edge technology. Signal integrity is a major headache, and Intel has the unlucky fortune to be the first to try it; there are bound to be problems.
RAMBUS is not a serial at the physical level, it is a parallel channel with a 16-bit width.
To offset the relatively small bus width, a super fast clock is used. Currently I think the i820 is designed for 600MHz, but I'm not 100% sure on that.
RAMBUS is a packet-based scheme, where multiple transactions can be pending at any given point in time (similar to TCP/IP). This allows non-blocking memory accesses and better bus utilization.
Intel's current RAMBUS implementation might not be cost effective over SDRAM, but given a year or two probably will be (if they can get past the current problems).
I don't know what you guys are thinking of when you say RAMBUS sucks. RAMBUS isn't another USB (yuk) -- it is an extremely well thought out technology that is (admittedly) somewhat ambitious. RAMBUS scales much better than any existing memory technology. I see people bitching about RAMBUS, but SDRAM will probably max out at 150 MHz next year.
Please understand that Intel != RAMBUS. Don't hate RAMBUS because you hate Intel; RAMBUS was founded by two people who were very smart guys and as a separate entity.
Intel's problem is probably not with the i820 itself, but the way the RAMBUS signals behave on the bus. They have noise and termination problems, which are very similar to SCSI problems. This is why the last slot on the bus is problematic -- having a RIMM or nothing at all makes a big difference to the the signalling scheme.
This problem will not affect SDRAM, even with an i820 (unless there is a different problem I don't know of).
You posted some great comments; but since you don't have an email listed, I will respond here and try to keep it brief.
For one thing, allowing an outside entity to control an appliance which you have purchased sounds like a potential privacy issue to me - without some really strict regulations on what a company can do with the information, do I really want a company to know when & how much toast I make? (Slightly more seriously, think DIVX...)
I agree with your fears. However, I feel that this will be inevitable, regardless of the privacy implications.
In any case, I see NAT as a highly desirable way for me to control what is talking on my subnet to stuff outside the subnet, regardless of whether you're talking IPv4 or IPv6.
NAT is not designed for security, it just coincidental that it is more secure than traditional means. If you want security, IPsec is the best way to go (and is much easier on IPv6 anyway).
Why is there some limit of effort @ opening NAT walls to different protocols? If the protocol is simple, then you can communicate through a single connection, and the owner of the NAT box can open that single port & attach it to the proper machine.
The limitation I speak of is a manpower/development limitation. It is not efficient to have someone spend their valuable time fixing the current NAT implementation for the latest and greatest vendor protocol. Often, vendor protocols embed the source/destination address somewhere inside the packet, which is why NAT fails. IPsec is a great example; it needs to embed the source and destination IP inside an encrypted packet. No NAT program will ever be able to route this correctly, which means people running NAT can't use IPsec, which won't fly economically.
Maybe I'm not quite understanding what you mean by "IP expansion" using ports, but as far as I'm concerned NAT is _supposed_ to make your subnet look like a big server on a single IP address, and I can't think of any performance/utilization metrics used by ISPs where this paradigm would cause "Bad Things" to happen.
By "IP expansion" I meant the mapping of unused ports on one host to ports on a different host (NAT), thus virtually giving you "more IP addresses" (bad phrase, sorry).
ISP metrics depend heavily on being able to uniquely identify evey host in the network, internal and external, for a variety of very good and time-tested reasons (I won't go into detail). NAT is designed to obscure this, and thus represents a problem for any network admin.
Seeing some discussion of IPv4/v6 in this forum is starting to scare me, so I thought I'd try and clear up some major misunderstandings.
I see a lot of posts saying that IPv4 is just fine and we should stick to it. Wrong, wrong, wrong. I realise that people on this group don't design routers every day, but I think you would be amazed at how much protocol hacking goes on under the covers. The vast majority of routers out there do some amazing things to try and hack together things like quality of service (QoS) and NAT that IPv4 just isn't designed to do.
Yes, IPv4 is working. But the amount of time now spent in the design phases to kluge together ways for NAT and QoS to work is becoming way more than most design houses will stomach. Features like VoIP, VPN, and QoS have major cash potential for ISP's, and they in turn will pay to get capable equipment. Doing this with IPv4 is a bitch, and a lot designers secretly wish IPv4 would go away and use IPv6 instead, because VPN and QoS are much easier to do.
One other major piece of misinformation here is that all boxes need to be replaced for this to happen. Not so. The vast majority of routers, hubs, switches, and all desktop computers are perfectly capable of running IPv6 right now. It involves a code load change, not a hardware upgrade. On a related point, most ISPs completely replace all their network boxes every 2 years anyways, so the threat of scrapping all hardware for IPv6 won't faze them much anyway (it's part of their cycle).
The last point is that people don't think that their toasters need IP addresses. This is also not so! Yes, in the next 10 years your toaster will need an IP address. Why? Because ToasterCompany will want you to do a firmware upgrade on your toaster because their have been field problems (like toasters burning operators). You will go across the wire, flash your firmware, and now your microprocessor-controlled toaster has CrispyToaster(tm) v1.16b firmware. We've already seen web servers implemented in ~4mm PIC processors, so expect them to become popular in the near future in your favorite household appliance.
To do this, you need an IP address (to speak IP of course). Please don't tell me how great NAT is... yes, I also run a Linux ipMasq box which works fine, but NAT fundamentally breaks many of the underlying IPv4 mechanisms. We can't keep dumping more patches to the NAT engine every time someone wants to NAT some new protocol; eventually we are going to reach a limit of effort.
Also note that using ports as a means of "IP expansion" is also a Very Bad Idea. A port is specifically designed (in TCP/IP spec) to represent a different service on a given host, not across different hosts. Yes, you can use this technique in NAT, but it tends to make performance/utilization metrics used by ISP's blatantly wrong, which leads to Bad Things.
Please also read Singal11's message above, he is right about the routing table issue. There is no current proposal (beyond CIDR) which can solve this problem. Also, see jd's post, it is a good summary of why IPv6 is needed.
It seems I managed to misspell Cisco every single time. Maybe it's the trauma of being suddenly out of a job :)...
:).
u shud hire me i'm a gud spelr
You might notice I am the one who submitted this story. I am also an employee of IBM's Networking Hardware Division, and I think I can shed some light on this "partnership."
:).
Let me be blunt. My division has been dying a slow death for several years now, and this is the last nail in the coffin. Up until this agreement, we produced hubs, routers, and switches, which is now (almost) entirely sold to Cicso. Our division of 2000+ people are now all spending the next two weeks cleaning up our resumes.
Cicso made out like champs on this one. They have no obligation to support our old boxes, which has been kept squarely on IBM (at great support cost as well). Cisco has acquired every design aspect of our data networking products, right down to the source code.
IBM Global services, however, will sell Cicso stuff, and Cicso will make huge inroads into the Mainframe and Channel Attached markets (i.e. ESCON and parallel channel) which were previously dominated by us (for whatever that was worth).
Don't be fooled by the large $2 billion number -- they would have spent that much anyway on our chips. $2 billion over 5 years comes out to $400 million per year, which is not much for someone with volumes like Cicso. They have already been making deals with IBM Microelectronics before this was announced.
Token Ring and SNA, however, will remain the IP of IBM. There will be a small group of people left here to maintain development on these fronts, but don't expect any significant new designs on this front. Which is fine with Cicso, because these technologies aren't really going anywhere anyway.
Ironic, really, because at one point in our division's history we had the perfect opportunity to buy Cisco, lock, stock, and barrel. Needless to say we have been kicking ourselves daily for that screw up.
And on a lighter note, if anyone reading this is interested in hiring a hardware systems/low level code design engineer, mail me here
Nearly everyone has remarked how extremely awful his writing is, so I won't add to the pile here. People have also noticed his startling revelation that "The distinction [between decimal and binary] is that, this is a Logical expression, that has no Equivalence. [LOL]"
:).
If you actually want to read his paper, just skip to the bottom where he displays his amusing tables . Any ideas what those small numbers in the last column mean (the 1, 10, and 110 ones)?
However, if you were at all like me and dissected his "paper" for what he was really trying to say, you may have actually noticed (if you were successful) that he considers the subnet mask part of the address (look at Table 1 in his "appendix"). Since TCP/IP fundamentally routes a IP datagram around using only the destination IP address, this won't work at all. Datagrams don't keep a subnet mask around with them, they are nodal notions only. His scheme will actually yield several thousand hosts which have the same IP address, which definitely won't work.
Oh and I love : "To render a more pointed fact, I needed to pass a CISCO Certification Examination." That says it all
Nearly everyone has rightly remarked how extremely awful his writing is, so I won't add to the pile here. People have also noticed his startling revelation that "The distinction [between decimal and binary] is that, this is a Logical expression, that has no Equivalence. [LOL]"
However, if you were at all like me and dissected his "paper" for what he was really trying to say, you may have actually noticed (if you were successful) that he considers the subnet mask part of the address (look at Table 1 in his "appendix"). Since TCP/IP fundamentally routes a IP datagram around using only the destination IP address
I realize there are a decent amount of posts about why this strategy is good for Linux, but maybe a closer look reveals why this is so good.
SGI, currently, has two things Linux desperately needs. The first is a journaling file system. I don't think I really need to explain why this is a good thing; all it takes is one bluescreen with NT and you'll understand me completely. SGI's is mature and stable, and has a very good reputation among the workstation community. Nuff said.
The second, IMHO, is even more important. SGI has (again IMHO) the most outstanding implementation of thread-level parallel processing. Almost all the other platforms you care to look at (IBM, older Sequent, Sun) either depend on MPI coding or are designed using close-coupled SMP, which tend to reach their limits quickly. It seems SGI has profited greatly from their acquisition of Cray Research.
SGI has a great thread library which they have mapped to their NUMA implementation, which scales a little better than SMP does (I'll skip the technical explanation here in favor of the point). SGI's extensive knowledge with multiprocessing comes at the perfect time for Linux, which is this very minute undergoing heavy kernel modifications to better facilitate thread level parallelism.
SGI has so much to offer in terms of technical skill that Linux could absorb at this point in time. Make no mistake, this is a perfect opportunity for Linux to milk the expertise from SGI, who needs Linux to survive.
Funny to see that article by the EFF. They have no idea how much they have underestimated the NSA.
I used to work for a company called Annapolis Micro Systems (Annapolis, MD). They specialize in selling high performance configurable computing boards (both VME and PCI versions). These boards are especially suited to numerically intense algorithms (image processing, encryption).
It's no big surprise that the single biggest customer of AMS is the NSA. They routinely bought Wildfire arrays (see website) by the dozens. Two guesses as to what they were using them for, and the first doesn't count...
It must be emphasized what kind of power these arrays confer. Anyone familiar with configurable computing knows several things:
1) It's not for the light of wallet.
2) It requires a hefty design overhead for each application.
3) It presents the fastest known solutions to almost every NP-complete and iterative solution problem ever posed.
I am a hardware designer by trade, and I can tell you that is almost beyond my ability to measure what kind of processing power these boards can enable, purchased in groups.
Be afraid, be very afraid...
(Author's note: from my limited knowledge of encryption, keys larger than 1024 bytes probably aren't crackable by brute force in this day).
Let me start by saying this article has quite a bit of capitalistic merit. My company (IBM) should certainly pay more attention to this.
:). But everyone needs to consider these things when you start ranting "Give us all your source or we'll say bad things about you."
HOWEVER, I feel I must post a "caution" (for lack of a better term) about this feature, which has evolved through years of Finding-Out-the-Hard-Way.
There are two problems that this article does not address. By releasing a driver for a piece of your hardware in Open Source form, you open up a big can of worms in two areas: customer support and hardware damage.
I will speak on the second topic first because it's probably less obvious. I have worked in houses which design some pretty complex devices. These devices typically make network cards look like a child's plaything. With this hardware, it is often possible to apply certain register settings that will destroy the boards, aside from the possibility to hang your machine. Please note that this possibility is more common than you might expect. Also note that these kinds of boards are now becoming more common, and are more likely to make their way into the Open Source/Free Sofware/etc. community.
Given the trial-and-error nature of Open Source debugging, there would exist a significant possibility users would start frying their boards after tinkering with it. They would then direct all their anger toward the manufacturer, and the end result is obviously not good for either party. In this case, keeping the drivers closed protects the consumers from damaging their products and contains the damage to those few unlucky prototypes in the lab.
One other major concern for businesses is the cost of customer support. When drivers become Open Source, any Joe User now feels he has the right to call the design engineer and speak his mind at all hours of the day. Nevermind that Joe doesn't have the number; he'll find out if it kills him. Since Joe can't get his poorly formed hack to work, he has no compunction about calling Mr. Design person at 4 am to bitch about how bad Mr. Design's hardware is.
I am not making this stuff up. It happens every day to design engineers, who end up spending their entire working lives answering tech support questions to people that really aren't qualified to hear them. There is no way to move on to new designs when your email address is at the top of a Linux driver header file. Your life will be consumed with inane and demoralizing questions like "how to I run make?".
Engineers are blissfully shielded from all this when it's done in house, which keeps them happier and more good products rolling out the door. They don't have to support 10 thousand different compilers, repeatedly tell people not to use -O99 when they compile, or explain to people that you need version x.y of the foo library.
Granted, this is NOT an argument against Open Source support for hardware -- I sincerely hope that effort continues to succeed as well as it has been of late, because I plan on running Linux forever
I thought I'd add some additional thoughts from inside Big Blue to this interesting conversation.
It should be noted that IBM has no plans to offer a commercial PC OS. This should come as no surprise, given our past failures and recent support of Linux (I think after we handed a big fat layup to M$ and the recent rise of Linux have squished that idea quite nicely).
However, it is also worth noting that IBM has created more than a dozen different OSes during its lifetime (AIX, VM, OS/2, OS/Open, OS/390, OS/400, the list goes on...) . It would be fair to say that we have no real emotional attachment to any one of them, which is why I think we're in a better position to support Linux than Sun or HP, who are clinging to their *NIXes like they're going out of style (- hey, a colloquialism that really fits!). Don't be fooled by their flashy press releases patting Linux on the back; I don't expect to see them really put Linux in the driver's seat for many years. Granted, IBM will probably follow the same road map, but at least we're more used to cutting our losses and switching out OSes than our other workstation buddies.
It is also very true that IBM once attempted to make everything electronic IBM proprietary. That mentality still survives in some areas in IBM, but being that IBM is primarily composed of engineers, most of us are completely sold on IEEE, ITU, and ISO standards. I hear a lot of people shouting vehemently of how IBM is the evil proprietary empire, but I don't think that's a fair assesment anymore.
I work in the Networking Hardware division (Slashdot reader: Networking? I didn't know IBM MADE switches and routers...), and there's only a few products I know of that use proprietary tech, and they are all going end of life. Gone are the glory days of 3270 and 3274. Everything else is purely IEEE and ITU, or else the safety and homologation guys come back and yell at us. All ATM, Ethernet, Token-ring, ISDN, FDDI, and T1/E1 are all our bread and butter now, not proprietary busses.
Anyways, I don't think IBM is worth criticizing anymore for proprietary behavior. We pretty much lost that battle soundly.
Comments welcome.
Your tone is curiously negative. I will overlook this and attempt to argue your points one at at time.
You assert that this is a "standard" setup for a large scale server. This is certainly not true. I have administered many systems, and there is no standard I would say predominates, and I'm sure most Slashdot readers would agree with me. Many times CPUs other than Intel are found, especially the much prized Alphas, are used (not PII/PIIIs). And do not believe with any certianty that Fast Ethernet is the connection of choice for a server that size. ATM, FDDI, or frame relay is certainly a better choice for what the server is supposed to be.
In addition, don't be fooled into thinking those Intel network cards were chosen at random. As posted many times before by astute Slashdot readers, NT has the ability to aggregate multiple Intel 100B links into a virtual fatter pipe, which is a driver tweak Linux currently doesn't have. I certainly would not think Intel cards are common fare (I would choose the DEC-Tulip cards if I had to use Fast Ethernet and wanted performance).
As for source level tweaking, since the testers are not regular Linux source contributors I highly suspect the value of these "tweaks". Yes, I did bother to read the ZD article, and I noticed a distinct lack of kernel MODULE tweaks (in the form of changing important module constants), which is where all of your performance boosts will come from (speaking generally, please no flames over this).
Now, as for their rating of SMP, I would much prefer to judge it against Linux's competitors than rely on ZD's judgement on this. Yes, they gave it a B, but I personally think it should be lower than that. Linux SMP still has a long way to go, and certainly Solaris and definitely IRIX will beat it quite handily in this category. IRIX has arguably the best thread performance of any other architecture I have used, which is no big surprise given their multiprocessor (Cray) designs. Having good SMP is CRUCIAL to scalability and superscalar performance, and Solaris and IRIX have been working on their implementations LONG before it surfaced in Linux.
As I said in my previous message, we just need to focus on SMP first and foremost. Once we have that down, our drivers (notably RAID) will probably be the next most significant performance yielding subsystem.
You say yourself at the end of your message that these are legit problems with Linux. I agree absolutely, and said the same thing in the first message I wrote. As for FUD, yes, I believe it IS FUD. FUD = fear, uncertainty, doubt. That is exactly what this test (and Mindcraft's) was. Those tests were deliberately crafted to expose Linux's greatest weaknesses to pursuade admins & users that it is not a viable platform. Propaganda, pure and simple, although to a lesser extent in the ZD test.
As for your suggestion about moving Samba into the kernel, I won't get into why that's a bad idea, but you might want to check out http://www.tux.org/lkml/ for a good explanation of kernel development.
Have a nice day.
Test server:
4 Pentium II/III CPUs
4 Intel NICs
RAID l5
2G RAM
Apache/Samba/no kernel tweaks
Why is it that all companies insist on picking hardware on which Linux performs the poorest? It seems our friends at ZD have been chatting with our friends at Mindcraft methinks (or perhaps M$ themselves).
Despite the fact that we seem to compare more favorably in this study than we did in the Mindcraft study, there is an extrememly important lesson we need to take away from this "losing in the benchmarks" experience as of late: we need to take these deficiencies and turn them into future strengths.
It was put very well by Linus himself in a previous poster's message. To paraphrase, anything that can be interpreted as a weakness in Linux by a media or testing agency must be improved. These are worthy pusuits, and if we keep doing them at the rate they are discovered, (unlike our M$ friends), we will eventually surpass all other OSes in every respect that matters.
We should probably place a particular emphasis on improving our SMP code, because that's the area we probably have the most to gain. All those other driver optimizations will only help us if by some luck the testing agency picks the same ones.
Anyways, I hope everyone won't get discouraged over this recent benchmarking FUD. The acceptance of good things is not always an easy road.