Hi, For what it's worth, I can see some scenarios benefiting from more immediate delivery, specially if this increases total throughput for some scenarios.
So IMHO it would be nice to have the knob to tweak this setting, at least I would appreciate it since I have been tuning some services that might very well benefit from it. If added, as you said Nikos, the default should by all means be to have Nagle enabled. Damián Viano. On Thu, Oct 15, 2009 at 11:38:34AM +0300, Nikos Balkanas wrote: > Hi, > > Thanks for a very thorough job. It seems that you are experiencing better > throughput with Nagle enabled. It is a good thing to have Nagle enabled > in a highly congested network. Like most production kannel installation. > On the other hand, if you have plenty of bandwith to spare and you want > immediate delivery you might want to disable it. But who is hoing to > guarantee that downstream connections (SMSCs etc.) will not use Nagle as > well? In fact most likely they will. > > The very nature of SMS is not immediate delivery. This is not reflected > in tcpdumps from your own server. I think that Nagle is a good overall > choice. I believe that you have reached the same conclusion in your case. > If you consider actual SMS delivery, then the whole issue becomes > academic. > > BR, > Nikos > ----- Original Message ----- From: "Michael Zervakis" > <mich...@zervakis.com> > To: <devel@kannel.org> > Sent: Wednesday, October 14, 2009 5:37 PM > Subject: RE: RE: Disable Nagle (enable TCP_NODELAY) ? > > > > I finally did a comparison test for Nagle using SMPP. For the test I > used a real SMSC with SMPP interface that was accessible through a VPN > connection over WAN which represents a common real world case. The SMSC > had a throttling limit at 80sms/sec triggered every 10 seconds. I built > two versions of Kannel cvs_20090921, one umodified and another one with > Nagle disabled and I connected both of them to the same SMSC. The test > included the submission of 2000 MTs each containing a 100 character > payload with sequential submission (2000 MT to first bearerbox, wait to > finish, 2000MT to second bearerbox, wait to finish). The test was > repeated 10 times in a time span of eight hours. During the whole > process I used tcpdump to calculate the seconds it took for each > bearerbox to send the 2000MT pack. The results are presented in the > table below (first column Nagle enabled, second column Nagle disabled). > The bearerbox configuration for both versions and the patch to disable > Nagle are also included. The dumps are not included but I can send them > if anyone is interested. > > TEST # |DEFAULT |NAGLE DISABLED > __________________________________ > 1 |37 |26 > 2 |34 |28 > 3 |43 |24 > 4 |30 |25 > 5 |28 |23 > 6 |35 |24 > 7 |34 |18 > 8 |34 |29 > 9 |39 |33 > 10 |32 |30 > ___________________________________ > AVERAGE |34,6 |26 > ___________________________________ > STDEV |4,32 |4,22 [snip config and patch]
