Lost speed to ISP when QoS enabled

I stopped using those bandwidth checkers. I found that they are absolute garbage…

Try using fast.com - Its the NetFlix bandwidth checker. Should be more accurate.


No waste? Even though I am only getting 50% of the speed for normal operations does not sound waste-free. Low loss potential and stability is all good, and so is preventing lower priority tasks from grabbing all the bandwidth. We actually agree on this part, yet you continue to argue that yours is the only way to tackle the problem.

I’ve suggested here, repeatedly, a different approach to handling QoS. You reject it out of hand, I understand that. Your model starts with the assumption that the best results are achieved by limiting – absolutely – use of available bandwidth. Other models, however, including some that have been implemented, start with the assumption of a minimum rather than a maximum (though they provide for maximum limits as well).

What bothers me the most here is that you seem to deduce every last thing I state as though my chief and only concern is pure speed. I don’t need QoS to achieve speed so much as I need it to ensure that a service, such as Zoom, or any other service, will be able to obtain the minimal bandwidth needed to provide reliable and non-latent reproduction. (Notice I said “minimal” not “maximal?” – because that is the nature of the problem to be solved.)

Cutting off a service at the upper bound is not desirable unless one is concerned about tying up the network connection with only one type of work, choking others out, resulting in compromised service for such things as sound and video which typically require low latency. So, if one were to provide a file sharing server, e.g., one would certainly want to limit how much bandwidth is used by that service; otherwise, too many users moving too much data at once could potentially negatively impact, e.g., those video and audio services.

I am absolutely certain that I need a minimum, not maximum, amount of bandwidth to ensure good playback of streaming services. I think that the user DJ-melo said is probably the most accurate: Your QoS implementation only does half the job. It would work fine for file serving and other services not requiring low latency. But it will choke out other work, in most cases unnecessarily, because of the model you have chosen to implement. But an artificial maximum is mostly wasteful for other types of services.

I understand that it might not be the aim of this particular project, Ipfire, to implement what I view as a more inclusive solution that is based more largely on minimum bandwidths rather than maximum ones. Perhaps this situation will not change going forward, as is the right of the project leadership that I respect. But realizing this, I am evaluating other firewall appliance software also.

N.B.: Please stop with the condescension and patronizing; it doesn’t help me and actually creates an intimidating environment. Keep the board informative, not personal. I would be much obliged if you would, please.

I’m not arguing about anything. I am merely telling you how QoS works here. You are the one unhappy about it not doing the things you believe it should do.

As I pointed out, you are loosing 50% of your potential speed due to a misconfiguration. That is your doing not the systems. If 95Mbps is the speed you are paying for then use 92150 as your Down/Up entry. Go test,…

I agree with Eric on this. Click show more info once done. And let us know the result.

Oh I’m sorry. I thought this post was a request to help resolve a problem you are experiencing and not a suggestion to DevOps on product changes.
How about trying this approach? Step back, look at what it asks, and provide it with the correct information. Let it do it’s job, and then start tweaking it towards the results you want, within the work environment it provides.

Maybe you want to reread your orignal post and follow ups. Stop the circular argumentation and clearly say what you want to achieve. You created those wrong impressions I responded to. The Minimum bandwith you speak of is the “Guaranteed bandwith” I spoke of as shown in the QoS WebGUI.

Absolutly correct, there will still be a bit of loss though, hence the 3-5% reduction we all spoke of.

That is what we have been saying. And for the preset to work correctly, unless you want to define all values manually, it requires an accurate max value that the line has. You need to provide that, otherwise how is it supposed to calculate the minimum values?

It actaully already does that, have another look.

Maybe we clear the air here a bit…

This is a community site, none of us work for ipFire, neither are any of us being paid for our time, input, or expertise.
We are not required to help.
We do so as it helps form bonds in the open source community, it assists in learning new things (no-one knows all), creates a form of social cohesion, and it improves the open source product along the way…when provided with accurate and constructive feedback.
Reading your post you assume we all are employed by ipFire and that we somehow owe you something. You are seriously mistaken.
You are the one who started with the condescending manner. I merely echoing your attitude… and I am still being relatively civil (polite) in my response.
Don’t like the echo? Change it.

And a final tidbit on QoS.
QoS that do traffic shapping by using a form of packet delay approach cause traffic congestion and high latency when things heat up. By that I mean, large amount of users start hammering the line at the same time. Especially when using low bandwidth link that end up buffering packets before sending them on. Considering that most ISP already use a form of traffic shaping to limit the abuse peer-to-peer traffic has, this approach just adds to an existing problem, one that QoS is supposed to try and improve on. Whilst this type of traffic shaping approach may be acceptable in a SOHO environment, it is not very useful in a medium to large network. Both IPCop and SmoothWall use this approach, hence results may vary compared to ipFire.


Yea, you might not believe it, but I didn’t even know fast.com existed until about a 2 months ago when ISP traffic went to crap at my provider. I was supposed to be getting bi-directional TX RX 1 GB Fiber throughput. That went apparently sideways, because I was only getting tops 300 MB RX, and like 50 TX. I tried everything, just like the notes above, and someone told me about the Netflix checker, and poof, all of a sudden I was able to more accurately measure bandwidth throughput.

Hi all,

since this discussion seems to be come overheated and off-topic, I just want to remind everyone to stay polite and focused to the actual problem. Otherwise, this topic will be closed.

Thanks, and best regards,
Peter Müller

Bandwidth values ​​are not defined?

I understand now

On wiki:

  • Classes which begin with 1 (101, 102, etc) are outbound rules. These control traffic being uploaded on your internet connection, such as sending email or uploading a document online.
  • Classes beginning with 2 are rules for your download bandwidth.
  • Special Classes include 101, 110 and 210. It’s best not to change these three classes as it may cause problems with QoS in IPFire.
    • 110 and 210 are defined as Default downlink and uplink respectively. All traffic which does not match any other class will be regulated by this class. These classes should have low priority (6 or 7) and low Guaranteed Bandwidth values to ensure they stay out of the way of higher priority traffic.
    • 101 is defined as the ACK class, for acknowledgement packets.
  • Tip: You may wish to define a 201 class with no rules as a place holder. This way the colors of classes in your Uplink and Downlink graphs will match