![]() | This article may be too technical for most readers to understand.(September 2010) |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
![]() | The contents of the Priority-based flow control page were merged into Ethernet flow control on 2012-02-01. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
I am no wiser after reading the current version. It reads like a technical manual description for computer networking experts. Would be great if someone in the know can turn it into an encyclopedia entry. Thanks. Tale 10:26, 7 October 2005 (UTC)
I see that the test link is broken: http://www.iol.unh.edu/testsuites/ethernet/archive.php#Flow%20Control%20Test%20Suites I'm not sure if I should link to ftp://ftp.iol.unh.edu/pub/ethernet/test_suites/CL31_FC/flow_control_testsuite_v1.3.pdf maybe someone else can correct it. For now I think we should remove the link.
It contains no technical detail, just restating the obvious which anyone with a networking background would know (Duh, I know what Ethernet is, I know what flow control is, I want to know the details of exactly how it works in Ethernet).
Frankly, these kind of articles are on topics which only IT people would be interested in, and so if you are not from an IT background, you shouldn't expect to understand it. These articles shouldn't be explaining obvious stuff like Ethernet, flow control. If you don't know what those things are, go learn about them first before tackling something like this. —The preceding unsigned comment was added by 137.111.11.69 ( talk) 21:07, 31 January 2007 (UTC).
That sounds wrong. The multicast is not sent to the originator of the flow, but only on the link that is congested. I think the scenario is node A and B sending to node C through a switch. The pause goes from C back the othe switch, not back to the nodes A and B. This needs to be fixed, perhaps with a diagram, and even better a reliable source! Also major issue is that switches that do Virtual Output Queues (most of them by now) do not have input queues, so usually drop instead of sending pause frames. W Nowicki ( talk) 00:25, 10 May 2011 (UTC)
As far as I can tell, IEEE 802.1Qbb is the same mechanism with a simply extended frame format with a time for each class. So hardly deserves its own article IMO. Anyone object if I merge them? That article just uses two of the cited sources here in its external links, and provides nothing further. W Nowicki ( talk) 23:05, 10 May 2011 (UTC)
802.1Qbb (per flow pause frames) are an extension to standard Ethernet pause frames and as such COULD be merged with this topic. If anything though, it should be linked to a DCB/DCE/CEE topic which is addressing a wider issue of running storage and standard ethernet traffic over a 'converged' layer 2 network (although it's not limited to this application). This'll make it easier to understand what the issues are and how the 4 DCB protocols (PFC,ETS,CN,DCBx) are implemented to mitigate potential issues with network convergence. A real-life example is always useful in understanding what nut a technology is trying to crack. -- Bigv2004 ( talk) 14:19, 1 November 2011 (UTC)
Ethernet is 802.3; the priority-based work was done in 802.1 and is not specific to Ethernet (being done at an upper layer). It may be the state of the art solution for Ethernet networks but it's not part of Ethernet. Maybe the article should be renamed "priority-based flow control"? Laugh Tough ( talk) 19:03, 7 December 2013 (UTC)
I think the reference to "Vendors on flow control". Network World Fusion. September 13, 1999. (which is broken) should point to http://archive.is/mDZlm
The "Ethernet Flow Control" link in External References no longer takes you to the 29West article. (You get redirected to unrelated Informatic content.) Ideally we could find the original content and fix the link (but I couldn't find it quickly), otherwise I think the link should simply be removed. Curtbeckmann ( talk) 17:56, 10 July 2019 (UTC)
![]() | This article may be too technical for most readers to understand.(September 2010) |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
![]() | The contents of the Priority-based flow control page were merged into Ethernet flow control on 2012-02-01. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
I am no wiser after reading the current version. It reads like a technical manual description for computer networking experts. Would be great if someone in the know can turn it into an encyclopedia entry. Thanks. Tale 10:26, 7 October 2005 (UTC)
I see that the test link is broken: http://www.iol.unh.edu/testsuites/ethernet/archive.php#Flow%20Control%20Test%20Suites I'm not sure if I should link to ftp://ftp.iol.unh.edu/pub/ethernet/test_suites/CL31_FC/flow_control_testsuite_v1.3.pdf maybe someone else can correct it. For now I think we should remove the link.
It contains no technical detail, just restating the obvious which anyone with a networking background would know (Duh, I know what Ethernet is, I know what flow control is, I want to know the details of exactly how it works in Ethernet).
Frankly, these kind of articles are on topics which only IT people would be interested in, and so if you are not from an IT background, you shouldn't expect to understand it. These articles shouldn't be explaining obvious stuff like Ethernet, flow control. If you don't know what those things are, go learn about them first before tackling something like this. —The preceding unsigned comment was added by 137.111.11.69 ( talk) 21:07, 31 January 2007 (UTC).
That sounds wrong. The multicast is not sent to the originator of the flow, but only on the link that is congested. I think the scenario is node A and B sending to node C through a switch. The pause goes from C back the othe switch, not back to the nodes A and B. This needs to be fixed, perhaps with a diagram, and even better a reliable source! Also major issue is that switches that do Virtual Output Queues (most of them by now) do not have input queues, so usually drop instead of sending pause frames. W Nowicki ( talk) 00:25, 10 May 2011 (UTC)
As far as I can tell, IEEE 802.1Qbb is the same mechanism with a simply extended frame format with a time for each class. So hardly deserves its own article IMO. Anyone object if I merge them? That article just uses two of the cited sources here in its external links, and provides nothing further. W Nowicki ( talk) 23:05, 10 May 2011 (UTC)
802.1Qbb (per flow pause frames) are an extension to standard Ethernet pause frames and as such COULD be merged with this topic. If anything though, it should be linked to a DCB/DCE/CEE topic which is addressing a wider issue of running storage and standard ethernet traffic over a 'converged' layer 2 network (although it's not limited to this application). This'll make it easier to understand what the issues are and how the 4 DCB protocols (PFC,ETS,CN,DCBx) are implemented to mitigate potential issues with network convergence. A real-life example is always useful in understanding what nut a technology is trying to crack. -- Bigv2004 ( talk) 14:19, 1 November 2011 (UTC)
Ethernet is 802.3; the priority-based work was done in 802.1 and is not specific to Ethernet (being done at an upper layer). It may be the state of the art solution for Ethernet networks but it's not part of Ethernet. Maybe the article should be renamed "priority-based flow control"? Laugh Tough ( talk) 19:03, 7 December 2013 (UTC)
I think the reference to "Vendors on flow control". Network World Fusion. September 13, 1999. (which is broken) should point to http://archive.is/mDZlm
The "Ethernet Flow Control" link in External References no longer takes you to the 29West article. (You get redirected to unrelated Informatic content.) Ideally we could find the original content and fix the link (but I couldn't find it quickly), otherwise I think the link should simply be removed. Curtbeckmann ( talk) 17:56, 10 July 2019 (UTC)