Quantcast



Docs


Blogs


Forums


Samples


Media


Labs


Resources

 




DevCentral > Weblogs > Lori MacVittie - Two Different Socks
 Jack of all trades, master of none
posted on Tuesday, November 27, 2007 2:23 PM

Alan Shimel applauded a recent blog post by Eric Ogren regarding the "Advances by Intel and AMD in compute power with multi-processors and management with virtualization" claiming that these advances "have shifted the game for security vendors who are bringing their products to market as a high performance appliance."

Nevis Networks posted a rebuttal, and the comments responding to Eric's post were generally of the same bent: ASICs are not likely to be replaced by general purpose (commodity) processors, regardless of their capabilities.

While this current debate is focused on the security market and security-specific ASICs, this isn't a new argument at all. We heard similar arguments over core network processing ASICs in the early days of high-speed switches, and have continued to hear said arguments even today in the layer 4-7 switching arena. There are those who (mistakenly) believe that ASICs are unnecessary due to the increasing power of general purpose CPUs. 

This is simply not true. Those who buy into such statements are generally software-focused product vendors who want to believe it because it sounds good and justifies their decision to deploy on a standard computing platform with off-the-shelf hardware. But anyone who's studied operating system design and engineering understands that a general purpose CPU is just that - general purpose. It specializes in nothing because it has to support everything. It's a jack of all trades, and master of none. At its core, its circuitry is necessarily generalized whereas an ASIC is necessarily specialized. An ASIC is designed to perform a specific task, and to perform that task at the greatest possible speed.It is generally self contained, and non-interruptible. Once the order is given to "do its thing", it does it, and does it fast.

Eric claims that "It is becoming increasingly harder to justify large engineering investments in custom-built ASICs or hardware that is not built on a standard platform." I disagree. There is just too much overhead that comes with standard platforms - including the operating system - that degrades performance well below that of a custom built platform. There's a couple of good reasons we have custom hardware driving devices such as routers and switches and application delivery controllers - speed and capacity. The reasons custom built hardware platforms evolved in the first place are still valid - general purpose CPUs just aren't fast enough for some computing processes. A standard platform will always be limited not only by its use of general purpose CPUs, but by the general purpose operating system which stands between a product and that CPU.

There are certainly some tasks for which building an ASIC would be financially prohibitive and unjustifiable. Network and customized processing are tasks for which ASICs make a great deal of sense, financially and technically. One of the best examples of late involves XML processing, which requires the same deep packet inspection capabilities that Eric is claiming can be done efficiently in a general purpose CPU. That's simply not true, as evidenced by benchmarks and anecdotal evidence from implementations that rely heavily upon XML messaging.  XML processing on general purpose CPUs is terribly slow, and the only thing that's improved that performance has been ASICs and custom built hardware. Bulk encryption is another good example. Even today the general purpose CPU cannot match the performance of an SSL acceleration card (i.e. custom hardware). Any network device worth its salt uses one, to do otherwise is considered simply foolish. And dare we even try to pit a standard platform running a standard operating system with a standard network card against the purpose built hardware in a router or switch? There is no performance comparison necessary - general purpose loses to purpose built every time. That's why you've got a core router handling your traffic and not a Linux or Windows server performing the task.

ASICs are not going anywhere, nor are custom-built appliances. The architectures necessary to support wire-speed processing of application traffic are different than those needed for general purpose computing and require a custom-built system.

Imbibing: Water

Technorati tags: , , , ,



Email This
  del.icio.us
      

Feedback


11/27/2007 8:43 PM
Gravatar Lori- while I agree that some tasks will always require specialized hardware, the fact is most "specialized appliances" being sold in security today are no more than off the shelf hardware with a fancy bezel.

On top of this, even deep packet inspection is seeing increasing gains with new, multi-core technologies. Watch what we have in store over the next couple of months to see ;-)

It comes down to this, if you want to run around town in a Ferrari, that is fine. But does every trip to the supermarket need to be done in a Ferrari? Not with the price of gas today or for that matter the costs of customized silicon.
alan shimel

11/28/2007 6:41 AM
Gravatar Alan,

Back in my publishing days we used to try to distinguish between the type of "appliance" you point out and purpose-built hardware by calling software shipping on off-the-shelf-hardware "softpliances". I agree, there is very little difference between shipping software and shipping software installed on off-the-shelf-hardware with the exception of eliminating installation tasks from the deployment.

Deploying these "softpliances" is more about ease of installation and rarely has additional benefits aside from perhaps the ability of the vendor to harden the underlying operating system - a task many customers don't have time/desire/skill sets to perform.

As far as performance goes, there's no advantage to a "softpliance" versus software deployed on customer provided hardware. The gains come when you move to a true purpose-built hardware platform, which is a completely different ballgame and may not be applicable to all types of software.

Good point there, thanks!!
Lori
Lori MacVittie

11/29/2007 6:29 PM
Gravatar ASIC addiction is indeed hard to break, Lori. The rationalizations and twists of logic necessary to support the ASIC habit are amazing.

For much of the first half of this decade, NetScaler was *FASTER* than F5 - ask Tolly - and they did it on Intel processors running an efficient pared-down Linux kernel. (I was a Dir of PM there then!) So empirical evidence says software has been beating hardware for several years. Yes, F5 spent an amazing amount of rolled-up $100 bills for little baggies of ASICS from the shady guy on the corner, which let them sometimes be faster than NetScaler.

But then again, Intel is putting XML processing into their CPU. Do you really believe that modern CPUs only do general things? They have specific instruction sets to do common tasks, and XML is common, so it's getting built in. So is network processing!

Now is the time to join the new AA - ASICs Anonymous. At the next meeting you could be there, saying, "Hi. My name is F5. I'm addicted to ASICs and I'm afraid." Or not! :)
Dave Asprey

12/7/2007 11:52 PM
Gravatar The argument is more complicated. The same technology that make modern CPUs faster, namely smaller transistor size, can be used to make modern ASICs faster. Modern design technologies can be used to cram more functionality into a chip of the same size. So the question is really more akin to describing a race.

The neat feature about the BigIP is the hardware/software integration. For packets that don't need a lot of inspection, they can zip through the hardware. When a packet needs inspection, then software can step in an do its thing.

But we're all just hand waving. It would be cool for somebody to run an experiment comparing the performance of, say, a 6400 running the same load with a fastL4 profile against a standard profile.

And by the way, the BigIP uses a pared-down linux kernel.
Jeff Silverman
 Leave Feedback
Title  
Name  
Email
Url
Comments   
Please add 1 and 5 and type the answer here: