From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751802AbcHQJXe (ORCPT ); Wed, 17 Aug 2016 05:23:34 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:40426 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750919AbcHQJXd (ORCPT ); Wed, 17 Aug 2016 05:23:33 -0400 Date: Wed, 17 Aug 2016 11:23:26 +0200 From: rcochran@linutronix.de To: Jouni Malinen Cc: Richard Cochran , Jouni Malinen , Thomas Gleixner , Rik van Riel , Len Brown , Peter Zijlstra , Frederic Weisbecker , LKML , George Spelvin , Josh Triplett , Chris Mason , Eric Dumazet , rt@linutronix.de, Paul McKenney , Ingo Molnar , Arjan van de Ven Subject: Re: [PREEMPT-RT] [patch 4 14/22] timer: Switch to a non cascading wheel Message-ID: <20160817092326.GB27858@linutronix.de> References: <20160704093956.299369787@linutronix.de> <20160704094342.108621834@linutronix.de> <20160811202544.GA20512@linutronix.de> <20160816094600.GC23077@localhost.localdomain> <20160817090522.GA4284@w1.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160817090522.GA4284@w1.fi> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 17, 2016 at 12:05:22PM +0300, Jouni Malinen wrote: > I had not realized this previously due to the test case passing, but the > same retransmit SYN case was happening with older kernels, it just was > done a tiny bit faster to escape that 1.0 second timeout limit.. That > about 1.03 sec value after this kernel commit is 1.0 sec before this > kernel commit. In other words, something in this specific kernel commit > seems to add about 0.03 sec delay to the TCP SYN retransmission. Yes, and this 3% increase in the timeout expiration interval is an expected result using the new timer wheel. See the large comment at the top of kernel/time/timer.c and the lkml discussion about this series. > That > said, I realize that this is quite unlikely timeout to use for connect() > in real world and as such, it looks simply as a side effect of a test > case that was using way too close timing requirement in the first place. Right, and user space should not rely on the exact timing of TCP SYN re-transmission! Thanks, Richard