security/hakurei.app
security/hakurei.app
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 4 Wiki Activity

explain why Diffserv is not as useful as it seems

Browse Source
This commit is contained in:
Daniel Micay 2020-12-27 23:12:28 -05:00
parent 6c673d712e
commit a6a88dc6bb
1 changed files with 13 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
static/articles/server-traffic-shaping.html
View File

@ -164,13 +164,20 @@
<pre>tc qdisc replace dev eth0 root cake bandwidth 1995mbit besteffort</pre> <pre>tc qdisc replace dev eth0 root cake bandwidth 1995mbit besteffort</pre>
<p>On a server, setting it to use 100% of the provisioned bandwidth may work fine
in practice. Unlike a local network connected to a consumer ISP, you shouldn't
need to sacrifice anywhere close to the typically recommended 5-10% of your
bandwidth for traffic shaping.</p>
<p>This also sets <code>besteffort</code> for the common case where the server <p>This also sets <code>besteffort</code> for the common case where the server
doesn't have Quality of Service markings via Diffserv. If you actually have doesn't have appropriate Quality of Service markings set up via Diffserv. Fair
traffic marked as bulk, video or voice to differentiate it consider changing that. scheduling is already great at providing low latency by cycling through the hosts
On a server, setting it to use 100% of the provisioned bandwidth may work fine in and streams without needing this kind of configuration. The defaults for Diffserv
practice. Unlike a local network connected to a consumer ISP, you shouldn't need traffic classes like real-time video are set up to yield substantial bandwidth in
to sacrifice anywhere close to the typically recommended 5-10% of your bandwidth exchange for lower latency. It's easy to set this up wrong and it usually won't
for traffic shaping.</p> make much sense on a server. You might want to set up marking low priority traffic
like system updates, but it will already get a tiny share of the overall traffic
on a loaded server due to fair scheduling between hosts and streams.</p>
<p>You can use the <code>tc -s qdisc</code> command to monitor CAKE:</p> <p>You can use the <code>tc -s qdisc</code> command to monitor CAKE:</p>