Boy, you guys have been reading a LOT of cisco propaganda, aren't you?

Ciscos are just a PCI bus, and they are generally deficient in cpu power.
The higher end ciscos (7500 and up) have 2 busses, but at 15 times the cost
of a PC its hardly worth if for twice the bus bandwidth. A PC is like a
7200 series with the cpu power of a 7500 (at least).

Even though ciscos can "switch" they still are routing unless you are on
the same card. Any kind of LAN/WAN routing has the same issues on a cisco
box as on a PC.

Performance-wise, ciscos have virtually no advantage below 12000 series.
They do have a big lead in software maturity however.

Dennis

http://www.etinc.com
ISA and PCI T1/T3/V35/HSSI Cards for FreeBSD and LINUX
Multiport T1 and HSSI/T3 UNIX-based Routers
Bandwidth Manager 

At 10:43 AM 8/19/99 -0400, you wrote:
>Thus spake Alan Cox
>>> - memory copies.  As I understand it, to switch a packet through a Linux
>>> router, there are at least 2 memory copies....the packet is received and
>>> stored in the nic buffer...from there it's copied into main memory...I'm
>>> assuming the Linux kernel is very efficient and doesn't do any copies of
>>> its own...from there its copied into the outgoing nic's packet buffer.
>
>>Most NIC's have only FIFO's . Main memory is their ram buffer. One card
DMA's
>>it in, the other DMA's it back out when using the fastroute aware tulip
>>driver.
>
>OK...even at that though...you're dealing with two DMA's across a PCI
>bus compared to what's essentially a single DMA across a much higher bus
>speed in most Cisco's.
>
>>> Cisco hardware...being designed with IOS in mind, allows IOS to do zero
>>> memory copies....the packet is read from the incoming nic's packet
>>> buffer directly out the outgoing nic.
>
>>Benchmarks for the low end ciscos say either they dont or it doesnt matter
>>cos we kick them on IP 8)
>
>I can believe that with a 25xx or so...those things only have 68ec030
>processors...hardly beefy at all...they're also a very old design (10
>years?) at this point.  I suspect the 26xx's (basically the newer
>replacement for the 25xx's) will give Linux a really good run for its
>money there.  Not that this is terribly significant.
>
>To be really fair though...when you're dealing with packet speeds that
>these types of boxes are dealing with (a 25xx can do 2 E1's and a
>regular ethernet at wire speed), it doesn't take much to do wire speed,
>and latency just isn't that significant.
>
>>> - extensive switching support.  To my understanding, you can't have a
>>> linux box with 4 ethernet cards and bridge between eth0 and eth1, and
>>> then bridge between eth2, and eth3, and then route between the eth0/1
>>> combo and the eth2/3 combo.  IOS handles that with no problem.  Other
>
>>Correct. We don't support fancy switching. Linux is a router it doesnt
really
>>have any pretense at switching. Measure the latency on a really good cut
>>through switch (like the big 3com ones) and you'll see why. For pure
switching
>>the fancy dedicated hardware stuff beats us flat on latency and I guess
always
>>will.
>
>Sure...hardware switches are gonna kick butt in switching...that's not
>really what I was talking about....you can take a Cisco router, and tell
>it to switch in all these ways...and some of these "switching" services
>are labeled so because they deal with things at the link layer, but are
>really only useful for routers, particularly in that group, VRRP.
>
>To try to pull this back on topic some.  :)  I'd really like to see some
>more switching services added to Linux.  VRRP would be one that would be
>really useful for folks to routing on Linux.  I'd also like to see the
>bridging support extended to be more flexible.  I have a really bizarre
>thought that would be really cool to be able to use IMHO.  :)
>
>For a server system (you can do largely the same with a router system,
>but my use for this would be for a server system), put two nics in

>it...connect each nic to seperate network switches.  Let the nics run
>briding code so they participate in spanning tree.  Also "bridge" the
>traffic to a loopback or "virtual" interface or so (maybe you can
>already do this?  haven't gotten a good answer, don't think so though),
>so you can tell daemons and such to bind to the loopback or virtual
>interfaces and the system can transparently recover from a dead nic card
>or cable, or switch.
>
>I've mentioned this to several people and quite a few of them just
>didn't understand what I was getting at...several others thought I was
>just weird (which is quite possible, even quite likely I'd say), and a
>few thought it was a neat idea.
>
>Anyway...that's out there as a random idea for enhancement.  :)
>-- 
>Jeff McAdams                            Email: [EMAIL PROTECTED]
>Head Network Administrator              Voice: (502) 966-3848
>IgLou Internet Services                        (800) 436-4456
>-
>To unsubscribe from this list: send the line "unsubscribe linux-net" in
>the body of a message to [EMAIL PROTECTED]
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]

Reply via email to