Date: Tue, 18 Aug 2020 17:01:37 -0400 From: Ryan Stone <rysto32@gmail.com> To: Marko Zec <zec@fer.hr> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: Is anybody using ng_pipe? Message-ID: <CAFMmRNyGu-vUgCsDjjDmX9YcEAhCDD-tZHeFJzRtaCOx-bCrgw@mail.gmail.com> In-Reply-To: <20200818205725.2e03c8cb@x23> References: <CAFMmRNxgoSNX2%2BLd=eEXRH0q7-XFzSF=b2GPzZgNW1LDCvq5Xw@mail.gmail.com> <CAFMmRNwAQ-x2p1CGnzyEuDREtuwS8w4SiQCqwNoKKNWxREQ_cQ@mail.gmail.com> <20200818205725.2e03c8cb@x23>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 18, 2020 at 2:43 PM Eugene Grosbein <eugen@grosbein.net> wrote: > Sorry, missed that. But why wasn't possible? There's a daemon running on the system that handles most network configuration. It's quite inflexible and will override any manual configuration changes. It manages firewall rules but is ignorant of netgraph, so it will remove any dummynet rules but leave netgraph configuration alone. It was significantly easier to just use ng_pipe, even after having to fix or work around the bugs, than it was to fight the daemon. 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. 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?CAFMmRNyGu-vUgCsDjjDmX9YcEAhCDD-tZHeFJzRtaCOx-bCrgw>