* Re: Loopback and Nagle's algorithm [not found] <1302575869.13492.1440076201@webmail.messagingengine.com> @ 2011-04-12 9:42 ` Alejandro Riveira Fernández [not found] ` <BANLkTi=jpdLRc35DkBhLmUr8-P+ggcrgoA@mail.gmail.com> 1 sibling, 0 replies; 2+ messages in thread From: Alejandro Riveira Fernández @ 2011-04-12 9:42 UTC (permalink / raw) To: Adam McLaurin; +Cc: linux-kernel, netdev El Mon, 11 Apr 2011 22:37:49 -0400 "Adam McLaurin" <lkml@irotas.net> escribió: Just CCing netdev > I understand that disabling Nagle's algorithm via TCP_NODELAY will > generally degrade throughput. However, in my scenario (150 byte > messages, sending as fast as possible), the actual throughput penalty > over the network is marginal (maybe 10% at most). > > However, when I disable Nagle's algorithm when connecting over loopback, > the performance hit is *huge* - 10x reduction in throughput. > > The question is, why is disabling Nagle's algorithm on loopback so much > worse w.r.t. throughput? Is there anything I can do to reduce the > incurred throughput penalty? > > Thanks, > Adam > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 2+ messages in thread
[parent not found: <BANLkTi=jpdLRc35DkBhLmUr8-P+ggcrgoA@mail.gmail.com>]
[parent not found: <1302606246.21782.1440195277@webmail.messagingengine.com>]
[parent not found: <alpine.LRH.2.00.1104121354010.6953@twin.jikos.cz>]
* Re: Loopback and Nagle's algorithm [not found] ` <alpine.LRH.2.00.1104121354010.6953@twin.jikos.cz> @ 2011-04-12 13:08 ` Eric Dumazet 0 siblings, 0 replies; 2+ messages in thread From: Eric Dumazet @ 2011-04-12 13:08 UTC (permalink / raw) To: Jiri Kosina; +Cc: Adam McLaurin, Will Newton, linux-kernel, netdev Le mardi 12 avril 2011 à 13:54 +0200, Jiri Kosina a écrit : > On Tue, 12 Apr 2011, Adam McLaurin wrote: > > > > It may be caused by an increase in context switch rate, as both sender > > > and receiver are on the same machine. > > > > I'm not sure that's what's happening, since the box where I'm running > > this test has 8 physical CPU's and 32 cores in total. > > Have you tried firing up the testcase under perf, to see what it reveals > as the bottleneck? > CC netdev This rings a bell here. I suspect we hit mod_timer() / lock_timer_base() because of delack timer constantly changing. I remember raising this point last year : http://kerneltrap.org/mailarchive/linux-netdev/2010/5/20/6277741 David answer : http://kerneltrap.org/mailarchive/linux-netdev/2010/6/2/6278430 I am afraid no change was done... ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-04-12 13:08 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1302575869.13492.1440076201@webmail.messagingengine.com>
2011-04-12 9:42 ` Loopback and Nagle's algorithm Alejandro Riveira Fernández
[not found] ` <BANLkTi=jpdLRc35DkBhLmUr8-P+ggcrgoA@mail.gmail.com>
[not found] ` <1302606246.21782.1440195277@webmail.messagingengine.com>
[not found] ` <alpine.LRH.2.00.1104121354010.6953@twin.jikos.cz>
2011-04-12 13:08 ` Eric Dumazet
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).