So to be clear and since adding to an on-topic thread is better than making a new one, and we don't have PM:
*assuming NAT=masquerade home router style, wan on eth1, bridging and using ip firewall*
Users outgoing packets TO internet are marked in mangle and shaped in what?
Packets from the internet to users are marked in mangle and shaped in what?

I'm still trying to wrap my head around it. My goal is to shape traffic by type, and not by user since 'users' have multiple devices that can access it all at once.

Something like:
Gaming
Streaming Video (netflix)
Browsing-High (first Xmb of connection)
The rest/torrents

Similar to what you said here:

So the plan is to mark by traffic type in prerouting and limit by traffic type in global-in.
1) we mark all traffic, that would be managed by one particular Queue, at the same place (prerouting)
2) we must mark upload and download for every type of traffic separately
5) we need 2 sets of queues - one for upload, one for download

and i cut out the sections that limit by IP since I have no need for that since my users don't have per-device or per-user priority, just traffic type.

Queue Tree max=-limit=the max limit of the WAN connection
-Gaming / limit-at=3Mbps / queue type: default-small
-Streaming Video (netflix) /limit-at=1-2 streams at the same time/ queue type: default / priority=1
-Browsing-High (first Xmb of connection) / queue type: PCQ /priority=2
-HTTP downloads / queue type: PCQ / priority=3
-The rest/torrents queue type: PCQ

The mentioned PCQ should have limit=5 total-limit=200 rate=0

Can you test with this in the router - one per direction upload/download ?

I figured out the answer to my question two posts above http://forum.mikrotik.com/viewtopic.php ... 74#p338374 .

The router forwards at the gigabit speed and sends the frames to the 100 megabit NIC. The NIC buffer fills and tail-drop occurs there. We prevent this by having a HTB that will drop 9 out of these 10 frames so that we do not have buffering in the NIC buffer.



P.S. if we put each of these 10 into separate leafs - then low level HTB theory applies and this may be still inherited by the Linux HTB (source and docs available on the web)

I vote for LLQ

NetworkPro,

Thank you for your input here and the article. Let me try and explain why I think LLQ is needed, and please correct me if I'm wrong.

We have an extensive network of relays that connects residential and business customers. During the day we see only about 50% utilization of our network, sometimes as low as 25%. At night we see near 90% and we are working to add more bandwidth.

I implemented QoS based on your article and it does seem to help, but, and I'll take a specific example I'm working on. So we have a business customer that has a voip pbx server on site. During the night, when the network is super congested their VoIP works perfectly and I can see their packets winning over everyone else in the queues.

Yet, during the day, even though the total bandwidth consumed is not high at all, the sheer number of packets processed on our (x86 Maxxwave) routers is like x10 the night.

Problem is that with packet priority using RouterOS, the priority only comes to effect when the queues are saturated. Well, in this case the queues are not saturated but the number of packets going through increases the latency a fluctuation a lot, and from what I read about LLQ, it would address this particular problem by allowing marked packets to simply travel in the router ahead of other packets regardless of whether the queue is congested or not.

True, we can go to even faster and faster routers and we will probably do that (our network is all solar+wind based so need to consider the limitations) but if there was a way to tell the router to process certain packets ahead of others, wouldn't that solve our problem?

And if it's possible to do in Mikrotik, how would I do it? How can I give packets priority without the queues reaching limits? And mind you, I tested our routers with mikrotik bandwidth generator mid day and they have a lot more capacity to handle, voip suffers greatly.

We of course checked signal levels during the day, capacity, cpu and other factors on the network.

Your input is appreciated.
Ofer

PS. Our network is fully routed. No NAT no private IPs, each customer is publicly routed with a single or /29 subnet.

interesting situation - this is a good question

so you have a radio network with high pps rates ? If you test the same setup on Gigabit Ethernet what would be the result ?

- problem is elsewhere
- LLQ is a silly thing pushed by Cl$c0 to increase sales (sleazy weasels can put their marketing up their a$$). No QoS should add latency. I challenge them to tell the truth what exactly happens inside their routers when you turn on the thing they call "LLQ"?

Its early morning , I may take a look at the post again later. (yawn)

interesting situation - this is a good question

so you have a radio network with high pps rates ? If you test the same setup on Gigabit Ethernet what would be the result ?

Thank you for the reply. The problem is increased number of packets during the work day with low bandwidth utilization. We are a wireless ISP and yes, our equipment is gigabit ethernet in the relay stations but the gear we use Ubiquiti is not and I can't change that.

Thing is, it does work well during peak hours when bandwidth is maxed, so what I need is to be able to prioritize the packets based on the nature of the packet and not based on whether a queue is saturated or not. Any ideas on how I can do it with Mikrotik?

I understand what you are saying about LLQ and I don't have the knowledge to argue if it's true or not, so let's assume what you are saying is 100% true. I can't also change the wireless gear I'm using. Yet I know voip works great when the number of packets is under control even at 90% bandwidth utilization and that's 90mbit on that leg. But even when the bandwidth is just 25mbit during the day, the voip goes to hell because the pps is increasing and I have no way to tell the packets "you wait" and let the voip pass first...

Any help would be appreciated.

We are a wireless ISP and yes, our equipment is gigabit ethernet in the relay stations but the gear we use Ubiquiti is not and I can't change that.

Thing is, it does work well during peak hours when bandwidth is maxed, so what I need is to be able to prioritize the packets based on the nature of the packet and not based on whether a queue is saturated or not.

I think, in your particular case, it is your wireless equipment that should do packet prioritization. It should be doing it based on the DSCP, which you can set/adjust using some mangle rules on you Mikrotik router.

andriys and network pro,

I thought our system was tagging things properly but I found out that the packets coming out of the pbx system were losing their tags in the router (I am still researching why.) So I made the router re-tag in postrouting and sure enough that addressed the issue. Mid day and things sound more than great!

I guess I'll take my vote off LLQ

Thank you both!
Ofer

@macgaiver

I see that you have good dominance on QOS and reply to user questions in forum . but reading and understanding a multipage forum topic is boring . Why you don't create some wiki documents with full examples (it is better with pictures) and share your knowledge with other users ?

Your efforts will be appreciated .

@macgaiver

I see that you have good dominance on QOS and reply to user questions in forum . but reading and understanding a multipage forum topic is boring . Why you don't create some wiki documents with full examples (it is better with pictures) and share your knowledge with other users ?

Your efforts will be appreciated .

Been there, done that!

Full examples make people lazy - they just copy/paste and do not think, only complain.
Complain that example presented is different from situation they have,

There is no point of making another page of theoretical stuff - nobody will read it - i know that just because it looks like nobody bothers to read the manual

i will stick to this forum - less effort, more results.

Thanks for reply .
I don't mean copy/paste examples . I mean schematic examples with description . I am one of your fans in forum and i search for your posts and learn from them . Learn something that is not in wiki,docs etc . but as i said it is hard to use them as reference .

I mean you put compact part of each useful topic as a wiki article and complete it time to time .

It's just a suggestion . Your efforts will be appreciated .

Thanks for a really interesting thread guys.

One theoretical question, is it possible to do qos without knowing a maximal bandwidth. For example of the isp allows bursting, could qos be implemented without losing the bursting?

My assumption would be no. But curious if there is another answer.

Sent from my SCH-I545 using Tapatalk 2

i vote for llq

i have a similar problem, as is tenenbaum.

Network based on satelite. Consist of micro networks (20-25 users on wifi).
In micro networks wifi mikrotik. If i use router cisco 1801 then voip is good.
If use mikrotik rb2011 voip is very bad. Talking time 1,5 - 3 minutes and disconnect.

Users voip gateway market paket dscp 46.

Hello,

Guys I really need to implement LLQ in my MikroTik router but I was struggling to do so, is there to implement LLQ in MikroTik routers? Thanks

If you need to send out packets without delay or drop, you will have to configure packet queue settings that are already present.

There is no such thing as LLQ this is made up and does not exist. It's a lie.

For more info check the link in my signature.

@macgaiver

I see that you have good dominance on QOS and reply to user questions in forum . but reading and understanding a multipage forum topic is boring . Why you don't create some wiki documents with full examples (it is better with pictures) and share your knowledge with other users ?

Your efforts will be appreciated .

Been there, done that!

Full examples make people lazy - they just copy/paste and do not think, only complain.
Complain that example presented is different from situation they have,

There is no point of making another page of theoretical stuff - nobody will read it - i know that just because it looks like nobody bothers to read the manual

i will stick to this forum - less effort, more results.

When I need to do something new, first I websearch into the wiki.

If that is unsatisfactory, then I try to find the answer in the forum.