https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/OPNFLWJAVA-47 openflowjava <p>TCP initializer does not set NO_DELAY option. This has effect across all OS-es, but has especially bad effects on connection latency on Linux with kernel 3.14 and later which does additional aggressive throughput optimizations. This is why I am tagging this for Linux (Ubuntu LTS with updates will default to 3.16).</p> <p>For nearly all openflow use cases openflow should operate in no-delay mode instead of throughput mode. This includes what openflow benchmarks call "throghput" as the actual throughput there is nowhere near what TCP means as throughput optimization. As a result of this option being not set:</p> <p>1. OS Kernel will try to enqueue multiple frames to merge them into a single packet and wait until another frame is available instead of sending it immediately.</p> <p>2. OS Kernel will not turn off additional throughput related optmizations (autocork in Linux) which are enabled by default.</p> <p>This is a trivial one-liner, I will send a patch for it later today.</p> <p>Operating System: Linux<br/> Platform: All</p> OPNFLWJAVA-47

TCP Options incorrect

Bug Resolved Done Anton Ivanov Anton Ivanov Fri, 27 Mar 2015 07:19:41 +0000 Tue, 7 Apr 2015 08:11:52 +0000 Tue, 7 Apr 2015 08:11:52 +0000 unspecified General 0 3 <p>master : <a href="https://git.opendaylight.org/gerrit/#/c/17213/1" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/17213/1</a><br/> stable/helium : <a href="https://git.opendaylight.org/gerrit/#/c/17219/1" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/17219/1</a></p> <p>Additional offline discussion and inspection of the netty source showed that it presently defaults to having this option on (opposite to OS defaults). This is the correct behavior by design in a double buffering environment.</p> <p>However, in order to ensure that this behavior is correct in the future either for netty or if someone writes a replacement, this should be specified explicitly so that the desired behavior is known (it just will have no effect for now).</p> <p>I am going to drop this to minor now as it effectively documentation, code tidiness and cosmetic at this stage.</p> <p>Both changes were merged.</p> Development External issue ID 2905 External issue URL Rank 0|i02fzj: