Re: Packets Per Second Limit?

Previous thread: project mgmt software by Jacob Yocom-Piatt on Thursday, May 31, 2007 - 8:34 am. (3 messages)

Next thread: basic pf question without NAT or rdr by Boudewijn Ector on Thursday, May 31, 2007 - 3:45 pm. (2 messages)
From: askthelist
Date: Thursday, May 31, 2007 - 12:18 pm

Anyone know the maximum packets per second that can traverse a 100MB
internet link. From what I've been able to gather its about 8300 or so? Is
this number accurate? Do connections just start to timeout once I hit this
limit? I'm a little worried about this because we are fast approaching this
mark and am afraid were gonna hit it before we max out are available
bandwidth? Anyone ever run into this situation or am I just paranoid?

From: Karsten McMinn
Date: Thursday, May 31, 2007 - 12:34 pm

well, 8300 x 1500 x 8 = 99.6mbit. congratulations. And yes,
when you saturate a interface with more packets than it
can transmit you will.....be out of bandwidth. btw, If you were
looking for google its at google.com.

From: Darren Spruell
Date: Thursday, May 31, 2007 - 12:37 pm

Packets per second are a capability limitation of the equipment
interfaces responsible for passing the traffic and don't directly
relate to the link speed. It's also highly dependent on the size of
the packets being passed by  the interface. It's dependent on many
several factors, actually.

You hit a pps limit and you'll see packets drop; the interface simply
can't keep up with the throughput.

DS

From: nachocheeze
Date: Thursday, May 31, 2007 - 12:43 pm

Depends on the byte size of the packet.  If most of your throughput is
standard 1500 byte packets, you should have little to no problem.

If someone starts blasting out 64 byte packets at wire speed though,
your link will be toast long before traffic ever reaches 100Mbps.


From: askthelist
Date: Thursday, May 31, 2007 - 3:43 pm

This is exactly what Im worried about but Im not sure if I should be or not.
Because of some of the applications we host, a ton of small packets are
being generated. Heres a breakdown by packetsize.

<= 64 bytes     48.1%
64 to 128 bytes     21.1%
129 to 256 bytes     1.6%
257 to 512 bytes     7.8%
513 to 1024 bytes     5.6%
1025 to 1518 bytes     15.8%

and here is what are pps and bandwidth look like.

queue root_em0 bandwidth 100Mb priority 0 cbq( wrr root ) {ext_root_queue}
  [ pkts:  767614230  bytes: 467721711758  dropped pkts:      0 bytes:
0 ]
  [ qlength:   0/ 50  borrows:      0  suspends:      0 ]
  [ measured:  6448.5 packets/s, 31.21Mb/s ]

Were nearing the 8300pps mark so I was worried? But should I be? Becuase the
majority of my packets are smaller then 64B, shouldn't I be able to pass a
lot more packets then 8300pps? If all my packets were 64K or smaller,
shouldn't that allow me to be able to handle closer to 200k packets/sec
before hitting my bandwidth limit?

by the way. I know where google is. I've been there and have even read some
of the links that are posted in this very thread. However I am confused and
there even seems to be some confusion/discrepancies within this thread... so
I thought I would bounce the question off of people who might have a better
grip on this than I, and already been through similar situations for
feedback, something google cant offer(yet). I am not going to apologize for
my ignorance but thank the people who are actually trying to help me
understand this, without being a smartass about it.




From: Ryan McBride
Date: Thursday, May 31, 2007 - 4:14 pm

You're fine.  The 8300pps mark is not an upper limit, it's the best case

Yes, depending on limitations of your firewall hardware, pf ruleset,

For this you will need a reasonably fast box with good gigabit ethernet
cards (em or sk), and an intelligently written ruleset. It seems like
you're a long way away from 200k pps, though.

From: askthelist
Date: Thursday, May 31, 2007 - 5:00 pm

ok i feel better now and i think i got a better handle on this then before.
its a fast box with plenty of memory, intel pro gig eth cards (em), about
350k in the state table at the moment, with fairly small ruleset,
intelligenty would probably be up for debate! I would like to think so.
Thanks.


From: Stuart Henderson
Date: Thursday, May 31, 2007 - 4:30 pm

that is not a high enough rate of packets to worry about unless it's
running on very weak hardware or there's some other problem.

if this becomes a problem you'll see things like high cpu% in interrupt

you'll probably hit bandwidth limits before you run into problems

welcome to misc@

From: Darren Spruell
Date: Thursday, May 31, 2007 - 4:41 pm

On 5/31/07, askthelist@gmail.com <askthelist@gmail.com> wrote:

First rule of Fight Club: dont' talk about Fight Club.
Second rule of Fight Club: don't take public mailing lists so
seriously. People will be smartasses. You will get ridiculed for
questions you ask, good or bad. Oftentimes you'll actually deserve it.
Thicken the skin and wear flame-retardant apparel. Smell the roses.
Enjoy the experience; it's not going to change any time soon.

DS

From: Jeffrey C. Ollie
Date: Thursday, May 31, 2007 - 1:22 pm

This[1] caculation is for 10Mb ethernet, but multiply that by 10 and you
get 148800 packets per second.

[1] http://www.erg.abdn.ac.uk/users/gorry/course/lan-pages/enet-calc.html

Jeff

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

From: Stuart Henderson
Date: Thursday, May 31, 2007 - 1:28 pm

100Mb -> somewhere between that and about 220,000. depends on packet size.

you're probably more interested in how many pps the devices *either side
of that link* can handle, though. you'll have to find this out for yourself.

if I run a packet generator on box 1 (amd64 MP/sk) sending small UDP packets
towards box 2 (i386 MP/bge) with just a switch between them (all gigabit),
I see this rate of bytes/sec and pps: (this is all pre-hackathon kernels)

Iface    State     Ibytes    Ipkts  Ierrs       Obytes    Opkts  Oerrs    Colls
sk0      up:U        7000      100      0     18364134   322176      0        0

-> in Mbit/s:

<sthen@zephyr:12103>$ echo $((18364134*8/1024))
143469

and all is reasonably ok, things are not too bad on either system.

depends on all sorts of things. NIC type, packet sizes, what kernel
you're using (i386/amd64/UP/MP), PF on or off, how applications handle
that kind of traffic if they're involved rather than just routing or
bridging ... but 8k pps is not really very much for a system to handle.

with the above example: if I reverse things and send from box 2 to
box 1, box 1 grinds to a standstill, it doesn't respond to anything
typed at the console until the packet flow ceases since all time is
processing interrupts. and that's at just 150kpps or so which is all

generate some load, do some testing, and see what happens.
you are probably worrying too much at 8kpps if the pipe is not
nearly near full.

Previous thread: project mgmt software by Jacob Yocom-Piatt on Thursday, May 31, 2007 - 8:34 am. (3 messages)

Next thread: basic pf question without NAT or rdr by Boudewijn Ector on Thursday, May 31, 2007 - 3:45 pm. (2 messages)