From owner-freebsd-current Mon Feb 17 11: 3: 0 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4A3637B405 for ; Mon, 17 Feb 2003 11:02:57 -0800 (PST) Received: from mail.flugsvamp.com (ts46-01-qdr3643.mdfrd.or.charter.com [68.118.36.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 886FA43FEA for ; Mon, 17 Feb 2003 11:02:42 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by mail.flugsvamp.com (8.12.6/8.12.6) id h1HJ2tnm040767; Mon, 17 Feb 2003 13:02:55 -0600 (CST) (envelope-from jlemon) Date: Mon, 17 Feb 2003 13:02:55 -0600 (CST) From: Jonathan Lemon Message-Id: <200302171902.h1HJ2tnm040767@mail.flugsvamp.com> To: current@freebsd.org, tlambert2@mindspring.com Subject: Re: Polygraph Considered Evil 8^) (was: Re: 5-STABLE Roadmap) X-Newsgroups: local.mail.freebsd-current In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article you write: >Alex Rousskov wrote: >One issue I have with Polygraph is that it intentionally works >for a very long time to get worst case performance out of caches; >basically, it cache-busts on purpose. Then the test runs. This >seems to be an editorial comment on end-to-end guarantees, much >more than it seems a valid measurement of actual cache performance. This is a realistic scenario; in the real-world, caches never start empty, but are constantly full. However, polygraph numbers are biased towards misses, and don't quite reflect real-world traffic. >> > net.inet.tcp.msl=3000 > >And this seems designed to get a bad one. You are aware that, by >default, NT systems cheat on the MSL, right? For gigabit, this is >a larger number than you want, I think. Polygraph checks the MSL of the target system and complains if it is < 3sec (TCP spec violation). Also, the tuning above is for the polygraph *client* machine, not the cache machine under test. >> One of our kernel patches optimizes handling of 1000s of IP aliases >> per FreeBSD box. The patch is required for older 4.x kernels to >> perform at decent levels. IIRC, the patch does not work for recent >> kernels, probably because of the SYN cache changes. I do not know >> whether any alias-related optimizations are still needed for recent >> kernels though. Perhaps the SYN cache solves the original scalability >> problem. > >The hash is a reasonable modification; it'd probably be better handled >through the routing code, since it has to be hashed there anyway, if >you planned on using a lot of IP aliases. This patch is not needed any longer. A hash table lookup to handle large # of IP aliases was added circa 4.4R. >I haven't looked at the client code, but you are aware that adding >IP aliases doesn't really do anything, unless you managed your >port space your self, manually, with a couple of clever tricks? In >other words, you are going to be limited to your total number of >outbound connections as your ports space (e.g. ~40K), because the >port autoallocation takes place in the same space as the INADDR_ANY >space? I guess this doesn't matter, if your maxopenfiles is only 16K, >since that's going to end up bounding you well before you run out of >ports... The goal here is to stress the neighbor/route code on the cache machine, this is done by generating packets from many different source IP addresses. >I don't think that anything you do in this regard is going to be able >to give you iMimic or NetApp level numbers, which are created by >professional benchmark-wranglers, so any comparison values you get >will liekly be poor, compared to commercial offerings. You're not going to get commercial quality numbers with squid. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message