From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 12:16:10 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 905E21065673 for ; Wed, 11 Apr 2012 12:16:10 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id E6B1B8FC12 for ; Wed, 11 Apr 2012 12:16:09 +0000 (UTC) Received: (qmail 49146 invoked from network); 11 Apr 2012 12:12:56 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Apr 2012 12:12:56 -0000 Message-ID: <4F857631.8040309@freebsd.org> Date: Wed, 11 Apr 2012 14:16:49 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Luigi Rizzo References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> <20120410233211.GA53829@onelab2.iet.unipi.it> <4F855E5E.5000107@freebsd.org> <20120411110036.GA60031@onelab2.iet.unipi.it> In-Reply-To: <20120411110036.GA60031@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Barney Wolff , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 12:16:10 -0000 On 11.04.2012 13:00, Luigi Rizzo wrote: > On Wed, Apr 11, 2012 at 12:35:10PM +0200, Andre Oppermann wrote: >> On 11.04.2012 01:32, Luigi Rizzo wrote: >>> On Tue, Apr 10, 2012 at 07:05:00PM -0400, Barney Wolff wrote: >>>> CPU cache? >>>> Cx states? >>>> powerd? >>> >>> powerd is disabled, and i am going down to C1 at most >>> > sysctl -a | grep cx >>> hw.acpi.cpu.cx_lowest: C1 >>> dev.cpu.0.cx_supported: C1/1 C2/80 C3/104 >>> >>> which shouldn't take so much. Sure, cache matters, but the >>> fact is, icmp processing on loopback should occur inline. >>> >>> unless there is a forced descheduling on a select with timeout> 0 >>> which would explain the extra few microseconds (and makes me worry >>> on how expensive is a scheduling decision...) >> >> Things going through loopback go through a NETISR and may >> end up queued to avoid LOR situations. In addition per-cpu >> queues with hash-distribution for affinity may cause your >> packet to be processed by a different core. Hence the additional >> delay. > > so you suggest that the (de)scheduling is costing several microseconds ? Not directly. I'm just trying to explain what's going on to get a better idea where it may go wrong. There may be a poor ISR/scheduler interaction that prevents that causes the packet to be processed only on the next tick or something like that. I don't have a better explanation for this. > Do we have something like yield() to measure how expensive is the > scheduler ? I ran some tests in a distant past and i remember numbers > of a few microseconds, but that was almost two gigahertz ago... -- Andre