Slashdot Mirror
Hardware Headaches Inevitable?
JaneWalker6847 writes "Don Becker, co-founder of the Beowulf project, describes the inevitability of hardware administration headaches and warns users not to expect a silver bullet to solve these problems." From the article: "We're about to see another revolution, which is in network adapters -- that we [will] talk directly to [them] from application level. That's a massive change in how you interface with them. And that brings about a new round of device drivers completely unlike the device drivers we had 10 years ago. So, that part of the world isn't going to stabilize anytime soon."
What they're likely talking about is technology like Chimney, which, barring lawsuits, will be coming out in or around the time of Windows Vista. Effectively, instead of the TCP/IP stack coming from the OS and running on the main processor, the network card will have a processor and memory and run the TCP/IP stack there. This increases efficiency and reduces reduces latency because the main CPU doesn't have to get involved as much. In the future we will probably see things like SSL encryption being performed on the card as well.
It seems that these old cards are on sale on the eBay and [when I look those other search results] also some are sold as new, so I guess that this is still viable technology in some places: http://www.google.com/search?q=ssl+encryption+acc
Anyway, I just have this feeling that it's not a good idea to integrate any kind of encryption technology directly to the card.
Hmm... Do I smell WinModem?
What happens now (on windows) is that applications talk to winsock. Winsock sends the data to kernel mode code including tcpip.sys. From there, it ends up in ndis.sys and then the driver for your network card before being sent to the card.
What this new thing means is that applications send the data to winsock which hands it directly to a new kind of network card/driver which takes the data and header info and creates the TCP/UDP and IP packets on the card itself in card firmware. From there, the card wraps it up in the lower level protocols and then puts it out over the wire (or air if its wireless)
I don't believe that most places that would benefit from an 'advancement' like this would tolerate a moving standard. If a company revises a card because the standard changes, it sure as hell had better support whatever the previous standard is because some company running 10,000 of these cards in some massive distributed application won't accept anything but plug and go.
The idea that your original hardware vendor can provide you with a drop in replacement for a failed card is nice, but any decent manager is going to ask you what the plan is for when that vendor goes under. You need to know that you can just buy some card off the shelf and put it in and have it work. At least with our current driver/hardware structure, you know that a 3com nic is going to work. Or if 3com goes under, you can drop an intel nic in. You may have to install the driver for the card, but it's not going to (unless you start messing with dirty cheap hardware) have compatability issues.
I guess my point here is, there's no way a bunch of companies would target big business with a product like this without there being SOME standard interface. Who wants a multimillion dollar migration to 100% proprietary hardware?
Humans are slow, innaccurate, and brilliant; computers are fast, acurrate, and dumb; together they are unbeatable
Individuals? Not many, at least not on a regular basis.
In a data center environment? Quite often.
Hmm... Do I smell WinModem?
I'm not sure what that smell is, but its familiar.
Yes, TCP/IP offloaders, crypto offloaders, physics offloaders, FFT offloaders, have all existed. The only accepted offloader that has succeeded is the GPU, and that is because it was subsidized by the high end graphics people and people with game addictions. The cost/benefit of the other offloaders has not proven itself. Especially when you consider the rate of increase of the CPU speeds and the bottleneck of getting the data to the offloaded chip and back again. The Linux kernel mailinglist has been pretty much anti TCP/IP offloading because the time spent optimizing the drivers and the performance increase was often surpassed in a few months with a faster general purpose CPU and a generic driver that worked with all cards. This is also confounded when you have OS level TCP/IP stuff like ipchains or iptables that need their code in the OS and not on the card. FFT and physics offloaders have not taken off because of the cost/benefit loss when one takes into account the speed loss of getting the data onto the card and then the cost of the cache RAM to put on the card (if its ever enough), and then the time to get the data off of the card.
Now, what will make these things work?
A bus that is near or at the speed of memory bandwidth or a problem where the data does not need to go back to the host system. A GPU falls into the second half there. The display needs to know what its told, the computer does not need to know the details. TCP/IP offloaders have failed to catch on because of the price/performance benefit and their lack of ubiquity and commonality. Crypto offloaders are cool. Especially for the geek factor of having the keys stored on the card and zeroed out when tampered with. But again, the cost of writing specific drivers vs known CPU drivers for doing crypto and the rate of increase of cheap commodity CPUs over time often exceeds the cost/benefit of the crypto card.
Now, give me a fast bus and the ability to use my generic system RAM with one of these offloading cards, and things could change, but until then I expect this battle between the CPU and specific PUs to continue with no real winner.
The problem is that general-purpose cpus grow in power so quickly that the offload-engines get ever-larger problems beating them. And they get the aditional problem that they don't get packet-filtering or anything else that is not custom-written for that particular card (if it's even possible to convince the card to do it!)
It's also nothing new -- these cards have existed for literally decades, and haven't managed to make any kind of inroads, not even in specialized servers.
Have a look at this year-old Lwn-article for an example listing some disadvantages.
What really worries me are the metaphors mixed in the same sentence in the summary. So we should expect headaches, but not a silver bullet to solve them? I'm just having a mild headache at the moment, and just the thought of curing it with a bullet seems... somehow not that tempting ;)
A polar bear is a cartesian bear after a coordinate transform.
Hmm... Do I smell WinModem?
Except that WinModems are the exact OPPOSITE of the philosophy that's being espoused here with crypto offload engines, intelligent network cards, etc.
The WinModem was an attempt to take traditional modem functions and move them onto the CPU, in software. Rather than actually having a box full of circuitry that did the hardware handshaking, data compression, and all that good stuff, you just replace it with a simple device that barely connects the analog telephone line to the computer, and have the computer do all the heavy lifting.
I think the justification behind this approach is "software is cheap, hardware is expensive." Therefore, you put the 'brains' in software, and your dumb-hardware/smart-software combo is cheaper than the traditional combination of dumb-software/smart-hardware.
It's a pretty radical departure to essentially go in the opposite direction, from WinModems to these kind of "intelligent network cards," which seem more like a traditional serial modem in philosophy; they do all the work themselves and basically present the computer with a standardized data stream.
The only way that I could see this whole business being "WinModem-like" is in it being tremendously difficult to program for on non-Microsoft OSes. But that's not a consequence of the design per se, but of how I suspect MS will choose to implement it.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
It looks to me like he's telling us that drivers are not likely to go away as an issue any time soon. Too bad, but if Becker says so, he's very likely right.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
This comment makes me think again about AMD's acquisition of ATI. Would AMD put an ATI graphics core in the CPU package? (HTT allows for all the bandwidth the GPU could handle - no separate cache needed). Need a faster GPU? By the time you do - there'll be a faster CPU with a new GPU included, and this packaging might be less expensive than the current high end cards.
This combination would also work fine for 90% of the world's computer users, and possibly be much cheaper. Think Sempron with RAM and a miniscule motherboard with ports. The $100 laptop might drop in price.
The cesspool just got a check and balance.