On Tue, 18 Aug 2020 17:01:37 -0400 Ryan Stone <ryst...@gmail.com> wrote: ... > On Tue, Aug 18, 2020 at 2:56 PM Marko Zec <z...@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-...@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). _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
