Community discussions

MikroTik App
 
Ozelo
Member
Member
Topic Author
Posts: 338
Joined: Fri Jun 02, 2006 3:56 am

Packets per second, bandwidth and throughput...

Fri Jul 28, 2006 12:23 am

I decided to create this thread to talk and possibly share experience with the community about these three items on wireless networking. Im looking initialy for specifications arround hardware limits and technology limits. Furthermore, this thread may become a useful reference to the mentioned subject above on this forum.

I did some measurements on my wireless network and would be nice if people point out corrections/measurements about the whole topic, including post references, benchmarks, etc.

Lets say, the main table to start: Technology and hardware. 802.11b show limits arround 200 pps, while in 802.11a I can see about 4000 pps. Apart the physical limitations in packets, there are known bandwidth and throughput limitations. I mean, if you have 11mb bandwidth limit, does not exactly mean that you will have 200 pps limit or even a corresponding limit on throughput. Of course, there are other variables included like tcp, udp, framing policy, queues, qos, traffic shaping, etc.

The main reason behind this post is about wireless network performance on different ways to acomplish it, i.e: l2tp, dual nstreme, ap, cpe, ppp and routed/bridged devices as well. Many people perhaps are basicly interested in QoS together with p2p, traffic shaping and specialy those using APs in 802.11b.

We have some scenarios to start talk, but first, let me tell you some history. We got specific problems on clients using old 802.11b cards when changing the AP hw to Atheros a/b/g cards, but only when using the AP for 802.11b only. We also got problems on APs that share 802.11b with many different card types on the client side, i.e: AP Atheros a/b/g -> Client Atheros a/b/g + 802.11b only cards.

A MT Wireless Access Point box with about 78 clients in 802.11b. Atheros a/b/g card at the AP side, few MT box with Atheros a/b/g and the rest are a mix of cards for 802.11b and some of them b/g cards, including realtek, d-link, ralink, orinoco, etc... All hidden stations. A side note: On this case, seems that MT to MT get very high priorities over the whole 200 pps limits. Lets say, you can barely see about 300 pps from time to time. Also, this AP have a mix pppoe/static IP clients. So, its difficulties on traffic shaping/qos are not so easy to beat. Most of all complaints are clients with static IP addresses, but are not atheros cards. The total throughput under this conditions does not get more than 2.5mbits/s. Clients with MT boxes can get a CIR of 80-95% easy, all over the rest. We use WRAP router boards and the CPU get less than 25% to do the job.

I was looking for some way to deal with the 200 pps limit, but seems the best way (easy as well) is to turn the AP from 802.11b to 802.11a. Then we get problems at the client side. Well, about 200 clients that use this tower must thrown out the 802.11b cards and then start using 802.11a cards. Queues, specialy the PCQ one or traffic shapping seems does not solve the problem with packets per second and also increase latency a lot. The situation get really worse when the client side (atheros a/b/g cards) are infected with viruses. Otherwise, we need a lot more AP units to do a ressonable coverage with about 25 clients max limit per AP.

I am sure that maybe a good samaritan could give us a great fine tune possible to better handle the situation without leave the 802.11b. :) Please, all comments are welcome.
MTCRE - 1104RE006
MTCINE - 1104INE001
 
sten
Forum Veteran
Forum Veteran
Posts: 920
Joined: Tue Jun 01, 2004 12:10 pm

Re: Packets per second, bandwidth and throughput...

Fri Jul 28, 2006 1:53 am

A MT Wireless Access Point box with about 78 clients in 802.11b. Atheros a/b/g card at the AP side,
78 clients contending for an upper limit of possibly 6mbit (connection less, single flow) aggregated throughput.
What exactly did you base that decision on?
What were the initial numbers?
Please, all comments are welcome.
If you were a plumber and you bought pipe parts/joints from many different manufacturers and after it's all put together you let the water flow at the upper pressure limit of those pipes. What's the probability of leaks?

Then you decide to increase the pressure to somewhere around 39 times what the pipes were designed for. What's the new probability of leaks?

I have come to the conclusion that peoples patience is a little more flexible than the laws of physics and neither like to get tested.
Move along. Nothing to see here.
 
Ozelo
Member
Member
Topic Author
Posts: 338
Joined: Fri Jun 02, 2006 3:56 am

Fri Jul 28, 2006 5:47 am

A MT Wireless Access Point box with about 78 clients in 802.11b. Atheros a/b/g card at the AP side,
78 clients contending for an upper limit of possibly 6mbit (connection less, single flow) aggregated throughput.
What exactly did you base that decision on?
What were the initial numbers?
Well, that was not a decision mine at all. The scenario I described is one of our critical APs nowdays. The number of clients connected can change aprox. from 20 to 80 every day. One of this clients is connected at 512kbps with a PC running MT static addressed and using full link 24/7. There are few other clients (arround 12) static addressed and connected at 256kbps that uses full link aprox. less than six hours/day. The rest are pppoe clients dynamic addressed and normaly 50% of these pppoe clients are connected at 256kbps and the other 50% at 128kbps most part of the time running p2p programs. I only see this AP geting more than 2.5mbits/s (about 3.8mbits/s) when I do a download on a client connected without any traffic shaping. When there are 78 clients aprox and the p2p tap is totaly open on our backbone node concentrator, there are ping loss and average time(2500ms) as well. At this point, this AP in 802.11b I see about 390 to 400 pps. There are other APs in 802.11b with about the same number of clients, none of them using full link all the time, just occasionaly. When there are less than 200 pps, no ping loss and average time of 5ms. P2p seems to be not a problem at last, but seems to aggravate in terms of pps. There are other numbers you would like to know?

Please, all comments are welcome.
If you were a plumber and you bought pipe parts/joints from many different manufacturers and after it's all put together you let the water flow at the upper pressure limit of those pipes. What's the probability of leaks?

Then you decide to increase the pressure to somewhere around 39 times what the pipes were designed for. What's the new probability of leaks?

I have come to the conclusion that peoples patience is a little more flexible than the laws of physics and neither like to get tested.
Im sorry, but you forgot to mention that the sum of all the forces of any nature are always null in any of the reference systems. But in fact, neither peoples patience and law of physics are being tested here, yet. Undoubtably you wont be the first neither will be the last. For someone that floods in expertise, your cortesy was very educational. No no, nothing that I couldnt expect from such a big knowledgement!? Thank you. What else you could do better? Perhaps why patience need to be flexible instead unnecessary rudenessss to someone that you never know who is or when you will need help...


*raises eyebrow* Next...
 
Skaught
Member Candidate
Member Candidate
Posts: 146
Joined: Mon Jun 19, 2006 9:31 pm

Fri Oct 06, 2006 5:00 am

I am trying to find a way to do queues based on packets per second. It seems that is the limiting factor in 802.11b and if we can control that, then we will be in a better position.

Unfortunately all the queuing I can find is based on kb/s not pps.
 
tpsretard
just joined
Posts: 23
Joined: Sat May 28, 2005 12:17 am

Fri Oct 06, 2006 2:59 pm

sten <-- that was such a wonderfull post, try and keep the sarcasem to a minimum, this is actually a very interesting topic...

Skaught there are a few things to do that will help, might not be as eligant in terms of administrating but....

Do traffic shapping on the client router insted of the AP this will stop unwanted traffic pialing up on the wireless side, put a cap on the amount of p2p sessions per sec.

Now i have done some testing with 802.11a, manly because we were looking for a way to backhaul a fair set of bandwidth, the 802.11a seemed to be our best bet as there was a supposed 4,000ps limit on it wich was better than our Alvarion equipment which is 2,000ps, we did some testing with dual nstreem and managed to get to about 5,500ps but the systems we were using then just craped out with 100% cpu so we need to get better systems before we redo our testing.
 
bushy
Member Candidate
Member Candidate
Posts: 140
Joined: Thu Oct 20, 2005 11:56 pm
Location: Ireland

Fri Oct 06, 2006 4:40 pm

I am trying to find a way to do queues based on packets per second. It seems that is the limiting factor in 802.11b and if we can control that, then we will be in a better position.

Unfortunately all the queuing I can find is based on kb/s not pps.
Maybe ask for it in the requests section to be added to a future release ? They are quick to fix up releases here. If its useful to you it will be useful to others too
 
Skaught
Member Candidate
Member Candidate
Posts: 146
Joined: Mon Jun 19, 2006 9:31 pm

Fri Oct 06, 2006 6:34 pm

Do traffic shapping on the client router insted of the AP this will stop unwanted traffic pialing up on the wireless side, put a cap on the amount of p2p sessions per sec.
I have 1200 802.11b client CPEs made by tranzeo owned by my clients I must support. Replacing them with mikrotik would cost nearly half a million dollars and is not an option.

But I am already shpaing P2P etc at the core. Allthough it is still not enough for our needs. It certainly helps though.
 
