This is the
talk page for discussing improvements to the
CoDel article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article was nominated for deletion on 15 August 2012 (UTC). The result of the discussion was keep. |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
|
Actually openwrt switched to the FQ_codel variant of codel, not codel. So have all the downstream users of openwrt (cerowrt, dd-wrt, many distros based on openwrt, etc. Desparately need to write up fq_codel for wikipedia. We have RFCs and the like in progress.
You might want to cite some of the videos, if you haven't already, notably Van's.
http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos
we quote van's comments on fq_codel a lot. (note, codel is still great as an AQM, still winning against things like pie, it's just that fq_codel is even better)
--dtaht — Preceding
unsigned comment added by
2001:470:E47C:2:94FF:244F:B798:6817 (
talk) 16:24, 24 January 2014 (UTC)
OK, I corrected the timeline. And yea, we have to write something about fq_codel next. — Preceding unsigned comment added by Dtaht ( talk • contribs) 20:24, 24 January 2014 (UTC)
The algorithm is currently better known as CoDel. I propose a change of title once AfD has closed. -- Kvng ( talk) 14:28, 16 August 2012 (UTC)
Done -- Kvng ( talk) 13:12, 22 August 2012 (UTC)
The sentence "He then suggested that a better metric might be the minimum amount of delay experienced by any packet in the sliding window of the buffer." has this: http://www.pollere.net/Pdfdocs/QrantJul06.pdf as citation, but I don't see that suggestion anywhere in that paper. — Preceding unsigned comment added by 121.121.81.136 ( talk) 03:33, 1 December 2012 (UTC)
Addendum: Van Jacobsen, David Taht and the rest were barking up the wrong wall till after 3 Dec 2011: https://dl.acm.org/doi/10.1145/2063166.2071893#comment-4466836527
In my opinion the actual solution to latency is not a reduction in buffer sizes. Because the real problem isn't actually large buffers. The problem is devices holding on to packets longer than they should. Given the wide variations in bandwidth, it is easier to define "too high a delay" than it is to define "too large a buffer".
From the wiki article itself: "He(VJ) suggested that a better metric might be the minimum queue length during a sliding time window.". Which is still wrong! Note that unlike delay, minimum queue length is NOT parameterless. It can vary a lot depending on the case. So it seems misleading in a codel article to mention a 2006 paper that's barking up the wrong wall, talking about queue lengths, and saying don't let queues stay full. With codel you can have X to infinite length queues that are never empty, it doesn't matter - it's all about delay. The May 2012 paper should be fine, but do note that's AFTER the 2011 comment on the bufferbloat article on which David Taht commented "The publication deadline for this missed the adoption of Byte Queue Limits (BQL)" - note they were still fixated bytes and sizes, nothing about time and delay. Only after the comment does Taht say: 'The concept of relying far more heavily on "Time in Queue", and expiring old packets, has great potential.'. 121.123.81.152 ( talk) 10:54, 29 June 2021 (UTC)
"But if the buffer is too small, then the buffer will fill up and will itself not be able to accept more packets than one per RTT cycle. So the buffer will stabilize the rate at which packets enter the network link, but it will do so with a fixed delay for packets in the buffer. This is called bufferbloat".
Is this correct? I thought bufferbloat happened when the buffer was *too large* and the buffer fills faster than it can be emptied. I've gone ahead and changed it now, but I think that whole section could be clearer. Amaurea ( talk) 13:52, 20 July 2013 (UTC)
The algorithm described at the moment is kinda off. The wording ("last packet of the interval") suggests that CoDel is working in successive intervals of 100ms. Actually the 'interval' is treated as a sliding window. And I'm fairly confident that the dropping state is left *immediately* when the queue is less than 5ms; it doesn't wait another interval, even a reduced one. Look at the pseudocode.
Positive idea: Wikipedia is supposed to use secondary sources. This article could start from the LWN article. It's a secondary source, but they're practically embedded journalists for the Linux kernel development process, so they get technical details bang on. https://lwn.net/Articles/496509/
http://www.dslreports.com/forum/r30057740- Sourcejedi ( talk) — Preceding undated comment added 10:16, 15 May 2015 (UTC)
The article claims that CoDel is parameterless (and uses a broad citation to attribute that to the authors).
But the acceptable minimum delay (5ms), the initial (and reset) interval (100ms), and the interval reduction sub-algorithm (interval_sub_N = initial_interval/(square_root(N)) are all parameters -- and at least the first two are likely to be things that should get tuned by at least a device manufacturer, if not in the field.
JimJJewett ( talk) 23:19, 1 September 2015 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on CoDel. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 18 January 2022).
Cheers.— InternetArchiveBot ( Report bug) 22:21, 9 August 2017 (UTC)
This is the
talk page for discussing improvements to the
CoDel article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article was nominated for deletion on 15 August 2012 (UTC). The result of the discussion was keep. |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
|
Actually openwrt switched to the FQ_codel variant of codel, not codel. So have all the downstream users of openwrt (cerowrt, dd-wrt, many distros based on openwrt, etc. Desparately need to write up fq_codel for wikipedia. We have RFCs and the like in progress.
You might want to cite some of the videos, if you haven't already, notably Van's.
http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos
we quote van's comments on fq_codel a lot. (note, codel is still great as an AQM, still winning against things like pie, it's just that fq_codel is even better)
--dtaht — Preceding
unsigned comment added by
2001:470:E47C:2:94FF:244F:B798:6817 (
talk) 16:24, 24 January 2014 (UTC)
OK, I corrected the timeline. And yea, we have to write something about fq_codel next. — Preceding unsigned comment added by Dtaht ( talk • contribs) 20:24, 24 January 2014 (UTC)
The algorithm is currently better known as CoDel. I propose a change of title once AfD has closed. -- Kvng ( talk) 14:28, 16 August 2012 (UTC)
Done -- Kvng ( talk) 13:12, 22 August 2012 (UTC)
The sentence "He then suggested that a better metric might be the minimum amount of delay experienced by any packet in the sliding window of the buffer." has this: http://www.pollere.net/Pdfdocs/QrantJul06.pdf as citation, but I don't see that suggestion anywhere in that paper. — Preceding unsigned comment added by 121.121.81.136 ( talk) 03:33, 1 December 2012 (UTC)
Addendum: Van Jacobsen, David Taht and the rest were barking up the wrong wall till after 3 Dec 2011: https://dl.acm.org/doi/10.1145/2063166.2071893#comment-4466836527
In my opinion the actual solution to latency is not a reduction in buffer sizes. Because the real problem isn't actually large buffers. The problem is devices holding on to packets longer than they should. Given the wide variations in bandwidth, it is easier to define "too high a delay" than it is to define "too large a buffer".
From the wiki article itself: "He(VJ) suggested that a better metric might be the minimum queue length during a sliding time window.". Which is still wrong! Note that unlike delay, minimum queue length is NOT parameterless. It can vary a lot depending on the case. So it seems misleading in a codel article to mention a 2006 paper that's barking up the wrong wall, talking about queue lengths, and saying don't let queues stay full. With codel you can have X to infinite length queues that are never empty, it doesn't matter - it's all about delay. The May 2012 paper should be fine, but do note that's AFTER the 2011 comment on the bufferbloat article on which David Taht commented "The publication deadline for this missed the adoption of Byte Queue Limits (BQL)" - note they were still fixated bytes and sizes, nothing about time and delay. Only after the comment does Taht say: 'The concept of relying far more heavily on "Time in Queue", and expiring old packets, has great potential.'. 121.123.81.152 ( talk) 10:54, 29 June 2021 (UTC)
"But if the buffer is too small, then the buffer will fill up and will itself not be able to accept more packets than one per RTT cycle. So the buffer will stabilize the rate at which packets enter the network link, but it will do so with a fixed delay for packets in the buffer. This is called bufferbloat".
Is this correct? I thought bufferbloat happened when the buffer was *too large* and the buffer fills faster than it can be emptied. I've gone ahead and changed it now, but I think that whole section could be clearer. Amaurea ( talk) 13:52, 20 July 2013 (UTC)
The algorithm described at the moment is kinda off. The wording ("last packet of the interval") suggests that CoDel is working in successive intervals of 100ms. Actually the 'interval' is treated as a sliding window. And I'm fairly confident that the dropping state is left *immediately* when the queue is less than 5ms; it doesn't wait another interval, even a reduced one. Look at the pseudocode.
Positive idea: Wikipedia is supposed to use secondary sources. This article could start from the LWN article. It's a secondary source, but they're practically embedded journalists for the Linux kernel development process, so they get technical details bang on. https://lwn.net/Articles/496509/
http://www.dslreports.com/forum/r30057740- Sourcejedi ( talk) — Preceding undated comment added 10:16, 15 May 2015 (UTC)
The article claims that CoDel is parameterless (and uses a broad citation to attribute that to the authors).
But the acceptable minimum delay (5ms), the initial (and reset) interval (100ms), and the interval reduction sub-algorithm (interval_sub_N = initial_interval/(square_root(N)) are all parameters -- and at least the first two are likely to be things that should get tuned by at least a device manufacturer, if not in the field.
JimJJewett ( talk) 23:19, 1 September 2015 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on CoDel. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 18 January 2022).
Cheers.— InternetArchiveBot ( Report bug) 22:21, 9 August 2017 (UTC)