Found a way to break QOS?

[dsalch]

One other clarification...

The only reason I know about the tcp /udp stream is that for testing from the center, I can inly cause two udp and one tcp stream. The rest of the network is sielnt.

[dsalch]

I suppose a big question here is, does the mechanism of enforcing minimum bandwidth o ly affect packets that are in queue within the gargoyle router? If the answer is yes, then minimums would not be enforceable if the packets are not delayed in the que because of buffering on either side. The gargoule routerwould then always be able to hand packets off to the surrounding buffers regardless of the bandwidth flows.

How does the minimum bw mechanism work?

[dsalch]

One final observation (out of time for testing today)

It does in fact "seem" that udp streams break minimum BW but tcp streams do not. I do not know this conclusively, but just visual observation with the different conditions seem to demonstrate this.

test condition:
steady tcp stream in class 1 which exceeds minimum BW requirement for that class
Start udp stream in class 2, the tcp stream in class 1 drops well below the minimum.
Start only a tcp stream in class 2 and the class 1 stream seems to drop below the minimum only for a few seconds until the max BW reaches capacity. Then the tcp stream in class 1 returns to the fluctuate around minimum.

I'll do more testing when possible.

thanks!

[pbix]

QoS depends on the Gargoyle router being the bandwidth limiter in any network. Make sure this is the case.

UDP should not break QoS. The router will discard them if needed to enforce its rules on the upload side. Any use of UDP on the download side from the internet implies that sender of the packets will respond to dropped packets. UDP would be otherwise unusable on the internet. The sender is just use a different throttling mechanism than TCP.

You should simplify your system greatly for your testing. Minimum bandwidths in particular are not used or needed for bandwidth sharing. The %bandwidths are used for sharing. Equal sharing between IPs is automatic and does not need anything.

[dsalch]

I removed the "min BW" settings on all three classes, to simplify the setup. I also slightly lowered the "max BW" overall setting. But it "seems" worse now. The bandwidth of one class can drive it to saturation and rob the other two classes. This is all TCP traffic by the way.

These three shots show the simpler config, and then a couple of shots of the bandwidth in play. You will notice three tests in this timeframe, using the "blue" class in the report. As the blue class grows, it pushes the other two out until they almost are completely starved. It is close enough to saturation to drive the ACC total bandwidth "up" becasue the time stayed low.

https://drive.google.com/open?id=1CajNv ... 5VsqD5NBnR

https://drive.google.com/open?id=1UD0_W ... uztUQGX1d6

https://drive.google.com/open?id=1UsR2N ... uOEf9rKD9f

Am I understanding something wrong?

[dsalch]

One last shot. I wondered if the total bandwidth could be off, so I lowered the setting for mas download to 20,000 from 30,000. This is well under the actual bandwidth. But another test showed the same effect, as the blue rose it pushed the other two down. When the blue stopped, the other two returned to normal.

this was why I desired the "min bw" setting, to preserve a minimum for each class where it would never fall below. perhaps something else is wrong?

https://drive.google.com/open?id=1YR_h6 ... coqxf9Ak8q

[pbix]

My understanding from your last post is that you are not actually in saturation. Your graphs never reach and stay in the limit. Lower the bandwidth to 5,000 to try and get into saturation and stay there. The graphs should have a flat top.

Unless we are in saturation QoS is not doing anything at all so it seems the effect you are noticing is not due to QoS.

How many computers are you using to generate this data?
What is the CPU load on your router at this time?

[dsalch]

That's interesting...

The ACC fair limit is increasing during the testing, so I assumed that was a definition of "saturation", since it reached the limit and the ACC limit was rising due to low ping times. Perhaps I am misinterpreting something in that ? Does it have to reach the actual hard limit before QOS starts to perform?

Curiously, the min BW on the Salchstr class does seem to affect throughput before the hard limit is reached. Testing agasint that class shows that it always seems to have hte min bw available even before the hard limit is reached. meaning, the other classes decrease to allow the salchstr class to achieve desired BW.

that said though... salchstr is a minrtt class, so i suppose it would reach "saturation" point sooner?

To answer your questions... In these last tests I managed to generate streams in the three classes doing limited BW downloads from the outside world (aka a video stream). Then set up a high speed stream from the third class to test. This stream is unlimited.If balancing were operating proeprly, I would assume that the original video streams would maintain their level while all available BW would go to the extra unlimited speed stream. is this correct? It does not seem to matter if I use multiple computers or a single in this test, results are the same.

How would I check CPU loadon the router?

[dsalch]

When I can, I will test with an even lower max BW setting.

[dsalch]

Very curious finding...

If i removed the "min BW setting for UPLOAD on the salchstr class, it started working as expected!

So, it is working properly under all conditions I can test as long as there is no minimum BW setting on UL. The bandwidth increases and when it hits the limit, all classes settle into their percentage as expected. Adding back a min BW on upload, regardless of how small, seems to break it.

and by break it i mean, the action of QOS flips in and out. As I watch a longer test run, QOS will start, and stop periodically. Not sure what triggers it. For a while it might work, and then the high speed udp stream takes over and kills the tcp streams. Remove the min be and it works reliably again.