trying to understand the "net.core.wmem_default" parameter

From: a s p a s i a (aspasia_at_pair.com)
Date: 02/18/04

  • Next message: Richard Ottinger: "RE: Courier Compressed Font" 
    To: redhat-list@redhat.com
Date: Wed, 18 Feb 2004 14:56:54 -0800 (PST)

    hello,

    can someone please explain simply what
    the "net.core.wmem_default" parameter
    in /etc/sysctl.conf exactly affect?

    an example:

    # increase Linux TCP buffer limits
    net.core.rmem_max = 8388608
    net.core.wmem_max = 8388608
    net.core.rmem_default = 65536
    net.core.wmem_default = 65536

    Questions:

    1. rmem and wmem - defaults - someone mentioned is:
     TCP send and receive socket buffer sizes:
    "It is essentially the maximum size of the linked list that is used to
    hold the socket buffers for a particular connection."

    what exactly does this mean? is this the congestion window
    for TCP only packets? What if my application is running UDP -
    will changing/tuning the above parameters matter?

    2. Is it a true statement to say:

    Conventionally value for buffers used for reading network values are twice
    the value for writes as the reads are interrupt driven and therefore flow
    control cannot be imposed....As writes can be controlled by the host O/S
    then the kernel can make the application block.

    again, what if my application is running UDP not TCP, does the
    above statement still hold true?

    thanks in advance,

    - a.

    a s p a s i a
    . . . . . . . 

    -- 
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
  • Next message: Richard Ottinger: "RE: Courier Compressed Font"

    Relevant Pages

    • Re: Coordinating TCP projects
      ... It is rapidly becoming clear that quite a few of us have Big Plans for the TCP implementation over the next 12-18 months. ... Jim and I recently discussed the idea of implementing autotuning of the TCP reassembly queue size based on analysis of some experimental work we've been doing. ... This means that if the TCP window grows to be more than 48 segments wide, and a packet is lost, the receiver will buffer the next 48 segments in the reassembly queue and subsequently drop all the remaining segments in the window because the reassembly buffer is full i.e. 1 packet loss in the network can equate to many packet losses at the receiver because of insufficient buffering. ... We observed that the socket receive buffer size provides a good indication of the expected number of bytes in flight for a connection, and can therefore serve as the figure to base the size of the reassembly queue on. ...
      (freebsd-arch)
    • Re: Coordinating TCP projects
      ... It is rapidly becoming clear that quite a few of us have Big Plans for the TCP implementation over the next 12-18 months. ... Jim and I recently discussed the idea of implementing autotuning of the TCP reassembly queue size based on analysis of some experimental work we've been doing. ... This means that if the TCP window grows to be more than 48 segments wide, and a packet is lost, the receiver will buffer the next 48 segments in the reassembly queue and subsequently drop all the remaining segments in the window because the reassembly buffer is full i.e. 1 packet loss in the network can equate to many packet losses at the receiver because of insufficient buffering. ... We observed that the socket receive buffer size provides a good indication of the expected number of bytes in flight for a connection, and can therefore serve as the figure to base the size of the reassembly queue on. ...
      (freebsd-net)
    • Re: Coordinating TCP projects
      ... It is rapidly becoming clear that quite a few of us have Big Plans for the TCP implementation over the next 12-18 months. ... Jim and I recently discussed the idea of implementing autotuning of the TCP reassembly queue size based on analysis of some experimental work we've been doing. ... This means that if the TCP window grows to be more than 48 segments wide, and a packet is lost, the receiver will buffer the next 48 segments in the reassembly queue and subsequently drop all the remaining segments in the window because the reassembly buffer is full i.e. 1 packet loss in the network can equate to many packet losses at the receiver because of insufficient buffering. ... We observed that the socket receive buffer size provides a good indication of the expected number of bytes in flight for a connection, and can therefore serve as the figure to base the size of the reassembly queue on. ...
      (freebsd-arch)
    • Re: Coordinating TCP projects
      ... It is rapidly becoming clear that quite a few of us have Big Plans for the TCP implementation over the next 12-18 months. ... Jim and I recently discussed the idea of implementing autotuning of the TCP reassembly queue size based on analysis of some experimental work we've been doing. ... This means that if the TCP window grows to be more than 48 segments wide, and a packet is lost, the receiver will buffer the next 48 segments in the reassembly queue and subsequently drop all the remaining segments in the window because the reassembly buffer is full i.e. 1 packet loss in the network can equate to many packet losses at the receiver because of insufficient buffering. ... We observed that the socket receive buffer size provides a good indication of the expected number of bytes in flight for a connection, and can therefore serve as the figure to base the size of the reassembly queue on. ...
      (freebsd-net)
    • Re: Fundamentals question, is this how it works?
      ... processing packets after you are done with one. ... receving the buffer size each time. ... TCP is a stream-based protocol, which means that it ignores any attempt ... then the receiving side might get ...
      (microsoft.public.win32.programmer.networks)