On Sat, 2018-02-03 at 05:56 +0000, Michael Junek wrote:
Below is my config. The per connection queueing is handled by the individual queue types, which are then bound in the simple queue which handles the aggregate.
Thanks for that; it has been a great help. I modified my queue setup to be more like yours, thusly: /queue type add kind=pcq name=Guest-10K-Downstream \ pcq-burst-time=1s \ pcq-classifier=dst-address \ pcq-rate=10k add kind=pcq name=Guest-10K-Upstream \ pcq-burst-time=1s \ pcq-classifier=dst-address \ pcq-rate=10k /queue simple add max-limit=10k/10k name=test \ queue=Guest-10K-Upstream/Guest-10K-Downstream \ target=192.168.100.0/24 .. and that worked much better, but still not as I expected, The transfer rate of a test file over the supposedly limited link was around 60 kilobytes per second. That's still tens of times higher than it should be, but way more acceptable than hundreds of kilobytes or even megabytes per second. Hence my question as to whether you have tested the limits your queuing is supposed to impose, by which I mean objectively, not using the Mikrotiks themselves to tell you :-) And another slightly pathetic question: Am I correct in expecting "maxlimit=10k/10k" to limit the affected traffic to ten kilobits per second in either direction, i.e. to somewhere around 1 kilobyte in either direction? That is, are the real transfer speeds of 60 kilobytes per second that I am seeing definitely unexpectedly high? Regards, K. PS: These are my queue stats. They make no sense to me. 0 name="test" target=192.168.100.0/24 \ rate=6.0kbps/3.3kbps total-rate=0bps \ packet-rate=11/3 total-packet-rate=0 \ queued-bytes=0/1072 total-queued-bytes=0 \ queued-packets=0/5 total-queued-packets=0 \ bytes=787434/715998 total-bytes=0 \ packets=6933/3005 total-packets=0 \ dropped=0/207 total-dropped=0 \ pcq-queues=8/1 What also puzzles me a lot is that with my 10k/10k limit in place, interactive comms with the router (CLI) is affected; echo delays and so forth. This is true even when there is no other traffic happening, and the CPU is at 1%. Take away the queue and the effect stops immediately. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D Old fingerprint: 58F8 09D4 97E4 D74A 0940 44BC 8D6D C28C 3BC9 B0CB