So u just set the download to your real speedtest result?
I disable download QoS completely.
If you must input a bandwidth parameter, yeah, you could virtually disable QoS if you were to input a bandwidth that exceeds (by a not a small amount) your measured bandwidth.
Download & upload only practically (technically, from a unnetworked, absolutist "I have data, I need to send data" perspective, only sending can be controlled and receiving is uncontrolled) differ by the inherent latency between TCP's request & response of congestion control.
When your gateway router sends LAN-originating data, if the router is receiving data faster than it can send the data, it will
drop packets to let the LAN-sender know to slow-down, which will take just a few milliseconds for the sender to sense congestion, plus a couple milliseconds for the sender to enforce (because some packets are "in-flight") the decreased bitrate, then another couple of milliseconds for the gateway router to actually begin receiving the slowed bitrate it requested.
So... now apply the same logic to
downloads, but realize that TCP's congestion avoidance "request, receipt, response, and answer" has to deal with hundreds of milliseconds of internet latency, rather than just a few milliseconds between LAN clients. This means that the global download bitrate needs to have a rate-limited bandwidth ceiling that is low enough to never be exceeded even when multiple (could be hundreds, with bittorrents) senders may exceed your configured bitrate maximum for hundreds of milliseconds before you actually receive the slowed bitrate you requested.
The respected toastman even
advises limiting download up to 60% to avoid download saturation.
From a QoS perspective, the internet backbones solve latency problems by the most reliable possible method: never exceed 50% link saturation.