From: Eric Dumazet <eric.dumazet@gmail.com>
To: Denys Fedoryshchenko <denys@visp.net.lb>
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
jesse.brandeburg@intel.com, davem@davemloft.net,
therbert@google.com
Subject: Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
Date: Sun, 20 May 2012 20:13:58 +0200 [thread overview]
Message-ID: <1337537638.24892.6.camel@edumazet-glaptop> (raw)
In-Reply-To: <d3a88d6c741394a48aee6179d58e4edf@visp.net.lb>
On Fri, 2012-05-18 at 17:04 +0300, Denys Fedoryshchenko wrote:
> It seems logic in BQL has serious issues. The most bad thing, if
> and it is empty. So in result, instead of eliminating latency, it is
> adding it.
There is maybe a misunderstanding here. BQL by itself only reduce amount
of buffering in TX ring. Now there's still the Qdisc layer.
On my laptop (e1000e NIC), and default pfifo_fast I can immediately see
the difference in ping results if I launch a single netperf TCP_STREAM
in another window :
1480 bytes from 172.30.42.1: icmp_seq=5047 ttl=64 time=0.185 ms
1480 bytes from 172.30.42.1: icmp_seq=5048 ttl=64 time=0.198 ms
1480 bytes from 172.30.42.1: icmp_seq=5049 ttl=64 time=0.255 ms
1480 bytes from 172.30.42.1: icmp_seq=5050 ttl=64 time=0.182 ms
1480 bytes from 172.30.42.1: icmp_seq=5051 ttl=64 time=0.182 ms
1480 bytes from 172.30.42.1: icmp_seq=5052 ttl=64 time=0.226 ms
1480 bytes from 172.30.42.1: icmp_seq=5053 ttl=64 time=0.186 ms
1480 bytes from 172.30.42.1: icmp_seq=5054 ttl=64 time=0.190 ms
1480 bytes from 172.30.42.1: icmp_seq=5055 ttl=64 time=0.223 ms
1480 bytes from 172.30.42.1: icmp_seq=5056 ttl=64 time=0.178 ms
1480 bytes from 172.30.42.1: icmp_seq=5057 ttl=64 time=0.191 ms
1480 bytes from 172.30.42.1: icmp_seq=5058 ttl=64 time=0.229 ms
1480 bytes from 172.30.42.1: icmp_seq=5059 ttl=64 time=0.229 ms
1480 bytes from 172.30.42.1: icmp_seq=5060 ttl=64 time=0.213 ms
1480 bytes from 172.30.42.1: icmp_seq=5061 ttl=64 time=0.187 ms
1480 bytes from 172.30.42.1: icmp_seq=5062 ttl=64 time=0.944 ms
1480 bytes from 172.30.42.1: icmp_seq=5063 ttl=64 time=4.67 ms
1480 bytes from 172.30.42.1: icmp_seq=5064 ttl=64 time=8.55 ms
1480 bytes from 172.30.42.1: icmp_seq=5065 ttl=64 time=12.8 ms
1480 bytes from 172.30.42.1: icmp_seq=5066 ttl=64 time=16.9 ms
1480 bytes from 172.30.42.1: icmp_seq=5067 ttl=64 time=20.5 ms
1480 bytes from 172.30.42.1: icmp_seq=5068 ttl=64 time=24.3 ms
1480 bytes from 172.30.42.1: icmp_seq=5069 ttl=64 time=27.0 ms
1480 bytes from 172.30.42.1: icmp_seq=5070 ttl=64 time=26.8 ms
1480 bytes from 172.30.42.1: icmp_seq=5071 ttl=64 time=26.7 ms
1480 bytes from 172.30.42.1: icmp_seq=5072 ttl=64 time=26.0 ms
1480 bytes from 172.30.42.1: icmp_seq=5073 ttl=64 time=27.0 ms
1480 bytes from 172.30.42.1: icmp_seq=5074 ttl=64 time=25.6 ms
1480 bytes from 172.30.42.1: icmp_seq=5075 ttl=64 time=26.7 ms
1480 bytes from 172.30.42.1: icmp_seq=5076 ttl=64 time=26.9 ms
1480 bytes from 172.30.42.1: icmp_seq=5077 ttl=64 time=25.0 ms
Now if I replace pfifo_fast by fq_codel : (still TSO and GSO are on)
1480 bytes from 172.30.42.1: icmp_seq=37 ttl=64 time=0.197 ms
1480 bytes from 172.30.42.1: icmp_seq=38 ttl=64 time=0.283 ms
1480 bytes from 172.30.42.1: icmp_seq=39 ttl=64 time=0.183 ms
1480 bytes from 172.30.42.1: icmp_seq=40 ttl=64 time=0.182 ms
1480 bytes from 172.30.42.1: icmp_seq=41 ttl=64 time=0.207 ms
1480 bytes from 172.30.42.1: icmp_seq=42 ttl=64 time=0.202 ms
1480 bytes from 172.30.42.1: icmp_seq=43 ttl=64 time=0.244 ms
1480 bytes from 172.30.42.1: icmp_seq=44 ttl=64 time=0.200 ms
1480 bytes from 172.30.42.1: icmp_seq=45 ttl=64 time=0.212 ms
1480 bytes from 172.30.42.1: icmp_seq=46 ttl=64 time=0.215 ms
1480 bytes from 172.30.42.1: icmp_seq=47 ttl=64 time=0.178 ms
1480 bytes from 172.30.42.1: icmp_seq=48 ttl=64 time=0.215 ms
1480 bytes from 172.30.42.1: icmp_seq=49 ttl=64 time=0.238 ms
1480 bytes from 172.30.42.1: icmp_seq=50 ttl=64 time=0.210 ms
1480 bytes from 172.30.42.1: icmp_seq=51 ttl=64 time=0.974 ms
1480 bytes from 172.30.42.1: icmp_seq=52 ttl=64 time=1.93 ms
1480 bytes from 172.30.42.1: icmp_seq=53 ttl=64 time=1.71 ms
1480 bytes from 172.30.42.1: icmp_seq=54 ttl=64 time=3.07 ms
1480 bytes from 172.30.42.1: icmp_seq=55 ttl=64 time=3.47 ms
1480 bytes from 172.30.42.1: icmp_seq=56 ttl=64 time=2.53 ms
1480 bytes from 172.30.42.1: icmp_seq=57 ttl=64 time=3.24 ms
1480 bytes from 172.30.42.1: icmp_seq=58 ttl=64 time=3.11 ms
1480 bytes from 172.30.42.1: icmp_seq=59 ttl=64 time=3.03 ms
1480 bytes from 172.30.42.1: icmp_seq=60 ttl=64 time=2.96 ms
1480 bytes from 172.30.42.1: icmp_seq=61 ttl=64 time=2.90 ms
1480 bytes from 172.30.42.1: icmp_seq=62 ttl=64 time=2.97 ms
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
prev parent reply other threads:[~2012-05-20 18:13 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-15 14:15 Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e Denys Fedoryshchenko
2012-05-17 13:42 ` Denys Fedoryshchenko
2012-05-17 16:54 ` Denys Fedoryshchenko
2012-05-18 14:04 ` Denys Fedoryshchenko
2012-05-19 2:07 ` Tom Herbert
2012-05-19 2:29 ` Denys Fedoryshchenko
2012-05-19 2:40 ` Denys Fedoryshchenko
2012-05-20 17:40 ` Tom Herbert
2012-05-20 18:53 ` Denys Fedoryshchenko
2012-05-20 19:07 ` Eric Dumazet
2012-05-20 19:18 ` Denys Fedoryshchenko
2012-05-21 3:56 ` Eric Dumazet
2012-05-21 8:06 ` Denys Fedoryshchenko
2012-05-21 8:30 ` Eric Dumazet
2012-05-21 8:40 ` Eric Dumazet
2012-05-21 9:22 ` Denys Fedoryshchenko
2012-05-22 17:11 ` Denys Fedoryshchenko
2012-05-22 17:24 ` Eric Dumazet
2012-05-25 6:01 ` Tom Herbert
2012-05-25 6:22 ` Eric Dumazet
2012-05-25 16:59 ` Tom Herbert
2012-05-25 17:18 ` Eric Dumazet
2012-05-29 14:25 ` Hiroaki SHIMODA
2012-05-29 14:54 ` Tom Herbert
2012-05-29 15:11 ` Eric Dumazet
2012-05-29 19:52 ` Denys Fedoryshchenko
2012-05-30 0:06 ` Hiroaki SHIMODA
2012-05-30 8:40 ` Eric Dumazet
2012-05-30 10:43 ` Hiroaki SHIMODA
2012-05-30 11:08 ` Eric Dumazet
2012-05-30 11:20 ` Joe Perches
2012-05-30 11:59 ` Eric Dumazet
2012-05-30 14:09 ` Joe Perches
2012-05-30 14:42 ` Eric Dumazet
2012-05-30 14:50 ` Joe Perches
2012-05-30 11:29 ` Hiroaki SHIMODA
2012-05-30 14:49 ` Eric Dumazet
2012-05-30 15:00 ` dave taht
2012-05-30 22:19 ` Hiroaki SHIMODA
2012-05-30 10:52 ` David Laight
2012-05-30 11:04 ` Eric Dumazet
2012-05-30 11:12 ` Eric Dumazet
2012-06-06 5:10 ` Eric Dumazet
2012-06-06 8:43 ` Hiroaki SHIMODA
2012-06-06 16:26 ` Jesse Brandeburg
2012-06-06 17:05 ` Eric Dumazet
2012-06-06 17:26 ` David Miller
2012-06-06 17:19 ` Hiroaki SHIMODA
2012-06-06 18:21 ` Tom Herbert
2012-06-06 18:23 ` David Miller
2012-06-06 18:46 ` Stephen Hemminger
2012-05-20 18:13 ` Eric Dumazet [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1337537638.24892.6.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=denys@visp.net.lb \
--cc=e1000-devel@lists.sourceforge.net \
--cc=jesse.brandeburg@intel.com \
--cc=netdev@vger.kernel.org \
--cc=therbert@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox