OT: TCP: trading latency for bandwidth



On May 17, 2:06 am, johnson.e...@xxxxxxxxx wrote:
On Wednesday, May 16, 2012 2:17:21 PM UTC-4, David Froble wrote:
Aside with putting up with the deficiencies in HP TCP/IP, I'm getting
slightly decent with socket communications.

By deficiencies, are you referring to the slow performance?  I've always found the TCP/IP stacks on VMS to be incredibly sluggish.  It's not just a bandwidth problem, it's very slow (relatively speaking) at reading and sending very small packets.  The situation on a platform like Linux is quite different.  It's very tragic.

EJ

A good place to start looking when things seem "very slow (relatively
speaking) at reading and sending very small packets", regardless of
the OS in question, is the Nagle algorithm, and its relative in code,
setsockopt(... TCP_NODELAY...). Supported on VMS and elsewhere. See
also TCP_NODELACK. This isn't the place for a lesson in the tradeoffs
between bandwidth and latency and efficiency, but these things are
reasonably well documented although not always as well known as they
should be. Anyway until those things have been set appropriately, it's
not really appropriate to criticise any given implementation.
.