Date: Mon, 17 Feb 2003 13:02:55 -0600 (CST) From: Jonathan Lemon <jlemon@flugsvamp.com> To: current@freebsd.org, tlambert2@mindspring.com Subject: Re: Polygraph Considered Evil 8^) (was: Re: 5-STABLE Roadmap) Message-ID: <200302171902.h1HJ2tnm040767@mail.flugsvamp.com> In-Reply-To: <local.mail.freebsd-current/3E511E7A.8225ABA9@mindspring.com> References: <local.mail.freebsd-current/20030216184257.GZ10767@garage.freebsd.pl> <local.mail.freebsd-current/3E4FFDD3.9050802@btc.adaptec.com> <local.mail.freebsd-current/20030216214322.GB10767@garage.freebsd.pl> <local.mail.freebsd-current/Pine.BSF.4.53.0302162130370.46493@measurement-factory.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-current/3E511E7A.8225ABA9@mindspring.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302171902.h1HJ2tnm040767>