[bug] Performance degradation in TCP.Socket

Issue status update for
http://smalltalk.gnu.org/node/119
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/119

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    Bindings (other)
 Category:     bug reports
 Priority:     normal
 Assigned to:  Unassigned
 Reported by:  elmex
 Updated by:   elmex
 Status:       active

I've encountered a problem with datatransfer with sockets.
When more data than readBuffer or writeBuffer is being
handled in the following smalltalk program a serious
performance degradation occurs:

http://www.ta-sa.org/files/txt/9de8fcc9b170b42440f087db036736a3.txt

I've written a Perl script which measures how many times per second one
can send a specific amount of data to the smalltalk echo server in the
example above.
See:

http://www.ta-sa.org/files/data/echo_performance_test

You will need the AnyEvent module from CPAN and the Event module
probably (maybe also works without).

Here is a sample run with default buffer sizes:

http://www.ta-sa.org/files/txt/a00d8a9d093a8bf8d4acb17ad5a9bf9c.txt

I've discovered that 256 is exactly the writeBuffer size of a
TCP.Socket. Setting that to a higher value increases the performance
for 257 byte packets and bigger packets,
until it hits the readBuffer size, then the performance goes down as
before.

It's maybe some weird interaction between the writer and reader thread,
I don't really know.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/119
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/119

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    Bindings (other)
 Category:     bug reports
 Priority:     normal
 Assigned to:  Unassigned
 Reported by:  elmex
 Updated by:   elmex
 Status:       active

Further investigation has revealed that this might not be a problem
specific to gst. It might be fundamental issue when buffer sizes are
met.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/119
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/119

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    Bindings (other)
-Category:     bug reports
+Category:     feature requests
 Priority:     normal
 Assigned to:  Unassigned
 Reported by:  elmex
 Updated by:   elmex
 Status:       active

Ok, i've tracked down the problem. The same effect occurs
on a perl only implementation. The actual delay of 40ms seemed to be
induced by nagles algorithm for tcp. Setting the socket option
TCP_NODELAY on fixed the problem for the perl only implementation.

So, I changed this to a feature request for setting
the socket option TCP_NODELAY.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/119
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/119

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    Bindings (other)
 Category:     feature requests
 Priority:     normal
-Assigned to:  Unassigned
+Assigned to:  bonzinip
 Reported by:  elmex
 Updated by:   bonzinip
-Status:       active
+Status:       patch
 Attachment:   http://smalltalk.gnu.org/files/issues/gst-tcp-flush-nodelay.patch (3.29 KB)

Can you please try this patch?  I am not sure if it achieves your
objective.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/119
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/119

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    Bindings (other)
 Category:     feature requests
 Priority:     normal
 Assigned to:  bonzinip
 Reported by:  elmex
 Updated by:   elmex
 Status:       patch

The patch enables TCP_NODELAY now for every socket flush as far
as I can see it. Is that intended?

The tcp delay, aka. nagles algorithm has it's applications and
disabling
it should be done only in special applications (eg. where low-latency
for is required) IMO.

So a more optional interface would be better I guess. Something like:

 socket setTCPNoDelay: true/false

would be enough IMO.

"valueWithoutBuffering:" is ok, I guess, as additional feature.

The Socket>>#flush method in that patch does always use
valueWithoutBuffering.
I would probably introduce a new method with a more verbost name
instead,
something like flushWithoutTCPDelay :-)

The patch is ok, I would just make the functionality optional.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/119
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/119

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    Bindings (other)
 Category:     feature requests
 Priority:     normal
 Assigned to:  bonzinip
 Reported by:  elmex
 Updated by:   bonzinip
 Status:       patch

> The Socket>>#flush method in that patch does always use
> valueWithoutBuffering.
> I would probably introduce a new method with a more verbost name
> instead, something like flushWithoutTCPDelay :-)

Yes, an alternative could be a patch that makes #flush not use
TCP_NODELAY, and adds #flushToNetwork which uses it

My reasoning was that when #flush is used, either you *want*
TCP_NODELAY behavior (low latency) or you are not going to write any
data soon to the socket because you're waiting for a reply.  In the
latter case, Nagle's algorithm is not going to be useful and the packet
will be sent anyway (only incurring a delay).

In fact, with the kind of high-level buffering that gst performs on
sockets, Nagle's algorithm may even be completely useless...

Do you agree?




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/119
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/119

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    Bindings (other)
 Category:     feature requests
 Priority:     normal
 Assigned to:  bonzinip
 Reported by:  elmex
 Updated by:   elmex
 Status:       patch

>Yes, an alternative could be a patch that makes #flush not use
> TCP_NODELAY, and adds #flushToNetwork which uses it

Yes, thats sounds ok to me.

> My reasoning was that when #flush is used, either you *want*
> TCP_NODELAY behavior (low latency) or you are not going to write any
> data soon to the socket because you're waiting for a reply.  In the
> latter case, Nagle's algorithm is not going to be useful and the
packet
> will be sent anyway (only incurring a delay).

Hmm, #flush was for me: "flush buffers to the OS", and then don't care
what the OS does with the data. TCP_NODELAY would only tell the OS how
to deal with
data it received from the application.

> In fact, with the kind of high-level buffering that gst performs on
> sockets, Nagle's algorithm may even be completely useless...
>> Do you agree?

Hmm, I guess I agree mostly. I only wonder whether there are cases of
calling

    * flush when it does not mean 'flush down to network'.




My suggestion to make it optional was merely because I'm not sure of
the
impact on everyday socket usage. It's just that TCP_NODELAY is not
enabled
by default for sockets for a good reason.

If you think there is no problem with no-delay-flush by default in gst
and
that it fits into the way gst does socket stuff, then I don't object to
enabling
it by default.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/119
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/119

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    Bindings (other)
 Category:     feature requests
 Priority:     normal
 Assigned to:  bonzinip
 Reported by:  elmex
 Updated by:   bonzinip
-Status:       patch
+Status:       fixed

Thanks for your comments; patch committed.  Could you post updated
values for your benchmark?




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk