Rodney, Thanks for the reply. Please let me clarify it a little. So you're saying that switching packets through PA-GE involves 3.5 times more processing overhead compared to switching them through native port (btw, by native port you mean G1/G2 builtin one, right?), hence pps goes down from 470kpps to 127kpps. Is that right? I actually always thought that for the software-based platform max pps is a function of CPU. Do you think that these figures can be improved in G2 chassis? Thanks,
Michael On Thursday 02 July 2009 11:48:26 am you wrote: > I found what I was looking. The test was on older code but in concept it > still applies. > > Bi-directional going native gige port to another native gige port on the > G1 you are looking at around 470 kpps (double 940 kpps bi-directional) > at 64 byte packets with NO features. > > At 1500 byte packets it can pretty much fill up the gig in both directions > without dropping frames...again with no features. > > It appears from the tet you can just about fill up the links with 256 byte > packets for native gige to native gige. > > However, with the PA-GE it appears it's around 127 kpps in one direction > (double > to get bi-directional) at 64 byte packets. Which ends up being about 400 Mbps > total (200 M tx and 200 M rx) going from a native Gig port to the PA-GE. > > These are rough numbers from a lab test with absolutly nothing configured. > > And also this is from a test set where there are no micro-burst from the > real world traffic flows. We've seen that way too many times where some > L3 forwarding switch is connected and it overruns the GigE ability on the > connecting device. That's why the ASR1k is the suggested platform for that > space now as it can do linerate Gige. > > Hope this helps. As always with performance numbers YMMV depending on actual > code and configuration and design. > > Rodney > > > > On Thu, Jul 02, 2009 at 11:26:33AM -0400, Rodney Dunn wrote: > > Michael, > > > > I can't find the performance document I saw once before now. I'm still > > trying > > to find it. > > > > If you want real Gige you should go with the ASR1000. Even the G1 GE ports > > will have problems at high rates with any features enabled. > > > > Rodney > > > > On Thu, Jul 02, 2009 at 11:00:29AM -0400, Michael Ulitskiy wrote: > > > Could you please elaborate on the PA-GE issues? Or may be you could > > > provide some pointers to where they're described? > > > We're using quite a few of those with traffic rate anywhere from 50M to > > > 100M and I didn't notice > > > any issues so far, but traffic rate is increasing and I'd really like to > > > know what to expect in the future, > > > especially if there are any known caveats. > > > Thank you, > > > > > > Michael > > > > > > On Wednesday 01 July 2009 01:41:44 pm Rodney Dunn wrote: > > > > The PA-GE has issues at higher speeds. > > > > > > > > You should move to L2TPV3 and see if it's better in regards > > > > to performance. Your best would be pure L3 forwarding. > > > > > > > > If the PA-GE is the issue you will have to get off that PA. > > > > > > > > What happens if you move it to one of the onboard GigE ports on the > > > > NPE-400? > > > > > > > > Rodney > > > > > > > > On Wed, Jul 01, 2009 at 12:56:39PM -0400, Chris Hale wrote: > > > > > We have a set of 7206VXR's, NPE400 CPUs on each end of a point to > > > > > point OC3 > > > > > using PA-POS-OC3 cards. We bridge these circuits through a PA-GE > > > > > interface > > > > > (essentially turning the 7206's into a OC-3 to GigE converter) with a > > > > > single > > > > > bridge group. > > > > > > > > > > We are trying to push nearly 130-140Mbps, but per the MRTG graphs, we > > > > > seem > > > > > to be capping @ ~110Mbps. The CPU is also averaging 80-90%. We're > > > > > seeing a > > > > > large number of input errors (ignored, total of 5% of input packets) > > > > > and a > > > > > fair amount of output pauses (0.12% of output packets). > > > > > > > > > > GigabitEthernet1/0 is up, line protocol is up > > > > > Hardware is WISEMAN, address is 0016.46e6.1c1c (bia 0016.46e6.1c1c) > > > > > MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, > > > > > reliability 255/255, txload 36/255, rxload 16/255 > > > > > Encapsulation ARPA, loopback not set > > > > > Keepalive set (10 sec) > > > > > Full-duplex, 1000Mb/s, link type is autonegotiation, media type is > > > > > unknown > > > > > media type > > > > > output flow-control is XON, input flow-control is XON > > > > > ARP type: ARPA, ARP Timeout 04:00:00 > > > > > Last input 00:00:00, output 00:00:00, output hang never > > > > > Last clearing of "show interface" counters 12w0d > > > > > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: > > > > > 208 > > > > > Queueing strategy: fifo > > > > > Output queue: 0/40 (size/max) > > > > > 30 second input rate 66046000 bits/sec, 29231 packets/sec > > > > > 30 second output rate 141617000 bits/sec, 31690 packets/sec > > > > > 2816822087 packets input, 1367339773 bytes, 0 no buffer > > > > > Received 7138653 broadcasts, 0 runts, 0 giants, 0 throttles > > > > > 143326584 input errors, 0 CRC, 0 frame, 481945 overrun, 142844639 > > > > > ignored > > > > > 0 watchdog, 4536607 multicast, 0 pause input > > > > > 0 input packets with dribble condition detected > > > > > 3993978307 packets output, 979813878 bytes, 0 underruns > > > > > 0 output errors, 0 collisions, 0 interface resets > > > > > 0 babbles, 0 late collision, 0 deferred > > > > > 4 lost carrier, 0 no carrier, 4808187 pause output > > > > > 0 output buffer failures, 0 output buffers swapped out > > > > > > > > > > If we move this to a routed infrastructure with CEF, can we expect > > > > > the CPU > > > > > to drop considerably? The routing will be static only, very simple > > > > > config > > > > > with no ACLs, no policy maps, etc. We're just trying to get the > > > > > routers to > > > > > let us push as much of the OC3 bandwidth as possible. > > > > > > > > > > We would rather not upgrade the NPE400's if possible. The internal > > > > > LAN > > > > > equipment is Nortel L3 switches which don't seem to support > > > > > flow-control. > > > > > > > > > > Thanks in advance for any ideas. > > > > > > > > > > Chris > > > > > > > > > > -- > > > > > ------------------ > > > > > Chris Hale > > > > > [email protected] > > > > > _______________________________________________ > > > > > cisco-nsp mailing list [email protected] > > > > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > > > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > _______________________________________________ > > > > cisco-nsp mailing list [email protected] > > > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > > > > > > > > > _______________________________________________ > > > cisco-nsp mailing list [email protected] > > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
