Do relays throttle queueing?

RouterOS General
1

I have included a graphic describing my basic WISP configuration. I serve two neighborhoods using one MikroTik, the second neighborhood through a wireless relay link. I am using EnGenius radio units instead of MikroTik radio cards due to environmental considerations.
Relay graphic 2009.jpg
I am using the following queueing parameters:

/queue interface set WANFeed queue=ethernet-default
/queue interface set Customers queue=wireless-default
/queue type add kind=pcq name=pcq-to-users   pcq-classifier=dst-address pcq-limit=50 pcq-rate=620000 pcq-total-limit=2000
/queue type add kind=pcq name=pcq-from-users pcq-classifier=src-address pcq-limit=50 pcq-rate=300000 pcq-total-limit=2000
/queue simple add direction=both dst-address=0.0.0.0/0 interface=Customers limit-at=256000/512000 max-limit=300000/620000 /
   name=CQ queue=pcq-from-users/pcq-to-users target-addresses=192.168.0.0/18 total-queue=wireless-default /
   burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s parent=none priority=8

In neighborhood A, this seems to be doing an adequate job of delivering half-meg download service to each subscriber. In neighborhood B, my download speeds are atrociously low. It’s possible I am having radio link problems, but my tests aren’t showing that.

It struck me to ask whether it is possible that my queueing setup is throttling the entirety of neighborhood B to a combined throughput of a half meg because it has decided to throttle all traffic through the …1.21 bridge to a maximum of a half meg. My original assumption is that the traffic would be throttled only according to its ultimate destination (e.g., …1.112), and that each individual subscriber should obtain a half meg, but the behavior I am seeing makes me wonder if my assumption was incorrect.

2

Wow. I am amazed that in two weeks nobody could answer what I thought was a simple question for a trained MikroTik user. Perhaps this indicates a need for specific mention of this issue in the manual.

3

change interface=all and try again.

4

The problem in question has been solved (it was in fact an obscure radio problem) but the original question itself still deserves an answer.

5

I’m lost… You say the original problem deserves an answer. But you fixed it with the radio change?
My guess is that your problem is be cuase of a bad radio?

6

My original problem was a bad radio. But what caused my original problem is independent of the question of whether queueing throttles the total traffic through relays on the same subnet. If after three weeks, no one on this board can give a straight yes or no answer to what I should think should be a relatively simple question for someone who has been trained in MikroTik queueing (I haven’t), that is a pretty good indication that the answer should be documented somewhere. Is this clearer?

7

well if I came across your post earlier, I would of asked:

What do you mean by relay?
Why are you using bridging?
Bridging is probably why the link is slower ( But then again I have a bridged connection myself and I get 35 mbit udp.
Your code doesnt say which device that is on, and I do not know what interface is named “Customers” I would assume that the wlan card on either side of your bridge is called “customers” and the limit for that is set to what you set it?

Your question is asking something without the required information given, ie, your asking if a queue throttles the total traffic, yes it can, but you can set it up to be spcific to an IP, or what ever you want, again, relay is mentioned and I might be tired right now, but I cannot understand what you mean by relay, are you asking if its possible to throttle using a queue through a BRIDGE on the same subnet?

are you using packet marking?

I’m by no way certified MT consultant, but I have experimented with quite a bit of the stuff in ROS, and basically learn as I go, trial and error. If my brother has no internet for a few hours, no big deal. THe reason why I am playing around with the different features of ROS is to learn the functionality of it and how it reacts if I do not what it is supposed to do. I do plan on providing internet to some businesses, but I wanted to learn the “best Practices” first. I did learn that using a bridged network is not good on larger scale deployments, so that is why I am figuring out what device is going to go where, and what to route where.

Like the shirt said " Friends don’t let friends bridge networks"

EDIT: I looked after I posted, Dumb me, only one Mikrotik device in there ha ha.. Ok so, you have a queue that throttles to 500K on interface “Customers” wich is either a WLAN card that you have labled as bridge, OR you have another AP connected via ethernet cable to an ethernet port of the RB, in eaither case your queue is set to throttle that interface. As to how you fixed it by changing the radio, I have no clue, becuase that queue would of still been there.

8

i would like to note, that there is a difference of backbone and end points. You do not want your point-to-point links be saturated with traffic that will be shaped elsewhere. That is why traffic limitation usually occurs after first hop, so client is saturating only his link not a part of backbone.

9

“Customers” is a software bridge (/interface bridge) internal to the MikroTik that consists of all ports other than the one labeled “WAN.” (I could have made it a single port and connected all the equipment to a dumb switch to achieve the same effect, but I had spare ports up the wazoo on the MikroTik and couldn’t imagine why adding a superfluous piece of fallible hardware would be preferable.)

I use the term “relay” in the old-fashioned sense of any link that connects a main station to an outpost. It consists of a bridge (other meaning of bridge) and an AP, as pictured. I am using bridging because I cannot arrange a direct broadband feed into the remote neighborhood, nor (for the number of subscribers there) would it be cost-effective for me to do so if I could.

I am not marking any packets. The commands provided in the initial posting are the entire set of queueing commands I run with. I am not opposed to marking packets, it just seemed unnecessary to do so given the queueing instructions at http://wiki.mikrotik.com/wiki/PCQ_Examples .

Ignore the fact that I had a problem and ignore the fact that I fixed it. It’s really no longer germane to the issue that still remains, which is an issue of how queueing works with a certain configuration.

I have never seen the T-shirt, nor would I understand the joke if I had.

As to janisk’s note, I’m afraid I don’t immediately comprehend it, though I suspect it may be very relevant to what I ask. To me, “backbone” means the WAN, but I suspect that is not the way janisk is using the term, and I would have to understand that in order to understand the point. I also don’t understand the recommendation that “traffic limitation occurs after first hop,” as I have only one router and I’m not sure what he considers the “first” hop (as I can’t do any shaping after the traffic leaves my router).

Saturation of my relay link, in terms of signal capacity, should not be an issue at this time with the number of subscribers in the remote neighborhood, only what artificial limitations queueing imposes on it; but I need to understand whether the traffic is limited only from the MikroTik to each end user, or whether there is another aggregate limitation being invisibly imposed on the units labeled …1.21 and …1.31.

10

only limitations that exists are ones you set up yourself or ones that by hardware ports.

about hop - A is client, B is your router

A------B is one hop, in your case you have A-----B-----C = 2 hops

if it is working now, because there are only some subscribers - that is ok, when you have problems, you will know where to look.

if you are using simple queues with target address set - you do not need to mark packets as simple queues with address set can do the job well, if you consider using PCQ queue type with simple queues - go for it, so you users share link equally (according to limit) as result, you end up with less queues, and smallest possible latency.