Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #199620

Re: Network issue

Show all headers | View raw

> ... I advise to look at your hardware configuration like flow control.
> This line doesn't seem good for me (mind the text in bold):
>
> "Aug 28 15:50:34 ovh-1 kernel: e1000e: enp1s0 NIC Link is Up 100 Mbps Full
> Duplex, *Flow Control: None"*

In general, enabling flow control is a bad idea - more so if qos is enabled.

I saved this snippet because it's a good explanation of why not to
enable flow control (& the snark about the former wife still makes me
grin :)

>From seifert@netcom.com Tue Mar 23 12:58:14 1999
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: 802.3x Flow Control -- Who has it?

802.3x reminds me of my former marriage--at the time, they both seemed like
good ideas. However, in retrospect, neither made a lot of sense. =8^)

Here's an excerpt on the subject (of .3x, not my former marriage), from my
upcoming book, "Make the Switch! A Comprehensive Guide to LAN Switching
Technology":

--------begin excerpt--------
It is important to remember that the PAUSE function was designed for a very
specific use at a very specific time‹to prevent buffer overflow for
memory-constrained switches with an input-queued architecture. At the time
the protocol was devised (1995-96), many low-cost switches used an
input-queued approach, and switch memory was relatively expensive. Reducing
the cost of a switch usually meant reducing its memory capacity; by using
PAUSE-style flow control, such a switch could provide a good
price/performance mix and yet avoid frame loss under peak overload
conditions. The PAUSE protocol is less useful today with lower-cost memory
and the popularity of output-queued switches.

In addition, TCP uses frame loss within the network as its indication of
congestion. That is, TCP¹s end-to-end flow control mechanism detects
underlying frame loss, and uses this information to throttle its flow. If
switches prevent frame loss under congestion conditions, TCP will never
recognize the congestion and will continue sourcing data into the network;
in fact, TCP will see a lack of frame loss over time as an indication that
it can increase the offered load, further exacerbating the congestion
problem. If the switches dropped an occasional frame, TCP would throttle
back the offered load and alleviate much of the network congestion with no
need for PAUSE. This is the concept behind the Random Early Discard (RED)
approach to flow control. Implementing link-layer flow control on switches
can actually interfere with the end-to-end flow control.
  ---------

Regards,
Lee

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Network issue Reco <recoverym4n@gmail.com> - 2018-08-29 21:10 +0200
  Re: Network issue Fekete Tamás <fektom@gmail.com> - 2018-08-29 21:30 +0200
    Re: Network issue Fekete Tamás <fektom@gmail.com> - 2018-08-29 21:50 +0200
    Re: Network issue Lee <ler762@gmail.com> - 2018-08-30 00:40 +0200
  Re: Network issue Nicholas Geovanis <nickgeovanis@gmail.com> - 2018-08-29 22:40 +0200
    Re: Network issue Reco <recoverym4n@gmail.com> - 2018-08-30 06:30 +0200
  Re: Network issue Michael Stone <mstone@debian.org> - 2018-08-30 00:50 +0200
    Re: Network issue Reco <recoverym4n@gmail.com> - 2018-08-30 06:40 +0200
      Re: Network issue Michael Stone <mstone@debian.org> - 2018-08-30 12:40 +0200
        Re: Network issue Reco <recoverym4n@gmail.com> - 2018-08-30 13:00 +0200

csiph-web