How to work out needed Packet capacity (bandwidth)

I have a 8 Mbit/s PPPoE connection over cable (1492 mtu). It is allowed 1000 packets per second before my ISP drops data that should be fowarded onto my IP.

I'm monitoring how many PPS I've got coming in; 10 min average = 200pps. Spikes (95th percentile) = 400pps.

Ok, so now I will get into my question,..

Later on today the incoming data will increase by quite a lot... I don't exactly know by how much as the ISP will have already dropped packets... but I guestimate that I'll need a connection that can handle eight times the flow of packets per current period.

My question is; would it be correct to calculate my required bandwidth like this:

where: 400 pps * 8 = 3,200 pps (current flow * guessed multiplier = est. bandwidth requirement)
and: 3200 / 1000 = 3.2 (est. bandwidth requirement / current max bandwidth)
so: 8 Mbit/s * 3.2 = 25.6 Mbit/s ?

So I need to upgrade from 8meg to at least 25.6meg, in order to fully handle the 95th percentile of the anticipated packet flow, without drops ?

I'm not asking if my maths is correct, and although it might not be in some way relating to bits and bytes, it's more a question of scaling up Layer-2 networks... you see?

Oh; to avoid confusion; I'm getting the same size packets now as will be getting later only at 8 times the flow rate.

Errm... Let the warm banter start now ?

Surely you just to ask the provider for a connection that will allow 8000 packets per second?

You are basing the 25 Mbps on the assumption that every packet is of MTU size.

I don't know what the packet size is as they're layer-2 packets so difficult to size up without sniffing the wire.

What I do know is, that I'll be getting more of the same later, but in greater qauntity.... So can I scale up in multiples? or is there more to it than that ?

Actually I don't know if it will be 8K packets per sec. as cannot know for sure how many are getting dropped on my 8 meg line, that's what I'm trying to somehow guess.. hence the post

...Difficult to ask the ISP as I'm a Brit in Thailand and they get annoyed/perplexed with difficult questions like this!

edit: I can't control the sending flow rate - yet I need to receive all without loss, if possible.

Edited by deleted (Mon 25-Mar-13 11:07:50)

Without more information from the upstream provider, your best course of action would be to just double your capacity and see what actually happens.

what are these packets ?

Are you sure they have a packet per second limit and not a bandwidth limit (aka IP profile) ?

8000 packets/s at say 1450 bytes is 11.6 MBytes/s or about 90 Mbits/s

8000 packets/s at 64 bytes is 4Mbits/s

AFAIK; all ISPs impose packet limits - if they didn't then their edge routers would totally grind to a halt.

A router can transmit the most information if the message size is large. As the message size decreases in size, the headers and checksums *still* need to be processed, but the payload is much less. Hence the effective bandwidth decreases with smaller packets.

I have a graph of my incoming data which I'll try to post somehow.

The data is a .NET cloud API similar to FiX protocol.

(edit)

Graph here > http://www.hostpic.org/view.php?filename=13032519200... <

Can we work out the median packet size from this information ?

Edited by deleted (Mon 25-Mar-13 13:50:56)

Packet limits may exist in terms of what an edge router can handle, but any ISP that is imposing a sub limit on individual customers is probably running so close to breaking their kit that you should not be a customer.

Imposing a packet limit is so rare, this is the first post I've ever seen where a customer is worrying about it. It is much more normal to deal in Mega bits per second and only worry if a customer has a very odd type of traffic normally.

In reply to a post by yarwell:

Are you sure they have a packet per second limit and not a bandwidth limit (aka IP profile) ?

Good point.

What I do know is that I can download HTTP at 8meg at all times.

Conversly; When the messaging rate picks-up on from the remote .NET API, my speed graph will constantly spike between 3 - 6 meg and I start to get a degraded capture of incoming data. I started thinking the problem was somewhere else on the internet as I have no problem DLing 8 meg normally. But after using these online "capacity testing" tools - I find they will never go above 8mbit/s /1000pps without massive loss. I don't know the size of packet they are sending... I presume 400 bytes as this is the "internet average". However; if they are infact sending 1400 bytes, then I could have based my calculations detailed in the first post on false data and potentially have a massive bandwidth requirement ahead (IF ISP impose rate limit).

Edited by deleted (Mon 25-Mar-13 13:33:29)

Sorry, The graph I posted specified KB/s... I have updated the link with a changed graph with Kb/s as the text label.

Edit; I worked out the median packet size and how many packets "I should" be able to recieve on my connection.... I welcome anyone to show erors in my results as I'm new to this and might have well made some mistakes that need correcting !!!! All the needed information I'm working from has already been posted in these threads.
====================================================
1 second median - incoming packets = 300 pps
1 second median - incoming bandwidth = 335,000 bits SEC

Therefore; median packet = 138 bytes (1116 bits)

If connection = 8 million bits/sec, And if no packet limit, then 8M/1116 = 7168 PPS "natural limit" for this packet size on this line.

(not included PPP overhead so not 100% accurate)
====================================================

edit: note to self "PPS * (average packet size in bytes) = bytes per second"

Edited by deleted (Mon 25-Mar-13 16:20:15)

You also need to take account of contention. If these are standard DSL services then you will not be guaranteed line speed at any time as the amount others are using will impact on what you have available. It is more likely that you will see dropped packets on the shared/contended portions of the backhaul and therefore you may well see the same losses even with a faster headline sync speed.