This group is locked. No changes can be made to the group while it is locked.
Re: [openflowplugin-dev] https://bugs.opendaylight.org/show_bug.cgi?id=2905
|
Anton Ivanov
On 30/03/15 09:12, Michal Polkoráb
wrote:
This one - not yet. I started setting up a benchmark environment as I have to do proper benchmarks for the proposed fixes for ser/des as well (bug 2825) last week. Unfortunately, I had to switch urgently to clear something else out of my queue. I am just about done with what I had to context-switch to, so I will get back to the benchmark task ASAP. Otherwise, I have worked on similar stuff in the past - the difference depends on rtt. Based on my recollections from implementing mobile signalling over TCP, for very small rtt (virtual switch on same host) it will probably be not more than 50% for command-acknowledge sequence. For LAN you are looking at 2x difference. For WAN - even more than that. For ~ 10ms you may see several times difference depending on use case. There is a reasonable write-up on this here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-Application_Tuning_and_Deployment-TCP_NODELAY_and_Small_Buffer_Writes.html Java does not do cork, but we can emulate it in the ser/des layer so that is not a big deal. Further write up here http://www.techrepublic.com/article/tcp-ip-options-for-high-performance-data-transmission/ and ... frankly everywhere. All the way back to TCP Illustrated. http://www.amazon.co.uk/TCP-IP-Illustrated-Protocols-APC/dp/0201633469 This is the de-facto standard of implementing low-latency TCP response-ack. If you do not do it, you are guaranteed to get the latencies which the world is demonstrating for our stuff on CBENCH. A.
|
|
|
