Lowest TCP receive window size Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Data science time! April 2019 and salary with experience The Ask Question Wizard is Live!How to enable TCP_QUICKACK optionHow can I connect to Android with ADB over TCP?Who is listening on a given TCP port on Mac OS X?What is the maximum window size in segments of a TCP connection?Increasing TCP Window SizeBenefit of small TCP receive window?tcp receive window updateTCP receive window and congestion windowTCP receiving window size higher than net.core.rmem_maxHow is the window scale set/calculated in the TCP/IP implementation of the Linux kernel?Window Size when sender is faster than the receiver
As a dual citizen, my US passport will expire one day after traveling to the US. Will this work?
Besides transaction validation, are there any other uses of the Script language in Bitcoin
How to resize main filesystem
Does the main washing effect of soap come from foam?
Random body shuffle every night—can we still function?
Keep at all times, the minus sign above aligned with minus sign below
malloc in main() or malloc in another function: allocating memory for a struct and its members
My mentor says to set image to Fine instead of RAW — how is this different from JPG?
How does the body cool itself in a stillsuit?
Do i imagine the linear (straight line) homotopy in a correct way?
New Order #6: Easter Egg
Table formatting with tabularx?
Why do C and C++ allow the expression (int) + 4*5;
How to achieve cat-like agility?
.bashrc alias for a command with fixed second parameter
Why complex landing gears are used instead of simple, reliable and light weight muscle wire or shape memory alloys?
Calculation of line of sight system gain
Why not use the yoke to control yaw, as well as pitch and roll?
Are there any irrational/transcendental numbers for which the distribution of decimal digits is not uniform?
First paper to introduce the "principal-agent problem"
3D Masyu - A Die
How do you cope with tons of web fonts when copying and pasting from web pages?
Weaponising the Grasp-at-a-Distance spell
How can I prevent/balance waiting and turtling as a response to cooldown mechanics
Lowest TCP receive window size
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)
Data science time! April 2019 and salary with experience
The Ask Question Wizard is Live!How to enable TCP_QUICKACK optionHow can I connect to Android with ADB over TCP?Who is listening on a given TCP port on Mac OS X?What is the maximum window size in segments of a TCP connection?Increasing TCP Window SizeBenefit of small TCP receive window?tcp receive window updateTCP receive window and congestion windowTCP receiving window size higher than net.core.rmem_maxHow is the window scale set/calculated in the TCP/IP implementation of the Linux kernel?Window Size when sender is faster than the receiver
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
What is the lowest possible TCP receive window size can be announced by Linux kernel TCP/IP stack impl and how can i configure to make it announce such one? My goal is to achieve low latency and sacrificing throughput?
sockets tcp network-programming
add a comment |
What is the lowest possible TCP receive window size can be announced by Linux kernel TCP/IP stack impl and how can i configure to make it announce such one? My goal is to achieve low latency and sacrificing throughput?
sockets tcp network-programming
Why do you think that reducing the TCP receive window size reduces latency?
– Maxim Egorushkin
Mar 22 at 14:07
For low latency you should be using UDP with kernel bypass.
– Maxim Egorushkin
Mar 22 at 14:08
"For low latency you should be using UDP with kernel bypass" - At this moment server accept TCP connections only. "Why do you think that reducing the TCP receive window size reduces latency?" - Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.
– hwasin
Mar 22 at 14:40
add a comment |
What is the lowest possible TCP receive window size can be announced by Linux kernel TCP/IP stack impl and how can i configure to make it announce such one? My goal is to achieve low latency and sacrificing throughput?
sockets tcp network-programming
What is the lowest possible TCP receive window size can be announced by Linux kernel TCP/IP stack impl and how can i configure to make it announce such one? My goal is to achieve low latency and sacrificing throughput?
sockets tcp network-programming
sockets tcp network-programming
asked Mar 22 at 12:40
hwasinhwasin
12
12
Why do you think that reducing the TCP receive window size reduces latency?
– Maxim Egorushkin
Mar 22 at 14:07
For low latency you should be using UDP with kernel bypass.
– Maxim Egorushkin
Mar 22 at 14:08
"For low latency you should be using UDP with kernel bypass" - At this moment server accept TCP connections only. "Why do you think that reducing the TCP receive window size reduces latency?" - Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.
– hwasin
Mar 22 at 14:40
add a comment |
Why do you think that reducing the TCP receive window size reduces latency?
– Maxim Egorushkin
Mar 22 at 14:07
For low latency you should be using UDP with kernel bypass.
– Maxim Egorushkin
Mar 22 at 14:08
"For low latency you should be using UDP with kernel bypass" - At this moment server accept TCP connections only. "Why do you think that reducing the TCP receive window size reduces latency?" - Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.
– hwasin
Mar 22 at 14:40
Why do you think that reducing the TCP receive window size reduces latency?
– Maxim Egorushkin
Mar 22 at 14:07
Why do you think that reducing the TCP receive window size reduces latency?
– Maxim Egorushkin
Mar 22 at 14:07
For low latency you should be using UDP with kernel bypass.
– Maxim Egorushkin
Mar 22 at 14:08
For low latency you should be using UDP with kernel bypass.
– Maxim Egorushkin
Mar 22 at 14:08
"For low latency you should be using UDP with kernel bypass" - At this moment server accept TCP connections only. "Why do you think that reducing the TCP receive window size reduces latency?" - Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.
– hwasin
Mar 22 at 14:40
"For low latency you should be using UDP with kernel bypass" - At this moment server accept TCP connections only. "Why do you think that reducing the TCP receive window size reduces latency?" - Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.
– hwasin
Mar 22 at 14:40
add a comment |
1 Answer
1
active
oldest
votes
Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.
I do not think that changing the receive window size will have any effect on latency.
However, since your messages are small (128 bytes), you may like to disable Nagle algorithm in the sender that makes the sender wait when sending TCP payload smaller than MSS:
Applications that expect real-time responses and low latency can react poorly with Nagle's algorithm. Applications such as networked multiplayer video games or the movement of the mouse in a remotely controlled operating system, expect that actions are sent immediately, while the algorithm purposefully delays transmission, increasing bandwidth efficiency at the expense of latency. For this reason applications with low-bandwidth time-sensitive transmissions typically use
TCP_NODELAY
to bypass the Nagle delay.
On the receiver you may like to disable TCP delayed acknowledgements:
The additional wait time introduced by the delayed ACK can cause further delays when interacting with certain applications and configurations. If Nagle's algorithm is being used by the sending party, data will be queued by the sender until an ACK is received. If the sender does not send enough data to fill the maximum segment size (for example, if it performs two small writes followed by a blocking read) then the transfer will pause up to the ACK delay timeout. Linux 2.4.4+ supports a
TCP_QUICKACK
socket option that disables delayed ACK.
C++ code:
void disableTcpNagle(int sock)
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_NODELAY)");
void enableTcpQuickAck(int sock)
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_QUICKACK, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_QUICKACK)");
I agree with your commentary, but the problem is that i dont have access to server and i'd like to know whether its even possible technically to enforce kernel announce lower TCP window on client side.
– hwasin
Mar 22 at 14:58
@hwasin AddedTCP_QUICKACK
note for you.
– Maxim Egorushkin
Mar 22 at 15:01
Thank you. I tried this option and still receiver windows size is not reduced. Please see this question
– hwasin
Mar 22 at 15:05
@hwasinTCP_QUICKACK
has nothing to do with the receivers window size. The receive window size is controlled bySO_RCVBUF
socket option.
– Maxim Egorushkin
Mar 22 at 15:06
But if TCP_QUICKACK option is enabled and hence my 128 bytes ACKnowledgment should be delivered to server then client should announce 128 byte receiver window too, but kernel does not do that, it waits till SO_RCVBUF/2 window size can be announced.
– hwasin
Mar 22 at 15:14
|
show 6 more comments
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55299828%2flowest-tcp-receive-window-size%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.
I do not think that changing the receive window size will have any effect on latency.
However, since your messages are small (128 bytes), you may like to disable Nagle algorithm in the sender that makes the sender wait when sending TCP payload smaller than MSS:
Applications that expect real-time responses and low latency can react poorly with Nagle's algorithm. Applications such as networked multiplayer video games or the movement of the mouse in a remotely controlled operating system, expect that actions are sent immediately, while the algorithm purposefully delays transmission, increasing bandwidth efficiency at the expense of latency. For this reason applications with low-bandwidth time-sensitive transmissions typically use
TCP_NODELAY
to bypass the Nagle delay.
On the receiver you may like to disable TCP delayed acknowledgements:
The additional wait time introduced by the delayed ACK can cause further delays when interacting with certain applications and configurations. If Nagle's algorithm is being used by the sending party, data will be queued by the sender until an ACK is received. If the sender does not send enough data to fill the maximum segment size (for example, if it performs two small writes followed by a blocking read) then the transfer will pause up to the ACK delay timeout. Linux 2.4.4+ supports a
TCP_QUICKACK
socket option that disables delayed ACK.
C++ code:
void disableTcpNagle(int sock)
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_NODELAY)");
void enableTcpQuickAck(int sock)
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_QUICKACK, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_QUICKACK)");
I agree with your commentary, but the problem is that i dont have access to server and i'd like to know whether its even possible technically to enforce kernel announce lower TCP window on client side.
– hwasin
Mar 22 at 14:58
@hwasin AddedTCP_QUICKACK
note for you.
– Maxim Egorushkin
Mar 22 at 15:01
Thank you. I tried this option and still receiver windows size is not reduced. Please see this question
– hwasin
Mar 22 at 15:05
@hwasinTCP_QUICKACK
has nothing to do with the receivers window size. The receive window size is controlled bySO_RCVBUF
socket option.
– Maxim Egorushkin
Mar 22 at 15:06
But if TCP_QUICKACK option is enabled and hence my 128 bytes ACKnowledgment should be delivered to server then client should announce 128 byte receiver window too, but kernel does not do that, it waits till SO_RCVBUF/2 window size can be announced.
– hwasin
Mar 22 at 15:14
|
show 6 more comments
Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.
I do not think that changing the receive window size will have any effect on latency.
However, since your messages are small (128 bytes), you may like to disable Nagle algorithm in the sender that makes the sender wait when sending TCP payload smaller than MSS:
Applications that expect real-time responses and low latency can react poorly with Nagle's algorithm. Applications such as networked multiplayer video games or the movement of the mouse in a remotely controlled operating system, expect that actions are sent immediately, while the algorithm purposefully delays transmission, increasing bandwidth efficiency at the expense of latency. For this reason applications with low-bandwidth time-sensitive transmissions typically use
TCP_NODELAY
to bypass the Nagle delay.
On the receiver you may like to disable TCP delayed acknowledgements:
The additional wait time introduced by the delayed ACK can cause further delays when interacting with certain applications and configurations. If Nagle's algorithm is being used by the sending party, data will be queued by the sender until an ACK is received. If the sender does not send enough data to fill the maximum segment size (for example, if it performs two small writes followed by a blocking read) then the transfer will pause up to the ACK delay timeout. Linux 2.4.4+ supports a
TCP_QUICKACK
socket option that disables delayed ACK.
C++ code:
void disableTcpNagle(int sock)
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_NODELAY)");
void enableTcpQuickAck(int sock)
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_QUICKACK, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_QUICKACK)");
I agree with your commentary, but the problem is that i dont have access to server and i'd like to know whether its even possible technically to enforce kernel announce lower TCP window on client side.
– hwasin
Mar 22 at 14:58
@hwasin AddedTCP_QUICKACK
note for you.
– Maxim Egorushkin
Mar 22 at 15:01
Thank you. I tried this option and still receiver windows size is not reduced. Please see this question
– hwasin
Mar 22 at 15:05
@hwasinTCP_QUICKACK
has nothing to do with the receivers window size. The receive window size is controlled bySO_RCVBUF
socket option.
– Maxim Egorushkin
Mar 22 at 15:06
But if TCP_QUICKACK option is enabled and hence my 128 bytes ACKnowledgment should be delivered to server then client should announce 128 byte receiver window too, but kernel does not do that, it waits till SO_RCVBUF/2 window size can be announced.
– hwasin
Mar 22 at 15:14
|
show 6 more comments
Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.
I do not think that changing the receive window size will have any effect on latency.
However, since your messages are small (128 bytes), you may like to disable Nagle algorithm in the sender that makes the sender wait when sending TCP payload smaller than MSS:
Applications that expect real-time responses and low latency can react poorly with Nagle's algorithm. Applications such as networked multiplayer video games or the movement of the mouse in a remotely controlled operating system, expect that actions are sent immediately, while the algorithm purposefully delays transmission, increasing bandwidth efficiency at the expense of latency. For this reason applications with low-bandwidth time-sensitive transmissions typically use
TCP_NODELAY
to bypass the Nagle delay.
On the receiver you may like to disable TCP delayed acknowledgements:
The additional wait time introduced by the delayed ACK can cause further delays when interacting with certain applications and configurations. If Nagle's algorithm is being used by the sending party, data will be queued by the sender until an ACK is received. If the sender does not send enough data to fill the maximum segment size (for example, if it performs two small writes followed by a blocking read) then the transfer will pause up to the ACK delay timeout. Linux 2.4.4+ supports a
TCP_QUICKACK
socket option that disables delayed ACK.
C++ code:
void disableTcpNagle(int sock)
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_NODELAY)");
void enableTcpQuickAck(int sock)
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_QUICKACK, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_QUICKACK)");
Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.
I do not think that changing the receive window size will have any effect on latency.
However, since your messages are small (128 bytes), you may like to disable Nagle algorithm in the sender that makes the sender wait when sending TCP payload smaller than MSS:
Applications that expect real-time responses and low latency can react poorly with Nagle's algorithm. Applications such as networked multiplayer video games or the movement of the mouse in a remotely controlled operating system, expect that actions are sent immediately, while the algorithm purposefully delays transmission, increasing bandwidth efficiency at the expense of latency. For this reason applications with low-bandwidth time-sensitive transmissions typically use
TCP_NODELAY
to bypass the Nagle delay.
On the receiver you may like to disable TCP delayed acknowledgements:
The additional wait time introduced by the delayed ACK can cause further delays when interacting with certain applications and configurations. If Nagle's algorithm is being used by the sending party, data will be queued by the sender until an ACK is received. If the sender does not send enough data to fill the maximum segment size (for example, if it performs two small writes followed by a blocking read) then the transfer will pause up to the ACK delay timeout. Linux 2.4.4+ supports a
TCP_QUICKACK
socket option that disables delayed ACK.
C++ code:
void disableTcpNagle(int sock)
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_NODELAY)");
void enableTcpQuickAck(int sock)
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_QUICKACK, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_QUICKACK)");
edited Mar 22 at 15:01
answered Mar 22 at 14:45
Maxim EgorushkinMaxim Egorushkin
90.7k11104193
90.7k11104193
I agree with your commentary, but the problem is that i dont have access to server and i'd like to know whether its even possible technically to enforce kernel announce lower TCP window on client side.
– hwasin
Mar 22 at 14:58
@hwasin AddedTCP_QUICKACK
note for you.
– Maxim Egorushkin
Mar 22 at 15:01
Thank you. I tried this option and still receiver windows size is not reduced. Please see this question
– hwasin
Mar 22 at 15:05
@hwasinTCP_QUICKACK
has nothing to do with the receivers window size. The receive window size is controlled bySO_RCVBUF
socket option.
– Maxim Egorushkin
Mar 22 at 15:06
But if TCP_QUICKACK option is enabled and hence my 128 bytes ACKnowledgment should be delivered to server then client should announce 128 byte receiver window too, but kernel does not do that, it waits till SO_RCVBUF/2 window size can be announced.
– hwasin
Mar 22 at 15:14
|
show 6 more comments
I agree with your commentary, but the problem is that i dont have access to server and i'd like to know whether its even possible technically to enforce kernel announce lower TCP window on client side.
– hwasin
Mar 22 at 14:58
@hwasin AddedTCP_QUICKACK
note for you.
– Maxim Egorushkin
Mar 22 at 15:01
Thank you. I tried this option and still receiver windows size is not reduced. Please see this question
– hwasin
Mar 22 at 15:05
@hwasinTCP_QUICKACK
has nothing to do with the receivers window size. The receive window size is controlled bySO_RCVBUF
socket option.
– Maxim Egorushkin
Mar 22 at 15:06
But if TCP_QUICKACK option is enabled and hence my 128 bytes ACKnowledgment should be delivered to server then client should announce 128 byte receiver window too, but kernel does not do that, it waits till SO_RCVBUF/2 window size can be announced.
– hwasin
Mar 22 at 15:14
I agree with your commentary, but the problem is that i dont have access to server and i'd like to know whether its even possible technically to enforce kernel announce lower TCP window on client side.
– hwasin
Mar 22 at 14:58
I agree with your commentary, but the problem is that i dont have access to server and i'd like to know whether its even possible technically to enforce kernel announce lower TCP window on client side.
– hwasin
Mar 22 at 14:58
@hwasin Added
TCP_QUICKACK
note for you.– Maxim Egorushkin
Mar 22 at 15:01
@hwasin Added
TCP_QUICKACK
note for you.– Maxim Egorushkin
Mar 22 at 15:01
Thank you. I tried this option and still receiver windows size is not reduced. Please see this question
– hwasin
Mar 22 at 15:05
Thank you. I tried this option and still receiver windows size is not reduced. Please see this question
– hwasin
Mar 22 at 15:05
@hwasin
TCP_QUICKACK
has nothing to do with the receivers window size. The receive window size is controlled by SO_RCVBUF
socket option.– Maxim Egorushkin
Mar 22 at 15:06
@hwasin
TCP_QUICKACK
has nothing to do with the receivers window size. The receive window size is controlled by SO_RCVBUF
socket option.– Maxim Egorushkin
Mar 22 at 15:06
But if TCP_QUICKACK option is enabled and hence my 128 bytes ACKnowledgment should be delivered to server then client should announce 128 byte receiver window too, but kernel does not do that, it waits till SO_RCVBUF/2 window size can be announced.
– hwasin
Mar 22 at 15:14
But if TCP_QUICKACK option is enabled and hence my 128 bytes ACKnowledgment should be delivered to server then client should announce 128 byte receiver window too, but kernel does not do that, it waits till SO_RCVBUF/2 window size can be announced.
– hwasin
Mar 22 at 15:14
|
show 6 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55299828%2flowest-tcp-receive-window-size%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Why do you think that reducing the TCP receive window size reduces latency?
– Maxim Egorushkin
Mar 22 at 14:07
For low latency you should be using UDP with kernel bypass.
– Maxim Egorushkin
Mar 22 at 14:08
"For low latency you should be using UDP with kernel bypass" - At this moment server accept TCP connections only. "Why do you think that reducing the TCP receive window size reduces latency?" - Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.
– hwasin
Mar 22 at 14:40