From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 20:08:56 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73B391065670 for ; Fri, 4 Sep 2009 20:08:56 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 0778E8FC08 for ; Fri, 4 Sep 2009 20:08:55 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id DF415730DA; Fri, 4 Sep 2009 21:57:18 +0200 (CEST) Date: Fri, 4 Sep 2009 21:57:18 +0200 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20090904195718.GA69566@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: what clock is used by select()/HZ ? 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: Fri, 04 Sep 2009 20:08:56 -0000 Hi, I am running a kernel (8.0) with HZ=5000 trying to generate packets which are apart from each other by something that is not an exact multiple of 1ms . I have a modified ping version which essentially accepts a microsecond spec, loops around select() and tries to send a packet at precise intervals (taking care not to accumulate errors). running it with ./ping -i 0.050200 some.host and looking at the tcpdump output captured on the same host, i see that packets get out of the system at intervals that (according to the tcpdump timestamps are .050121 (60% of them) or .050322 (40% of them) seconds apart (values are scattered within 10us of each of the two values). Overall the average delta is correct, but individual samples are not. The system reports the following values: kern.timecounter.choice: TSC(-100) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000) kern.timecounter.hardware: HPET kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.HPET.frequency: 25000000 kern.timecounter.tc.ACPI-safe.frequency: 3579545 kern.timecounter.tc.TSC.frequency: 2314976129 kern.timecounter.tick: 5 # (not sure what this means) The only way i can explain the differences in the delays is that the internal value of HZ is slightly different than the correct value (50121/50200 or 50322/50200 times 5000) due to some approximation in the divider used to generate the peridic interrupt, whereas gettimeofday() is reasonably correct and prevents the accumulation of errors. However, HPET (which seems to be the one used) is a multiple of 5000 so the divider should be correct, and i cannot figure out what other clock source could cause, due to a rounding error in the divisor, such a large difference (50121/50200 or 50322/50200) Any ideas ? cheers luigi