From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail24c25.carrierzone.com (mail225c25.carrierzone.com [64.29.147.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F384B3B2A4 for ; Tue, 21 Nov 2017 14:08:29 -0500 (EST) X-POP-User: hmurray@megapathdsl.net Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mail24c25.carrierzone.com (8.14.9/8.13.1) with ESMTP id vALJ8Ro6032672 for ; Tue, 21 Nov 2017 19:08:28 +0000 Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 5B80540605C; Tue, 21 Nov 2017 11:08:26 -0800 (PST) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 From: Hal Murray To: bloat@lists.bufferbloat.net Cc: Hal Murray Date: Tue, 21 Nov 2017 11:08:26 -0800 Message-Id: <20171121190826.5B80540605C@ip-64-139-1-69.sjc.megapath.net> X-CSC: 0 X-CHA: v=2.2 cv=SPkybKnH c=1 sm=1 tr=0 a=OWgXOY7Tc8w5m7k7nGX6Zw==:117 a=OWgXOY7Tc8w5m7k7nGX6Zw==:17 a=sC3jslCIGhcA:10 a=7VDZQ2-_ZTSdxgl3vt4A:9 X-CTCH-RefID: str=0001.0A010201.5A1479AD.006A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 Subject: Re: [Bloat] Steam In Home Streaming on ath9k wifi X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 19:08:30 -0000 > Right, no idea how Windows drivers behave. But odds are that the bottleneck > is at the client, since that often has worse antennas than the AP. If you're > in a position to take packet captures at both clients and AP you may be able > to figure it out; may require tightly synchronised clocks to do properly, > though. It should be reasonable to synchronize the clocks at both ends well enough. If that doesn't work and/or is inconvient, you could post process one trace to adjust the time stamps. The idea is to scan both traces in parallel to find the minimum transit times in each direction, then adjust the time stamps on one end to allocate half the total time to each direction. It would obviously be handy to have a few pings during a period of low traffic for calibration. ------- There are two dimensions to clocks. One is the current time. The other is the frequency. If the frequency is off, the clock will drift. (ntpd's drift correction is usually stored in someplace like /var/lib/ntp/ntp.drift) Unless you are interested in long runs, the clock will not drift far enough to be a serious problem, so all you have to do is get the time right before starting a run. You might want to kill ntpd on the wifi end so it doesn't get confused and yank the clock around. -- These are my opinions. I hate spam.