Date: Tue, 18 Aug 2020 23:44:16 +0200 From: Marko Zec <zec@fer.hr> To: Ryan Stone <rysto32@gmail.com> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: Is anybody using ng_pipe? Message-ID: <20200818234416.5aec459c@x23> In-Reply-To: <CAFMmRNyGu-vUgCsDjjDmX9YcEAhCDD-tZHeFJzRtaCOx-bCrgw@mail.gmail.com> References: <CAFMmRNxgoSNX2%2BLd=eEXRH0q7-XFzSF=b2GPzZgNW1LDCvq5Xw@mail.gmail.com> <CAFMmRNwAQ-x2p1CGnzyEuDREtuwS8w4SiQCqwNoKKNWxREQ_cQ@mail.gmail.com> <20200818205725.2e03c8cb@x23> <CAFMmRNyGu-vUgCsDjjDmX9YcEAhCDD-tZHeFJzRtaCOx-bCrgw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 18 Aug 2020 17:01:37 -0400 Ryan Stone <rysto32@gmail.com> wrote: ... > On Tue, Aug 18, 2020 at 2:56 PM Marko Zec <zec@fer.hr> wrote: > > The probability that a frame is completely unaffected by BER events, > > and thus shouldn't be dropped, is currently computed as > > > > Ppass(BER, plen) = Psingle_bit_unaffected(BER) ^ Nbits(plen) > > The problem is in its calculation of Psingle_bit_unaffected(BER). The > BER is the fraction of bits that are affected, therefore it is the > probability that a bit is affected. But for some reason, > Psingle_bit_unaffected(BER) is calculated as 1 - 1/BER rather than 1 - > BER. Since in ng_pipe we define BER as an one error in BER bits (integer value), wouldn't your formula P = 1 - BER yield results less than or equal to zero for all non-zero values of BER? The domain of P is [0..1], so that won't fly. Your analysis seems to be based on an assumption that the BER parameter is given as a multiplier to 0.5**48, which it is not. The proper fix would be to clarify the current BER parameter semantics in ng_pipe(4), not to break bridges with the existing scripts / software which rely on ng_pipe. Cheers, Marko > This leads to the probability table being wrong. For example, > given a BER of 23500000, the probability that a 1500-byte packet is > not dropped is: > > (1 - 23500000/2**48)**(1500 * 8), which is approximately 99.00%. > > However, ng_pipe calculates a fixed-point probability value of > 281460603879001. To calculate whether a frame should be dropped, > ng_pipe takes this probability value and shifts it right by 17, > yielding 2147373991. It then calls rand() to generate a random number > in the range [0,2**31-1]; if the random number is larger than the > probability value than it is dropped, otherwise it is kept. The > chances that a packet is kept is therefore 2147373991/(2**31 - 1), or > about 99.99%. > > It's easy enough to fix this one, but I wasn't sure that it would be > so easy to fix the TSO/LRO issue without significantly increasing the > memory usage, so I wanted to gauge whether it was worth pursuing that > avenue or if a simpler model would be a better use of my time. The > feedback is definitely that a simpler model is *not* warranted, so > let's talk about fixing TSO/LRO. > > On Tue, Aug 18, 2020 at 1:47 PM Rodney W. Grimes > <freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > Hum, that sounds like a poor implementation indeed. It seems > > like it would be easy to convert a BER into a packet drop > > probability based on bytes that have passed through the pipe. > > I'm not quite following you; can you elaborate? Would this solution > require us to update some shared state between each packet? One > advantage of the current approach is that there is no mutable state > (except, of course, when configuration changes).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200818234416.5aec459c>