From owner-freebsd-current@FreeBSD.ORG Sat Sep 24 05:14:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF4201065672; Sat, 24 Sep 2011 05:14:08 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 184F08FC12; Sat, 24 Sep 2011 05:14:07 +0000 (UTC) Received: by fxg9 with SMTP id 9so5722321fxg.13 for ; Fri, 23 Sep 2011 22:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=ceaBdLOUEN91ZlqkmxVObJQK9QfO57pIZ0ER8SmhAKs=; b=oklUQjOKcAXnj4kJMQwvFvmxwjLzIxfVenqY3l6vciG6EQAs+YFv0K002GmeGvNm1Y W94HSTEUgxSDVfBBR3iTSWXRX70qTSYMH52OD4HkxsXPdnFYumLjNXcLAtpeheoyJw0n D3JUiyPSQXE7Y8VO5Sy1/hybOSRWOzdRcOlqI= Received: by 10.223.40.203 with SMTP id l11mr5974466fae.107.1316841246930; Fri, 23 Sep 2011 22:14:06 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (advisory-appointer.volia.net. [93.73.242.53]) by mx.google.com with ESMTPS id t19sm13401347faj.23.2011.09.23.22.14.05 (version=SSLv3 cipher=OTHER); Fri, 23 Sep 2011 22:14:06 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E7D6700.4080302@FreeBSD.org> Date: Sat, 24 Sep 2011 08:13:36 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: Adrian Chadd References: <4E7CFC42.8000409@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ath / 802.11n performance issues and timer code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 05:14:08 -0000 On 24.09.2011 04:13, Adrian Chadd wrote: > On 24 September 2011 05:38, Alexander Motin wrote: >>> When I set kern.eventtimer.periodic=1, the 11n TX/RX performance >>> suddenly jumps to where it should be. >>> >>> Would you mind helping me figure out what the problem is? >> >> I would be glad to help, but at this moment I am not sure how network >> traffic related to timer. May be wireless has some specifics, but for >> wired adapters traffic processing happens on network interrupts. > > Well, here the interrupt handler just sets up some deferred tasks to > run via taskqueue_schedule(). > This isn't the only driver which does this - I think the gige/10gige > NICs also do this. OK, but how taskqueue related to the timer? Taskqueue uses SWI that are called in separate thread and except "swi4: clock" AFAIR they are not anyhow related to the timer. >>> I didn't think kern.eventtimer.periodic was needed? >> >> It should not be needed. >> >> Have you tried to set kern.eventtimer.idletick=1 instead? > > I just tested it - it has the same effect. Interesting. So either it is what I've described below (but it's strange, I have doubt it may consume so much time, at least I haven't seen it on x86), or network traffic is still somehow depends on timer events and timer events are delayed more then needed. >> kern.eventtimer.periodic=1 on UP system effectively includes >> kern.eventtimer.idletick=1. kern.eventtimer.idletick=0 may somewhat >> increase interrupts overhead due to need to reprogram timer before >> context switch, but under high interrupt rate (about few KHz) kernel >> should dynamically switch to "quick" mode skipping it. > > The clock rate interrupt difference is quite startling - at 150mbit > 11n bridging (from wlan0 -> arge0 wired) the clock interrupt rate is > around 300/sec for idletick=0, and about 1150/sec for idletick=1. The numbers themselves look fine. 1150 int/sec should mean 1000 of hz and 127 of stathz. Lower rate with idletick=0 means that eventtimer subsystem is dropping some timer ticks. > The other thing to keep in mind is that the wlreless NIC isn't > interrupting per RX or TX completed packet. So although I'm doing ~ > 19,000 pps, it's only interrupting me ~ 390 times a second. So low interrupt rate means large queuing, that should make bandwidth even less affected by side influences. Can you try to build kernel with KTR_SPARE2 KTR and send me a trace when the traffic flows. I would like to check whether timer events are generated close to a proper time. -- Alexander Motin