Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Aug 2020 10:47:39 -0700 (PDT)
From:      "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>
To:        Ryan Stone <rysto32@gmail.com>
Cc:        freebsd-net <freebsd-net@freebsd.org>
Subject:   Re: Is anybody using ng_pipe?
Message-ID:  <202008181747.07IHldYZ066440@gndrsh.dnsmgr.net>
In-Reply-To: <CAFMmRNxgoSNX2%2BLd=eEXRH0q7-XFzSF=b2GPzZgNW1LDCvq5Xw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> I recently needed to be able to simulate a lossy, high-latency network
> in an environment where dummynet wasn't possible.  I gave ng_pipe a
> try, and hit some major issues
> 
> 1. Instead of configuring a packet drop rate, you configure a bit
> error rate, which I found significantly less intuitive

>From your background being packet network centric perhaps?
Those of us who have line oriented, aka telecom, centric backgrounds
BER is a very meaningful and useful metric.

> 2. The use of BER makes for a very inconvenient implementation, as
> ng_pipe has to maintain a table of packet drop rates for every
> possible packet size

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.

It should be easy to covert a BER into a packet drop rate, but
doing the converse leads to quantization errors.  I would rather
see us keep the BER as the metric and fix what is broken rather
than convert this to a packet drop rate..

> 3. The table implementation isn't sized right for LRO or TSO, leading
> to ng_pipe going out of bounds of the array and panicking the system

Code predates LRO and TSO, so not unexpected.

> 4. The table calculation had two integer truncation bugs and used the
> wrong formula.  I'm reasonably sure it would never calculate a
> probability other than 0 due a 64-bit constant being truncated to
> 32-bits.
You retracted this.

> I'd like to dump all of this and just implement a packet loss rate,
> which would simplify all this immensely.  Is anybody using ng_pipe
> with a non-zero BER who would object to this?  Given this litany of
> issues I doubt it, but I thought that I'd be sure.

My gut instinc is that statistically BER leads to a more realistic model.

-- 
Rod Grimes                                                 rgrimes@freebsd.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202008181747.07IHldYZ066440>