changeip
Forum Guru
Forum Guru
Posts: 3819
Joined: Fri May 28, 2004 5:22 pm

Fri Oct 06, 2006 8:51 pm

has anyone tried using packet packer in this situation to clump packets together and lower the overall pps ?

Sam
 
tpsretard
just joined
Posts: 23
Joined: Sat May 28, 2005 12:17 am

Sat Oct 07, 2006 12:21 am

i am sorry i did not know that, you has that many CPE's deployed...

Where are you shapping, only at your nock or at the AP also, i had a situation similar to this, and the only solution at the time was to upgrade the AP to a P4 mobile and do shapping on the wireless box it self, this seemed to of help alot...
 
Skaught
Member Candidate
Member Candidate
Posts: 146
Joined: Mon Jun 19, 2006 9:31 pm

Sat Oct 07, 2006 3:30 am

Whoa, that is a neat protocol. IT would only help one way since our CPEs are all non-mikrotik.

But something to keep in mind.

Would it work if only one end is MT?
 
karyal
Member Candidate
Member Candidate
Posts: 168
Joined: Sat Nov 12, 2005 12:09 pm

Sat Oct 07, 2006 10:50 pm

has anyone tried using packet packer in this situation to clump packets together and lower the overall pps ?

Sam
Yes, on a congested link i tried once.. latency gets impacted, but pps (and cpu) get drammaticaly lower, with just simple aggregation, on an RB532.
Bye,
Ricky
 
jober
Long time Member
Long time Member
Posts: 692
Joined: Fri May 28, 2004 12:16 pm
Location: Louisiana,USA

Sun Oct 08, 2006 4:20 am

LOL, Holy crap people. Sten was just trying the help and maybe try to be a little funny at the same time. You really can't call that rued or sarcastic. I know him well enough to know that he meant no disrespect. As I don't.
But if he did I would be the first to call him. And I don't think he did.
he he, You did say any input welcome. LOL

Sorry, In advance if this may have ofinded anyone in any shape or form.
BUT! Like the laid back folks in these parts say"Fork em if he cant take a joke"
 
variable
Member Candidate
Member Candidate
Posts: 217
Joined: Wed Apr 13, 2005 4:36 am

Mon Oct 09, 2006 9:30 pm

can m3p be enabled just on wireless links --> ie. only the bridges compress and decompress the packets, so it doesnt needs to be touched in the router?
 
simonkizi
newbie
Posts: 45
Joined: Mon Jan 30, 2006 10:38 pm

Wed Oct 11, 2006 2:17 am

has anyone tried using packet packer in this situation to clump packets together and lower the overall pps ?

Sam
Hi.

Sorry but how do you do that exactly? (Packet Packer)

Also, you can set queues to limit packet match rate! However, I believe that does not control what the wireless card receives, but after the receipt.

If polling in Nstreme can work for non-Mikrotik clients, then the equal time sharing can help distribute the limited number of packets equally. I believe someone had mentioned this earlier.

Thx
 
Skaught
Member Candidate
Member Candidate
Posts: 146
Joined: Mon Jun 19, 2006 9:31 pm

Wed Dec 13, 2006 2:38 am

What would be s e x y is two options related to this.

- The ability to set the RTS to 1 in non-MT clients and then MT gives CTS in a round robin fashion. Hence pseudo polling but with any 802.11 CPE.

- A windows client program that will allow packing packets right in windows. I am sure I could talk my P2P users into isntalling it as I imagine it could improve performance for them and everyone else too. If there is an existing vendor out there that makes such a thing that would be cool too.
 
sten
Forum Veteran
Forum Veteran
Posts: 920
Joined: Tue Jun 01, 2004 12:10 pm

Thu Dec 14, 2006 8:29 pm

Ah, yes, good idea, but it additionally requires modifications to the clients.
Consider the process where the clients log on to the access point.
What do you think happens if the clients, before they are "authenticated" by the access point, send RTS packets for the authentication packets?
Move along. Nothing to see here.
 
User avatar
NoXy
just joined
Posts: 15
Joined: Thu Sep 15, 2005 11:07 am
Location: Hungary

Wed Dec 20, 2006 9:14 pm

Dear Ozelo!

I got the same problem with pppoe over wifi. At Middle network load we got pings like 2000ms, packet losses etc
At about 30% usage works fine... I don't know where is the problem

:cry:

Who is online

Users browsing this forum: No registered users and 31 guests