From: John Hall (j.hallIZZATf5.com)
Date: Thu Jan 22 2004 - 20:36:58 EST
It *is* happy so far! And a happy new year to you as well! :)
I find it interesting that you say you are not sending connections
'through' an OS, yet you state that the packet engine operates in
"kernel mode". All of the OS's I am aware of also have a kernel and
connections being handled by that kernel are generally considered to be
handled by the OS. I was trying to distinguish between what the switch
folks usually call "slow path" (requiring processing by a host processor)
and "fast path" (usually completely handled by ASIC's). In todays world
of 3GHz CPU chips, the difference is becoming less and less, but it still
is significant.
I hate tit-for-tat, but the stacks used in BIG-IP are highly refined by
us and bear little resemblance to a "generic OS TCP/IP stack" and also
do not involve any context switching. I honestly suspect that the same
would be said by most load balancing vendors.
Cheers,
JMH
Shawn Nunley wrote:
>John,
>
>Just to be clear, the NetScaler device does not ever send connections
>'through' ANY OS, ever. The performance effects of doing this would be
>catastrophic and would not allow us to support the speeds and feeds we
>advertise. Everything is handled within our packet engine which
>communicates directly with RAM, NICs and the CPU, all in kernel mode with no
>context switching to slow things down.
>
>The difference is worth pointing out since we spent years developing that
>technology in order *not* to be lumped in with devices that are limited by
>generic OS TCP/IP stacks. Nothing personal, but I couldn't let that
>generalization just slip by.
>
>BTW, I hope you're having a great New Year.
>
>-Shawn
>
>-----Original Message-----
>From: John Hall [mailto:j.hallIZZATf5.com]
>Sent: Wednesday, January 21, 2004 12:44 PM
>To: lb-lIZZATvegan.net
>Subject: Re: [load balancing] Load Balancer Evaluation: Which would you
>pick?
>
>
>It would be interesting to find out what engineer said this, but it is
>essentially incorrect. Recent BIG-IP's that have our Packet Velocity
>ASIC (you gotta love marketing folks) have a range of load balancing
>options including full hardware acceleration (the entire connection is
>handled by the ASIC with no host processor support required) through
>partial acceleration (the connection is initially handled by software,
>but as soon as a load balancing decision is made, it's handed off to the
>ASIC for the rest of the connection), to full software load balancing
>which provides all the possible load balancing capabilities.
>
>In regards to the original question. I strongly suggest that you ask
>the top several vendors on your list specifc questions about your
>planned (and future) load profile. All of the boxes you are looking at
>have a host processor running some OS (vxWorks, BSD, BSDI, etc) and all
>of them send some types of connections to the host processor for
>handling. The loads you are planning are significantly above the
>capabilities of some of the boxes you list to handle in software, but
>are probably quite easily handled in a partially or fully hardware
>accelerated modes. Specific characterization of your load profile and
>some direct questions to the vendors should help you narrow down your
>choices.
>
>An illustrative anecdote involves the effect of the Nachi worm on
>several vendors of six-figure cost layer 2/3 switches. Many of the
>vendors sent ICMP packets to the switches host processor for handling
>and their host processors are often amazingly low powered, so a single
>Nachi infected PC sending ICMP packets to thousands of random
>destinations could bring these very expensive and capable switches to
>their knees. Some switches handled ICMP in hardware, but updated their
>ARP tables using the host processor and they were incapacitated by ARP
>updates. So, while these switches quite ably handled the "normal" layer
>2/3 load, they were crippled by an unusual (but perfectly "legal", at
>least according to the RFC's) load profile that their designers did not
>anticipate.
>
>JMH
>
>Mike W wrote:
>
>
>
>>Radware is a switch based solution, while F5 is still a unix kernel
>>based product, which some say takes them out of the "switch market" -
>>their marketing discusses their network processor, but one of there
>>engineers at a trade show last year finally admitted when pressed,
>>that they didn't use it when doing actual load balancing, only if they
>>were a router.
>>
>>
>
>
>
-- John Hall Test Manager - Switch Team F5 Networks, Inc.____________________ The Load Balancing Mailing List Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l Archive: http://vegan.net/lb/archive LBDigest: http://lbdigest.com MRTG with SLB: http://vegan.net/MRTG Hosted by: http://www.tokkisystems.com
This archive was generated by hypermail 2.1.4 : Thu Jan 22 2004 - 20:53:45 EST