Man, you must have a death wish with a flame like that!! Regards...
>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]
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
