• Tuong Lien's avatar
    tipc: add test for Nagle algorithm effectiveness · 0a3e060f
    Tuong Lien authored
    When streaming in Nagle mode, we try to bundle small messages from user
    as many as possible if there is one outstanding buffer, i.e. not ACK-ed
    by the receiving side, which helps boost up the overall throughput. So,
    the algorithm's effectiveness really depends on when Nagle ACK comes or
    what the specific network latency (RTT) is, compared to the user's
    message sending rate.
    
    In a bad case, the user's sending rate is low or the network latency is
    small, there will not be many bundles, so making a Nagle ACK or waiting
    for it is not meaningful.
    For example: a user sends its messages every 100ms and the RTT is 50ms,
    then for each messages, we require one Nagle ACK but then there is only
    one user message sent without any bundles.
    
    In a better case, even if we have a few bundles (e.g. the RTT = 300ms),
    but now the user sends messages in medium size, then there will not be
    any difference at all, that says 3 x 1000-byte data messages if bundled
    will still result in 3 bundles with MTU = 1500.
    
    When Nagle is ineffective, the delay in user message sending is clearly
    wasted instead of sending directly.
    
    Besides, adding Nagle ACKs will consume some processor load on both the
    sending and receiving sides.
    
    This commit adds a test on the effectiveness of the Nagle algorithm for
    an individual connection in the network on which it actually runs.
    Particularly, upon receipt of a Nagle ACK we will compare the number of
    bundles in the backlog queue to the number of user messages which would
    be sent directly without Nagle. If the ratio is good (e.g. >= 2), Nagle
    mode will be kept for further message sending. Otherwise, we will leave
    Nagle and put a 'penalty' on the connection, so it will have to spend
    more 'one-way' messages before being able to re-enter Nagle.
    
    In addition, the 'ack-required' bit is only set when really needed that
    the number of Nagle ACKs will be reduced during Nagle mode.
    
    Testing with benchmark showed that with the patch, there was not much
    difference in throughput for small messages since the tool continuously
    sends messages without a break, so Nagle would still take in effect.
    Acked-by: default avatarYing Xue <ying.xue@windriver.com>
    Acked-by: default avatarJon Maloy <jmaloy@redhat.com>
    Signed-off-by: default avatarTuong Lien <tuong.t.lien@dektech.com.au>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    0a3e060f
socket.c 103 KB