Date: Thu, 19 Sep 1996 13:43:48 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: dennis@etinc.com (Dennis) Cc: hackers@freebsd.org Subject: Re: Routers - hardware received wisdom Message-ID: <199609191843.NAA11352@brasil.moneng.mei.com> In-Reply-To: <199609191755.NAA13350@etinc.com> from "Dennis" at Sep 19, 96 01:55:43 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >A T1 is 1.544Mbps, at 8 bit bytes that is about 193,000 bytes/sec. > >That means the router needs to handle 1930 packets per second. When > >you consider that that means 1930 _in_ via one interface and _out_ via > >another, that means 3860 packets per second - assuming the remote > >site does not respond to your pings. > > Remember that T1 is full-duplex.....so you need to double the potential.... I think that last qualification essentially eliminated that, which was intentional for the purposes of this discussion. See later where I added that consideration back in. I simply wanted to draw the simpler case first - but certainly it needs doubling to account for the complete potential. > Id doesnt matter what they are connected at.....you cant receive at higher > then your > bandwidth....you cant kill me on my 56k line, you just CANT do it! Sorry, was not thinking you had a 56k line, but given a slow enough CPU on your side, I could probably kill you. If you had a T1 and anything less than a Pentium, on the other hand... I know I could. Obviously you can not handle more than your bandwidth - that should be elementary. However, if the water coming down your pipe is coming faster than the rate at which you are prepared to drink out of the hose, the excess water usually goes somewhere. > Please...T1 hardware is not the issue. The board can do 16Mbs single flag > separated. The issue is the ability of the host to get the packet off of the > board. I agree!!!!!!!!!!!!!!!!!!!!! And that can be a problem at _ANY_ data rate.... 300 baud, 56k, T1, 10mbps, 100mbps, 655mbps. What I am saying is that at some point, you can probably saturate the host CPU. UNLESS the host CPU is powerful enough to deal with the worst case scenario in the first place... Come on Dennis, you _know_ this as well as I do. > at 5us per character, you've got 200us to pull off a 40byte packet. Thats your > limit on the board. You've got a 32K buffer to protect against cpu > contention, which > is plenty. Bullshit. Pure bullshit. This rate is almost irrelevant to this discussion, as long as it is large enough to support saturation at the desired speed. I can't believe you do not understand this concept, but I will draw it out for you. Let us pretend for the sake of argument that it takes 1ms for the host CPU to route and dispose of a packet. This is known as "overhead". Now for large packets (lets say 1000 bytes), you have 5000us (5ms) to pull off the 1000 byte packet. You also have the 1000us (1ms) packet overhead. HOWEVER - I will grant that in the most ideal circumstances, the two can be overlapped thanks to DMA transfers, and therefore packet reception becomes max(5000us, 1000us) = 5000us. At that rate, I believe that I can receive 200 packets per second. I hope we can agree on that! Because it is derived purely from your 5us figure. Now, given a much smaller packet.. let's use your 40 byte packet. You have 200us to pull off the 40 byte packet. You also have the 1000us (1ms) packet processing overhead. Packet reception time is max(200us, 1000us) = 1000us. At that rate, I believe that I can receive 1000 packets per second. But... let's undo that math. We should be able to receive at 5us per byte, or 200,000cps. E1 speeds. That looks good. We can receive 1000 40 byte packets per second. 1000 packets per second * 40 bytes per packet = 40,000 bytes per second. Uh oh. So - Dennis - it is clear to me that if the CPU takes time to process a packet, that may become a very important consideration when trying to process short packets. What is clearly MOST important - assuming the hardware is fast enough, which I _agree_ it is - is that the CPU be fast enough so that this does not become a serious concern. If you try to drink water out of a fire hose, you will get a wet face and most of the water will not make it into your mouth. > Now ethernet is more difficult. The PCI cards are bus masters, so the only > hardware > reason to drop packets is that you cant get the bus....considering there is > no memory > on the card, you have to transfer at full bandwidth 100% of the time. No, you are still failing to consider that there is overhead in the software. Hardware overhead is generally less of a consideration. > I'm not sure that you are correctly diagnosing the reason that packets are > getting dropped, > and its certainly not easy to do so. Dennis, I have seen the _cursor_ on Trantor blinking irregularly and even _stop_ because the levels of traffic I was pushing through that venerable 386DX/40 were far beyond reasonable. The CPU stops having idle time - or even sufficient time to process the currently pending interrupts.. it is a truly awe inspiring sight to see a console cursor stop blinking entirely. > Although it is true that most '486 ISA/PCI bridge chipsets are very > inefficient....there could > be a limitation there as well. > > The bottom line is that, normally, a '486 is fine for a T1 or even 2. Cisco > 2501s are less intelligent > and have a 30mhz 68030.....and lots of people use them. YES!!! Absolutely! "Normally" a '486 would probably be great for even three or four T1's. As LONG as you realize that a '486 CAN get swamped by lots of small traffic data... and take that into account. Many people won't care. However, those of us who insist on knowing what the risks are, we want to be aware of this. I certainly agree that the CPU on a 486DX5/133 will pound the hell out of a 2501 and still have cycles to spare. I am NOT saying the 2501 doesn't exhibit this problem... it's probably WORSE on a 2501. ... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609191843.NAA11352>