From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D6D5F3B2A3 for ; Tue, 25 Apr 2017 17:06:41 -0400 (EDT) Received: by mail-wr0-x234.google.com with SMTP id z52so74132933wrc.2 for ; Tue, 25 Apr 2017 14:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=PKjiMGy9tSKJ/QObigtWbSKDAClI6a6zYrd8nMdlQU0=; b=h2no+O3PTrEbkwIJ9MvS+jsSgnmQlbkPFKU+pWe7Q/LegjMWZrZjDrk9x/R6hPHz7g n+wkmaGA2ISu1wMEYzNSO5sTBjeeQEKf0jUNiaRMVUc6UIGid78iVhEDFlmuLeMZfYie SozOzE8m44OOs80TGzLqvMkbtFc7waddn3F/R1Xl7iR0T+NKudCz6VPIDgeofdRcsI4B 0l22uX7Tqh/VHOIVVQeo2JEfXE8s+ZtJckKt0uoqR9oJFl0YWB1sOCupJoHSMgr3Lg9S uX3ylVCUi1fTqcv0g2uyiPQjvp81uGqgtAtoYGRtMpMuoAxE2dYVjSuIebmw0JXCSHY2 8tRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=PKjiMGy9tSKJ/QObigtWbSKDAClI6a6zYrd8nMdlQU0=; b=W4AChos2MZteTat8zPQ1SWNl1qtc+TfwbLaOTkfm3qofF6bylOL9Lks0Ht7gPsUopp sS30Pquq1JAMe4YQ11x0183bXw8qh0ZBcdC4EO+muwgTuyLfnC/iIW6xJtSmS8gExBgC T5IvuMO57YY2KNJAYJX1QRwA4T4hF1XDnJ0gGtMMhlobhKSCHp0At3hrzfM/kkuT48lh SrWDwSaM9NuI8ebpUUL/s6R1dctRhwp7mRUyg572Wkv+2ysZGv3t0ogDqLPH5mPJVmj3 BxIkA2TIeg3jk0ywB6j2YQl8sUswx/qFnC4iH6p2559+K89oqFdlWbNz45u/2pJlwPvg vX+A== X-Gm-Message-State: AN3rC/7gvQ5o3NlRz0fQ7oOTGngNMFWq4kPybq2EWD8khDKH2lIDXeTC J/mzoGM9rOfQWA== X-Received: by 10.223.139.92 with SMTP id v28mr3482064wra.177.1493154400889; Tue, 25 Apr 2017 14:06:40 -0700 (PDT) Received: from [192.168.0.3] (185.182.7.51.dyn.plus.net. [51.7.182.185]) by smtp.gmail.com with ESMTPSA id j26sm27517025wrb.19.2017.04.25.14.06.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 14:06:39 -0700 (PDT) To: Jonathan Morton , Dendari Marini Cc: cake@lists.bufferbloat.net References: <22E633CF-5EE0-4B0F-89A8-B790E730FB6C@gmx.de> <0BA3EE91-C5BC-4155-9D5D-D15D34490A1A@gmx.de> <00DDAA0B-7D99-489B-BA2D-1F20289409B3@gmx.de> <2FFBF256-2932-4FC7-AD1F-0D7CEE111809@gmx.de> <3fbfd0ee-7b41-0f83-8b44-ce7eed6a0562@gmail.com> <09DB0D8E-F63C-4126-8608-9EACDE99D2F1@gmail.com> From: Andy Furniss Message-ID: <7ac3ea6a-885c-f7a0-e01f-a824e0656e15@gmail.com> Date: Tue, 25 Apr 2017 22:06:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 SeaMonkey/2.51a2 MIME-Version: 1.0 In-Reply-To: <09DB0D8E-F63C-4126-8608-9EACDE99D2F1@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Cake] Getting Cake to work better with Steam and similar applications X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:06:42 -0000 Jonathan Morton wrote: > >> On 25 Apr, 2017, at 21:22, Dendari Marini >> wrote: >> >> The good news is that using switch0 as inbound and pppoe0 as >> outbound works, and I was able to set up Steam as bulk using the >> interface on the ER-X (used DSCP 8 and used a custom DPI category). >> I confirmed this was working by looking at the bulk traffic >> increasing (using the "tc -s qdisc" command) and by starting >> another download (Steam gets pretty much nothing in this case). >> >> The bad news is this isn't enough to fix my gaming issue (still >> having ping spikes, latency variation and packet loss), and even >> using it with Steam configured to use just one connection didn't >> change much from my previous testing. >> >> So I'm really confused :\ What could cause ping spikes in this >> case (assuming the multiple connections aren't the issue)? > > As noted, it’s far more difficult to control latency from downstream > of a bottleneck link. If a bulk sender decides to send burstily, > those bursts will always collect in the dumb queue at the far end and > delay other traffic. The only true solution is to install a smart > queue at the upstream end - but that’s not under your control. > > You may see some improvement from wholesale reducing the inbound > bandwidth, to say 10Mbit. This is especially true given the high > asymmetry of your connection, which might require dropped acks > upstream to keep filled downstream - and dropped acks will tend to > increase burstiness of sending on unpaced senders. > > You should also try to ensure ECN is fully enabled on your LAN hosts, > especially the ones running Steam. This will help to reduce > retransmissions and loss-recovery cycles. Yea, good idea - hopefully steam servers will honor that. Plus remember what I said about raw - you have an upstream fail case with sacks - also see below. I just looked at a tcpdump I made last night doing a steam d/l, mainly to see if I got servers in the list from the steam link posted, I did. The other stand out thing is there are far more sacks than I would normally expect to see. tcpdump -nnr steam2.pcap src host 192.168.0.224 | grep "sack" | wc -l reading from file steam2.pcap, link-type EN10MB (Ethernet) 28298 tcpdump -nnr steam2.pcap src host 192.168.0.224 | wc -l reading from file steam2.pcap, link-type EN10MB (Ethernet) 44094 incoming count - tcpdump -nnr steam2.pcap dst host 192.168.0.224 | wc -l reading from file steam2.pcap, link-type EN10MB (Ethernet) 59319 That's a crazy amount especially as being in recovery means ack per packet. My connection is quite different from the OPs of course, ptm 66 meg sync with cake at 60mbit for this test and the pcap was only over 12 seconds. The servers are only 8ms away from me, 5 connections. I wonder if they are using bbr or something.