RESOLVED -simple queue without packets drop on ccr1036 v6.18

Hi.
On the 200Mbit/s I have CCR1036 to distribute internet access to 20+ offices. I limit bandwidth using ‘simple default queue type’ and I have no complains from clients. However, when I limit one customer on that router to 50 Mbit/s they get enough dropped packets to loose online licenses, which require “X” amount of time to re-login. Though, when I disable queue, the traffic from them easily goes to 200 or whatever is available without any problems.

For this customer I assign public IP with 1 to 1 NAT (they use their own server/firewall). I need help finding a way to limit the speed without any packets loss. As soon as 40 workstations go in production and traffic reaches 50 I get drops with different settings I’ve tried. ‘default queue type’ works better then ‘default-small’ but still unacceptable.

Please help!!!

bump

Rate limiting happens by delaying, then dropping packets. You can not push 200Mbps of traffic through a 50Mbps pipe. Some will have to fall off outside the pipe and end up on the floor. The packets on the floor are “dropped” packets.

You are using the “default” or “default-small” queue type. Those run out of buffers pretty early in the throughput smoothing by delaying packets phase. When they run out of buffer space, they drop packets. If you are seeing excessive packet loss with 25 - 40 Mbps running through your 50Mbps queue, this is probably the problem.

You can increase the buffer size or switch the “default-small” and/or “default” queue types from using pfifo to sfq. The defaults are not good defaults in the days of >10Mbps network links.

If there is more than 50Mbps of traffic attempting to go through your 50Mbps queue, you will have packet loss. Switching to SFQ may help to keep any one connection from being penalized too heavily while other connections get all they want.

Please read and understand http://wiki.mikrotik.com/wiki/Manual:Queue.

Try latest 6.19rc, preferably on other partition :slight_smile:

Thank you lambert. I do understand how queue works. I would really like to know how ISPs are shaping without me “dropping”. Here is the test I’ve done on one of the live networks:
From ISP 100mbps up/down
1.
ftp server 192.168.0.2 set to 50/50 and upload is running all the time.
from comp1 192.168.0.3 no drops running ping test (without and with default speed upload)

ftp server uploading at 50
queue set to 50 on 192.168.0.3
from comp1 192.168.0.3 lots of drops just running ping test

ftp server upload at 80
from comp1 i can upload at 20 - no drops

ftp server is OFF
from comp1 i can upload at 100 - no drops

What am I missing? Why without queue i have no drops? How comp1 is “holding” the traffic?

used:
Queue Type - default
Total Queue Type - default-small

tested to simple queue to 50 on 100mbps and to 80 on 200. No drops in Total Statistics, no complains from client transferring huge files between the servers over vpn connection

Also, as a side note, on this speeds multiprocessor routers to be used (CPU goes to 100 with one simple queue like mentioned above on rb2011)

Maybe an example will translate better.

/queue type set [find name=default-small] kind=sfq
/queue type set [find name=default] kind=sfq

For why I am suggesting that you try changing the queue “kind” : http://wiki.mikrotik.com/wiki/Manual:Queue#Kinds and also http://www.tldp.org/HOWTO/Traffic-Control-HOWTO/classless-qdiscs.html and https://www.google.com/#q=pfifo%20vs%20sfq

If “sfq” still doesn’t make you happy, try “red”.

With pfifo, one large, fast stream can fill the queue bytes. When that happens, other streams are likely to have so many packets dropped that they can not maintain their TCP connection.

Which queue “kind” works best for you depends on your traffic.

Thank you kindly, lambert. I will defiantly try suggested queue “kind” and study further…

All the best,
Yuri

Thanks, sfq help me lot but still dropped some packets.

A queue which is passing traffic at close to the max limit speed will drop packets.

You did not provide any information about your configuration. We cannot know the cause of your dropped packets. We can only guess.

You may want to start your own topic. Tell us everything about the hardware, your queue configuration, the throughput you are seeing, how much packet loss you are measuring, and what your goals are.