[omniORB] Latencies - Oneway vs. Roundtrip

[Helge Penne]

Jim Redman wrote:

> I have a counter-intuitive latency problem and would like some input and
> validation of what I think I'm seeing.  This is strictly latency, not
> throughput.   Running between two NT 4.0 system with 2.7.0 I see latencies
> for oneway messages that appear to approach 100ms.  When I change the same
> calls to roundtrip the latencies drop below the NT measurable time (about
> 10ms?).
>
> Has anyone seen anything similar or different, that is, can anyone confirm
> or deny my numbers.

I've now compiled and tested my modification on Windows NT 4.0.

The following lines were added in tcpSocketMTfactory.cc at line 834:

  BOOL bNoDelay = TRUE;
  int nResult = setsockopt( sock, IPPROTO_TCP, TCP_NODELAY, (const
char*)&bNoDelay, sizeof(bNoDelay) );
  if (nResult)
  {
 int nError = WSAGetLastError(); // For debug purposes...
 return RC_SOCKET_ERROR;
  }

This turns off the socket send buffering, which removes the long latency for
oneway calls.  It seems to work OK on NT.  I have not tested it on other
platforms.  Note that this change could probably affect the performance
omniORB, so only do this is you actually need it.

This buffering issue really is an important detail for real time and semi-real
time applications, where this kind of buffering will hardly ever be what you
want.

If something like this was to be incorporated into the source tree, I would
really like to be able to turn this on or off when the omniORB is initialized
(this is the way it is done in VisiBroker).  I suspect it could be complicated
to hand the correct information down from the initialization code to the
realConnect function in tcpSocketMTfactory, but I won't have time to look at
this for a while.

--
Helge Penne (helge.penne@datarespons.no)
Senior Software Development Engineer
Data Respons AS, Postboks 489, N-1323 Høvik, Norway
Phone: +47 67112081 / 22719957 (work/home)