Date: Wed, 12 Apr 2006 21:07:00 -0300 From: Patrick Tracanelli <eksffa@freebsdbrasil.com.br> To: AT Matik <asstec@matik.com.br> Cc: freebsd-ipfw@freebsd.org Subject: Re: Load-balancing Message-ID: <443D9624.4010407@freebsdbrasil.com.br> In-Reply-To: <200604121942.25737.asstec@matik.com.br> References: <20060411092932.42148fd8@giboia> <20060412214619.GT9364@elvis.mu.org> <443D7B71.5070004@freebsdbrasil.com.br> <200604121942.25737.asstec@matik.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
AT Matik wrote: > On Wednesday 12 April 2006 19:13, Patrick Tracanelli wrote: > >>Also, what about some sort of algorith more similar to "plr" for "prob" >>action? As my understanding prob is really a probability, which does not >>mean say 33% of the packets will match (while plr says it will match - >>and drop the packet), it means 33% of probability, right? This would be >>different of 33% of matching rate. Lets think of a "rate" option for >>"matching rate", a >> > > > "probably" not a good choice to generate packet-loss when trying kind of load > balance > > prob generates random rate (fwd in this case) > plr generates random packet _loss_ rate > > I think the latter option create artificial kind of bw limit > > Joćo Tt is certainly the deal, according to the code as I mentioned in the later message. This is why a "rate" option would do this job better than prob which make use of random(). Anyway according to my tests this random() approach gets very close to a percentage. From more elaborated to simple tests such as: # ipfw add 1 prob 0.33 deny icmp from me to any out icmptypes 8 # ping 10.69.69.1 [.. and there ping(1) goes...] --- 10.69.69.1 ping statistics --- 28 packets transmitted, 18 packets received, 35% packet loss round-trip min/avg/max/stddev = 0.229/0.280/0.359/0.036 ms One can easily find out we get really close to the desired behaviour, except that the order it happens is really random (which means that with a small amount of tests, say, fewer packets, one might have distorted results). So I believe the lack of a "fwd keep-state"-like behavior is more significant than the rate-with-precision stuff, when the matter is balancing... -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?443D9624.4010407>