In the workgroup environment, having a drive spindle for every seat is a waste. Imagine a server serving 30 terminals but having 30 drives inside the server?! It is a popular mindset to have 30 autonomous computers each with their own autonomous operating system complete with autonomous applications on autonomous disk drives. That simply isn't practical, but it is totally acceptable for current IT thinking.
When I read the article, I realized that it was Windows specific when I got to the part about the guy wanting to put his swap into a RAM-based disk. What's up with that? Wouldn't you simply buy more system RAM if swapping was becoming an issue?
Anyway, a few things I've done to get more performance out of my filesystem was I set kupdated's period to 'never'. The default is for kupdated to perform a sync every 5 seconds! I altered this behavior by changing the values in the kernel source, but it can be altered much more cleanly by setting the values in/proc. Turning off kupdated on a busy system with slow disks has improved performance quite a bit. Caveats are I'm running a server that NEVER freezes or has a kernel panic, and the system is on a battery backed UPS.
Another great performance increase was installing Squid and giving it its own 256mb RAM disk for web cache.
Any single user on an autonomous computer can get similar benefits by making a small RAM disk and making a soft link for their browser cache to it. Put a script in/etc/init.d to gzip the files on shutdown and unzip them on startup.
What happens with Sun depends on price commoditization of the 4-way and 8-way space with the forthcoming AMD Opterons. If that really happens, and Sun doesn't adapt, then that segment could go away for them.
I think the issue of whether to self-build or buy premade comes down to leveraging one's areas of expertise. If you or your staff can build your own servers, you get the brand names on the inside.
If you buy premade computers, you get the brand name on the outside, and service and support and an easier way to figure out your IT budget.
If you can roll your own, your costs CAN be lower, in-house service and support CAN be better, faster and cheaper. For my money, computer science is a lot more fun and the results are a lot more reliable with in-house made computers running Linux from Scratch than it would be with Dell and Red Hat.
Is like I see it. They're already losing out to Linux and BSD on the server side of things. Now they didn't even get their act together enough to have something for the Opteron launch.
By the time their crappy server OS does get launched, they will be facing an entrenched group of free OSs that have 100% market share.
Just because you don't understand how to build XFree86, and think it takes a long time, you claim that XFree itself is flawed?
Unfortunately, it is the blind eye/ear attitude that is at the core of the issues with XFree86. Yes, I know how to build Xfree and don't care how long it takes. And I never complained about how long it takes.
Thankfully, I seek out documentation OUTSIDE the XFree source. The archaic imake system, the need for 121 files in xc/config/cf! What's up with that? How is that supposed to be better than configure --prefix etc.etc?
I sure was lucky to find out about WORLDOPTS="", otherwise, if the compilation had hit a snag, I may have never known, because the XFree compile would happily chum along. Fine maybe for some systems. Maybe it is cool to grep an 11 megabyte &> log file. Maybe it is old school.
Keith's code is nice, is creative and works well, it is just the XFree86 World system he's fitting into. Fontconfig package 2.1 took me a long time to get right.
I just think the architecture of the project is what's a mess. I compiled the new 4.3 on a Mac yesterday, and I find the project is stuck in an Imake Spin Cycle. Oh sure, somewhere in all that mess is a document that tells you how to compile 'just the servers' or maybe tells you how to build it without the fonts, or maybe even how to build it without those pathetic utilities, fonts and never-updated docs.
If I was King of XFree86, I'd first open it up to more people, then I'd tear out the utilities and put them separate, put the fonts separate, throw away the/xc/config monstrousity and replace that with configure --prefix= etc. etc.
Separate pswrap, mkshadow, xau, xnest, xext, all the gl's, xt, xv, xi, pex, speedo. The list is wildly bloated. Sure, maybe all that junk can be separate projects on the same Sourceforge page, but as it stands now, it is a whale.
I've also downloaded and compiled Packard's stuff, and I think his is pretty messy, too.
I guess that would be OK, but I'm salivating over the Midiman Revolution 7.1. Seems to have 7.1 channels 24/192 audio out, 24/96 audio in, 107db signal to noise ratio. OSX drivers and sort-of alsa drivers. $119 list or $99 at newegg. And since Midiman has been good to open source efforts and Creative has been bad, I'd rather get the Midiman.
My work has been setting up a FCA for the past three weeks using Linux and there have been some major problems. They have a fat array with 32 15k rpm U320 drives hooked up to a IBM x440 via 4 HBAs. The interesting thing is that no distro they've tried can transfer faster than Windoze due to Linux kernel and driver issues. I was a little shoked. The x440 has 8 Xeons w/hyperthreading. The more cpus that are enabled, the more the performance degrades. The sysadmin says he thinks it has something to do with single-threaded io calls in all Linux kernels - the more cpus try to access io, the more threads that get blocked. Me and the other sysadmin - Gentoo 'heads' - start scratching our heads wondering what all the Linux 'Enterprise' stuff is that everyone is talking about. And yes, these components were all given the 'good to go' stamp by all their manufacturers. Since the prob is with the kernel itself, this is kinda major.
I went over to IBM's website and it sems to me that all the 6 PCI-X slots on these machines share the same bus, so it isn't going to matter if your kernel has multi-threaded I/O (is there such a thing?) or not.
I think that those 4 separate adapters controlling the drives are going to incurr 4 times the PCI overhead (grab the bus X4, send the data, release the bus X4) as a single adapter controlling all 32 drives would. And I think you would hit your I/O peak with one or two CPUs, assuming you are testing under no-load conditions.
I agree. The Emperor's New Clothes comes to mind when I ponder the price of the so-called Enterprise edition. I guess some people are comforted by the thought of a Red Hat applications specialist who can look up a client's problem/solution of Google better than the client can!
I don't think that Sun is 'selling out', they're just broadcasting how utterly clueless they are to the commoditization of their market. I guess they really believe their own spin about how their current downturn is the result of the lax economy and not because of the fact that fewer people are interested in paying US$59,000 for a 4-way server.
They don't understand that they can no longer charge $2,000 for an ethernet card just because they slap their name on a $200 card and write the driver for SunOS. Or charge $2,500 for an off-the-shelf SCSI disk drive. Or thousands for an off-the-shelf stick of RAM.
Their model of field sales and service reps, their own CPU design team, low-quantity manufacturing, is already archaic to the point of being moot.
The upcoming commodotization of 4-way, 64-bit (and possibly 8-way) servers running Linux with tons and tons of device drivers supporting off-the-shelf I/O cards, clustering software, commercial and free databases, great office apps (SUN!) will leave them gasping for air.
I had thought that maybe Sun was being secret about their future path, but their statement about Linux indicates that they are still believing in their old pictures.
I caught myself imagining what this Monday morning Slashdot topic is doing for morale at the Micros**t campus today, that is if they are allowed to access the web on company time.
NCD terminals + server Linux is spend the money and you're done.
I think that the practicality of Xterminals is lost with many Linux users and almost all of Windows users. When people understand the efficiency of X over tcp/ip, it is like a big light turns on in their head.
Windows Terminal Server-Citrix/Metaframe environment is relatively slow and the licenses are so expensive that it really hasn't taken off as well as it could. TCO for that environment exceeds that of standalone Windows PCs.
There once was a time when Xterminals were more expensive than standalone PCs too. And old-line commercial UNIX software was/is always more expensive than Windows apps on a per-seat basis.
It seems like the current generation of IT greybeards were the early risk-takers of the generation that replaced the mainframe with standalone PCs. Now they are the ones stuck in their old ways.
If you have talented sysadmins that actually know their job you can save massive amounts of cash using unix... even more if you didnt get fancy-smanchy NCD X terminals but used your old pc's as diskless terminals.... but we wanted the invisible PC+ sleek lcd on everyone's desk.
We white-boxed ours from a local clone maker. Micro-ATX Nforce boards, Durons, 128mb of memory. No CDROM, no hard disk, no floppy. Even in a real Micro ATX case, they are big, but they sure are fast! Many a time I've shocked an onlooker by telling them I was working on a terminal!
TCO studies are useless. It all breaks down to what is the right tool for the job.
I disagree. The most important point I think the author made in the study is the case for 1 (with redundancy) big iron server doing everything as opposed to several small servers each doing one thing. Sure, you'd have to read between the lines to get that, but the story does point out the case for big iron.
I especially liked his illustration of how PCs are akin to a millipede with 1000 autonomous legs. I can also see how serving with many small computers is more labor intensive than serving with big iron. But I don't think anyone would want to do his university setup with just one system admin.
I think Mr. Bill is cursed by his money. It seems his main motivator in life is that he is afraid of losing it. Imagine having all that cash and being afraid? Never enough. Buried in lawsuits. Feeling like you must kill your competition.
Basically, all calculations about the paralellism of instructions is done by the complier, not the processor. Theoritically really efficient if you can get it to work right.
I think that's where Intel is stuck with this CPU. Their compilers still aren't quite there with this problem. Intel is also throwing more and more level 2 cache at the problem, but this keeps the price of the Itanic very expensive and the thermal issues too cumbersome to consider moving it to the desktop.
The original premise was to bring the economies of mass production to the world of 64 bits. Maybe in the future they will hit a sweet spot with their compilers and the amount of level 2 cache, and then wait for a die shrink small enough for this to sell at a profit for $500. Someday.
Slashdot Mirror
When I read the article, I realized that it was Windows specific when I got to the part about the guy wanting to put his swap into a RAM-based disk. What's up with that? Wouldn't you simply buy more system RAM if swapping was becoming an issue?
Anyway, a few things I've done to get more performance out of my filesystem was I set kupdated's period to 'never'. The default is for kupdated to perform a sync every 5 seconds! I altered this behavior by changing the values in the kernel source, but it can be altered much more cleanly by setting the values in /proc. Turning off kupdated on a busy system with slow disks has improved performance quite a bit. Caveats are I'm running a server that NEVER freezes or has a kernel panic, and the system is on a battery backed UPS.
Another great performance increase was installing Squid and giving it its own 256mb RAM disk for web cache.
Any single user on an autonomous computer can get similar benefits by making a small RAM disk and making a soft link for their browser cache to it. Put a script in /etc/init.d to gzip the files on shutdown and unzip them on startup.
Bad news if the RIAA hired Mitnick to bullet-proof their website.
What happens with Sun depends on price commoditization of the 4-way and 8-way space with the forthcoming AMD Opterons. If that really happens, and Sun doesn't adapt, then that segment could go away for them.
If you buy premade computers, you get the brand name on the outside, and service and support and an easier way to figure out your IT budget.
If you can roll your own, your costs CAN be lower, in-house service and support CAN be better, faster and cheaper. For my money, computer science is a lot more fun and the results are a lot more reliable with in-house made computers running Linux from Scratch than it would be with Dell and Red Hat.
By the time their crappy server OS does get launched, they will be facing an entrenched group of free OSs that have 100% market share.
Why do you need onboard video to run a webserver? At any rate, you can get at least 2d Xwindows any of the all-in-one chipsets that run AMD products.
Thankfully, I seek out documentation OUTSIDE the XFree source. The archaic imake system, the need for 121 files in xc/config/cf! What's up with that? How is that supposed to be better than configure --prefix etc.etc?
I sure was lucky to find out about WORLDOPTS="", otherwise, if the compilation had hit a snag, I may have never known, because the XFree compile would happily chum along. Fine maybe for some systems. Maybe it is cool to grep an 11 megabyte &> log file. Maybe it is old school.
Keith's code is nice, is creative and works well, it is just the XFree86 World system he's fitting into. Fontconfig package 2.1 took me a long time to get right.
If I was King of XFree86, I'd first open it up to more people, then I'd tear out the utilities and put them separate, put the fonts separate, throw away the /xc/config monstrousity and replace that with configure --prefix= etc. etc.
Separate pswrap, mkshadow, xau, xnest, xext, all the gl's, xt, xv, xi, pex, speedo. The list is wildly bloated. Sure, maybe all that junk can be separate projects on the same Sourceforge page, but as it stands now, it is a whale.
I've also downloaded and compiled Packard's stuff, and I think his is pretty messy, too.
I think that those 4 separate adapters controlling the drives are going to incurr 4 times the PCI overhead (grab the bus X4, send the data, release the bus X4) as a single adapter controlling all 32 drives would. And I think you would hit your I/O peak with one or two CPUs, assuming you are testing under no-load conditions.
Right. And since this plan doesn't put any cash in any Congress Critter's campaign fund coffers, there's no motivation for Congress to make it law.
I agree. The Emperor's New Clothes comes to mind when I ponder the price of the so-called Enterprise edition. I guess some people are comforted by the thought of a Red Hat applications specialist who can look up a client's problem/solution of Google better than the client can!
They don't understand that they can no longer charge $2,000 for an ethernet card just because they slap their name on a $200 card and write the driver for SunOS. Or charge $2,500 for an off-the-shelf SCSI disk drive. Or thousands for an off-the-shelf stick of RAM.
Their model of field sales and service reps, their own CPU design team, low-quantity manufacturing, is already archaic to the point of being moot.
The upcoming commodotization of 4-way, 64-bit (and possibly 8-way) servers running Linux with tons and tons of device drivers supporting off-the-shelf I/O cards, clustering software, commercial and free databases, great office apps (SUN!) will leave them gasping for air.
I had thought that maybe Sun was being secret about their future path, but their statement about Linux indicates that they are still believing in their old pictures.
This revelation exposes a radical new change in IDG editorial policy. Up until now, they would have rewritten Microsoft's press releases!
The time will probably come when Micros**t relies on restraining orders to force people to buy their products! ;-)
I think that the practicality of Xterminals is lost with many Linux users and almost all of Windows users. When people understand the efficiency of X over tcp/ip, it is like a big light turns on in their head.
Windows Terminal Server-Citrix/Metaframe environment is relatively slow and the licenses are so expensive that it really hasn't taken off as well as it could. TCO for that environment exceeds that of standalone Windows PCs.
There once was a time when Xterminals were more expensive than standalone PCs too. And old-line commercial UNIX software was/is always more expensive than Windows apps on a per-seat basis.
It seems like the current generation of IT greybeards were the early risk-takers of the generation that replaced the mainframe with standalone PCs. Now they are the ones stuck in their old ways.
If you have talented sysadmins that actually know their job you can save massive amounts of cash using unix... even more if you didnt get fancy-smanchy NCD X terminals but used your old pc's as diskless terminals.... but we wanted the invisible PC+ sleek lcd on everyone's desk.
We white-boxed ours from a local clone maker. Micro-ATX Nforce boards, Durons, 128mb of memory. No CDROM, no hard disk, no floppy. Even in a real Micro ATX case, they are big, but they sure are fast! Many a time I've shocked an onlooker by telling them I was working on a terminal!
I disagree. The most important point I think the author made in the study is the case for 1 (with redundancy) big iron server doing everything as opposed to several small servers each doing one thing. Sure, you'd have to read between the lines to get that, but the story does point out the case for big iron.
I especially liked his illustration of how PCs are akin to a millipede with 1000 autonomous legs. I can also see how serving with many small computers is more labor intensive than serving with big iron. But I don't think anyone would want to do his university setup with just one system admin.
Those spec scores are telling because the whole thing fits in the Itanic's level 2 cache.
I say you should check out Dan Poynter the Ron Popeil of self-publishing.
I wonder how many people he trusts?
I think that's where Intel is stuck with this CPU. Their compilers still aren't quite there with this problem. Intel is also throwing more and more level 2 cache at the problem, but this keeps the price of the Itanic very expensive and the thermal issues too cumbersome to consider moving it to the desktop.
The original premise was to bring the economies of mass production to the world of 64 bits. Maybe in the future they will hit a sweet spot with their compilers and the amount of level 2 cache, and then wait for a die shrink small enough for this to sell at a profit for $500. Someday.