From owner-freebsd-current@FreeBSD.ORG Sun Sep 25 09:48:32 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 CC056106566B; Sun, 25 Sep 2011 09:48:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7BDC98FC15; Sun, 25 Sep 2011 09:48:32 +0000 (UTC) Received: by gyf2 with SMTP id 2so4476163gyf.13 for ; Sun, 25 Sep 2011 02:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xZDu71kUTBctfkE+m2gJQRj78/IC54s3X21OaOfwYWU=; b=CShiOawr6B0Txmz6jWJRrSswYqxBRhjDVZqN5MmW45qbYjKyG/ccgoI6FS746INj8R kVClOKJyKdPkW9xNizdItMOjKuMJoT2tLZZcn5t3t3ICQ+sCgzg2TO8YE+iud59mNuFr zTB42PplVVe99ailjCFaFmJCAbee4xLcMFonw= MIME-Version: 1.0 Received: by 10.236.129.242 with SMTP id h78mr32267343yhi.89.1316944111783; Sun, 25 Sep 2011 02:48:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Sun, 25 Sep 2011 02:48:31 -0700 (PDT) In-Reply-To: <4E7D6700.4080302@FreeBSD.org> References: <4E7CFC42.8000409@FreeBSD.org> <4E7D6700.4080302@FreeBSD.org> Date: Sun, 25 Sep 2011 17:48:31 +0800 X-Google-Sender-Auth: RDdRsIJcTO7PHvo_QXJ2sGZOIiM Message-ID: From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 25 Sep 2011 09:48:32 -0000 On 24 September 2011 13:13, Alexander Motin wrote: > 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. What about possible effects on the scheduler? Is it possible that once the interrupt handler has completed, the taskqueue thread isn't scheduled immediately, and isn't scheduled until the next tick? >>> 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. > 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. Nope, it has the opposite effect: * Increased latency may make aggregation better (for TX) but it limits throughput because TCP senses a latency increase; * Increased latency means that RX overflows occur beacuse the rx thread doesn't get queued until quite a bit later in the future. > 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. Ok. The most obvious issues occur on embedded mips boards, so I'll have to do some tinkering to get this to work. Adrian