Talk:Advanced traffic control

From ArchWiki
Latest comment: 9 June 2017 by Lahwaacz in topic Classification


This topic is of special interest to system administrators even though they're definitely not the only consumers of this (embedded devices come to mind). Traffic shaping isn't suited for most desktop users (who likely would never need such a thing) but if you're administering a CDN or something of the sort traffic shaping is especially relevant. I've also seen plenty of people use traffic shaping for personal seedboxes which I would classify as systems administration of the non-enterprise variety. It's not as if I'm linking here from the Vulkan or the kernel page or something.

Bratchley (talk) 17:07, 9 June 2017 (UTC)Reply[reply]

Anything in Category:Networking can be of greater or lesser interest to system administrators. Yet Category:Networking and Category:System administration are completely separate, except some categories are both in Category:Networking and Category:Security (see Table of contents). We would like to keep the categories disjoint, their complementarity should be obvious. If you have some other ideas, please join Talk:List_of_applications#Radical_alternative, which is the most recent discussion about the categorization problems.
As for making the page more visible, there are other (better) ways: e.g. in-text links or the related articles box.
-- Lahwaacz (talk) 18:20, 9 June 2017 (UTC)Reply[reply]

Poor Quality

This article is complete garbage, it tells one nothing of substance. It should start with providing *practical* examples that solve the most encountered problems in this domain.

Start with the easy ones:

+ 2 classes, web browsing vs VOIP/SSH
+ 3 classes, web browsing vs online gaming vs VOIP/SSH
+ 4 classes, web browsing vs bulk downloads (bittorrent) vs online gaming vs VOIP/SSH

Instead there are almost no examples but dry theoretical background information that's pretty much unreadable, even by someone with decades of networking experience.

Fidelio (talk) 00:23, 23 November 2015 (UTC)Reply[reply]

You can't offer that kind of advice. Performance tuning doesn't work like that. You can sometimes make certain statement that function as rules of thumb but workload can vary widely even between two instances of the same program. Since you can't offer advice that's categorically true your best bet is to explain how the system works and expect people to figure out what they need to do. Bratchley (talk) 01:39, 23 November 2015 (UTC)Reply[reply]
I should also mention that printed out, this article is only 6 pages long. If anything it doesn't have enough information in it. I would agree that it needs to be re-worked, though. The structure is a bit random at the moment. That's different than what you're wanting to do, though. Bratchley (talk) 01:47, 23 November 2015 (UTC)Reply[reply]

TCP Windowing

I just submitted some updates here. It's important to check out the wikipedia page for TCP Tuning. Receiving end-nodes can throttle the ingress speed by monkeying around with the receive window with the expectation that the sender will eventually pause its transmission to wait for some of those packets to be ACK'd. Also, bullet point number 6 on this page elaborates on this a little further at a high level (rest of the document is Windows-specific). Bratchley (talk) 14:22, 7 January 2015 (UTC)Reply[reply]