From owner-freebsd-doc Mon Aug 26 12:29: 3 2002 Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA5D737B400 for ; Mon, 26 Aug 2002 12:28:58 -0700 (PDT) Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2D9543E72 for ; Mon, 26 Aug 2002 12:28:57 -0700 (PDT) (envelope-from keramida@FreeBSD.ORG) Received: from hades.hell.gr (patr530-b165.otenet.gr [212.205.244.173]) by mailsrv.otenet.gr (8.12.4/8.12.4) with ESMTP id g7QJSqpD003931 for ; Mon, 26 Aug 2002 22:28:54 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.5/8.12.5) with ESMTP id g7QJSrSb032898 for ; Mon, 26 Aug 2002 22:28:56 +0300 (EEST) (envelope-from keramida@FreeBSD.ORG) Received: (from charon@localhost) by hades.hell.gr (8.12.5/8.12.5/Submit) id g7QIiDDB029776; Mon, 26 Aug 2002 21:44:14 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Mon, 26 Aug 2002 21:44:13 +0300 From: Giorgos Keramidas To: Martin Heinen Cc: "Ritz, Bruno" , FreeBSD-doc@FreeBSD.ORG Subject: Re: possible millisecond - microsecond confusion Message-ID: <20020826184413.GF756@hades.hell.gr> References: <20020825125050.A6559@sumuk.de> <20020825140556.GF762@hades.hell.gr> <20020826114506.A8041@sumuk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20020826114506.A8041@sumuk.de> Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2002-08-26 11:45 +0000, Martin Heinen wrote: > On Sun, Aug 25, 2002 at 05:05:57PM +0300, Giorgos Keramidas wrote: > > On 2002-08-25 12:50 +0000, Martin Heinen wrote: > > Actually, it's probably "milliseconds" you want to keep. > > Microseconds seems like a very small amount of time for processing > > a packet. I could be wrong, though. If you want to change it to > > microseconds, you'd also have to update numbers like "370 packets > > per second". > > If we omit the time for processing the rules, the sentences will be > less confusing. These numbers are not used in the following and a > reader may easily calculate them if he really needs them. > > How does this one look? It does remove some of the information. I'm not sure. An explicit mention of the fact that the rule chains of the test had 1000 rules each, is lost by removing this. The original text is not very confusing though, IMHO. The per-packet processing overhead in the former case[1] was approximately 2.703ms/packet, or roughly 2.7 microseconds per rule[2]. [1] The case of the chain with 1000 "slow" deny rules. [2] Since the chain has 1000 rules, and all of them are processed for a single packet, the time needed for the processing of each rule is (packet_time / 1000). I'm not sure I want to change anything here. Thus the theoretical packet processing limit with these rules is around 370 packets per second[1]. [1] Since every packet takes 2.703 milliseconds, there can be at most 1000 / 2.703 packets in each second. This is obviously correct: $ echo 'scale=3;1000/2.703' | bc 369.959 > For the latter case each packet was processed in > - approximately 1.172ms, or roughly 1.2 microseconds per rule. > + approximately 1.172ms. Each packet that is processed with the 'latter case'[2] runs through a list of quickly skipped rules. Now the time it takes to process a packet is different, since each rule takes 1.2 ìsec instead of 2.7 ìsec (which was the case in the former case, of 1000 "slow" rules). [1] The chain that contains mostly fast skip rules. The original text looks fine to me. Not very detailed, but not confusing either. - Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message