Is anybody using ng_pipe?
Marko Zec
zec at fer.hr
Tue Aug 18 21:43:44 UTC 2020
On Tue, 18 Aug 2020 17:01:37 -0400
Ryan Stone <rysto32 at gmail.com> wrote:
...
> On Tue, Aug 18, 2020 at 2:56 PM Marko Zec <zec at 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 at 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).
More information about the freebsd-net
mailing list