>PIX is wire-speed, hardware based! Checkpoint is based on the box you have
>it installed, which could be better than PIX's box... agreed!, but it is
>also software based.
>
>CheckPoint does have an embedded hardware based box made by NOKIA, but that
>market is not doing so well.
>
>Khalid Khan
"Wire speed" and "hardware based" come up often in many discussions,
but need to be taken with MANY grains of salt. By and large, they are
marketing hype.
*************************************
On Wire Speed (but what about fiber?)
*************************************
Start by considering that the packet rate _must_ be less than the
"wire" transmission rate on "wires" using encoding such as 4B/5B or
8B/10B.
There's been a recent discussion thread on the IETF Benchmarking
Methodology Working Group mailing list about whether "wire speed" is
a terribly useful or meaningful term. The consensus is that it is
not. A couple of expert comments:
>At 8:27 PM -0500 1/19/2001, Scott Bradner wrote:
>
>
>> RFC 2544 and its' parent 1944 don't use the term wire-speed.
>
>and I think that was an omission
>too many people are using the term "wire speed" in their own ways
>
>Internet average packet size, Internet packet size mix, and minimum
>sized packets are all definitions I've seen - to me its only the last
>one that makes sense
At 7:41 AM -0500 1/22/2001, Jim McQuaid wrote:
>I agree with Scott. The only meaningful definition is handling the maximum
>possible frame rate, i.e. the minimum size packets. This is the "implied"
>definition of wire speed, even if the reality is quite different.
>
>Every so often there has been discussion of "average" traffic or "typical"
>traffic. It is possible to imagine coming up with some defined 'bag of
>frames' that represents "typical traffic" but in reality the consensus is
>never there. There is no such thing as ""typical" traffic for testing
>purposes. The well-defined (if artificial) traffic loads of 2544 and others
>are the workable, implementable and consensus ways to do this, it seems.
>
At 8:47 AM -0800 1/22/2001, David Newman wrote:
> > I would say the wire rate is 10Gbps because the physical interface
>> is able to forward 10Gbps.
>
>No
>
>Some physical media ALWAYS operate at X bits per second, regardless of
>whether they carry packets. A measurement that says "this interface operates
>at X bit/s" isn't terribly meaningful if the forwarding rate is 0 pps.
>
At 3:07 PM -0800 1/25/2001, Ramesh Menon wrote:
>>I posed this question originally but had to drop out of
>>the thread for a bit. Jambi, thanks for guiding it back
>>to the original question.
>>
>>Jim, you asserted in an earlier mail:
>>"Let's focus on the goal. If it is to benchmark for router
>>performance, we have what we need."
>>
>>Routers are not the only interesting devices our there that
>>need benchmarking. The great thing about 2544 is that it can
>>used for benchmarking NICs, analyzers etc. The design (and
>>price point) for a lot of these are different from routers.
>>Some of these have no concept of forwarding and as such are
>>are optimized for other metrics, including price/performance.
>>While it may do less than 100% at 64 byte frames it can keep
>>up with every situation out there bar synthetic traffic.
>>
>>The reality on the ground is that it is not easy for engineers
>>in companies with marketing departments to go out and say that their
>>card (not *router*) can keep up with only 75% at the smallest frame size.
>>This is even if none of their customers would care.
>>
>>Quoting Jim again "... "implied" definition of wire speed, even if the
>>reality is quite different". I have spent quite a bit of time on standards
>>bodies before and I would argue that if we don't take *reality* into
>>account,
>>we are quickly going to be written off to oblivion. DUT vendors that can do
>>100% will report at every frame size, those that cant must have the option
>>to
>>report for a mix. I would urge this group to adopt a more pragmatic and
>>practical approach to this issue.
***********************
On Being Hardware Based
***********************
Ummm...I hate to say it, but there is very little practical software
that isn't hardware based. People also rarely make the distinction
of whether something is running a real-time operating system (IOS,
VXworks, etc.) versus a general purpose operating system (e.g.,
MacOS, UNIX, NT). For that matter, what if the OS is kernelized? Is
MACH hardware based? What if the routing processes run over pthreads
in a multiprocessing environment (i.e., all the processors are
general purpose RISC or CISC, not ASIC).
Which of the following is software based? Hardware based? Which is fast? Slow?
1. An ASIC for route lookup which has been loaded with a lookup table
computed on a 68000 processor?
2. The RISC processor in a VIP, using a FIB created in a RISC RSP8?
3. Optimum switching in an RSP, given the lookup uses a CAM with content
set up by a RISC?
4. CEF on a 7200 with a NPE-300?
5. Silicon switching on a 7000 with a 68040 CPU?
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
