Hi everyone,
We noticed CWND is growing much slower than expected during congestion
avoidance with new reno, and we came to this piece of code in
cc_ack_received() at tcp_input.c:353
if (type == CC_ACK) {
if (tp->snd_cwnd > tp->snd_ssthresh) {
tp->t_bytes_acked += min(tp-
Writing a new netgraph node is relatively simple. Take ng_sample.c and
ng_sample.h and copy them.
Change names to suit, and add your own code in the middle. use one of 50
other nodes as examples.
No matter what you want to do one of them already does it.
--
+--\
> On Tue, Aug 18, 2020 at 2:43 PM Eugene Grosbein 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 b
On Tue, 18 Aug 2020 18:04:24 -0400
Ryan Stone wrote:
> On Tue, Aug 18, 2020 at 5:43 PM Marko Zec wrote:
> > 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 BE
On Tue, Aug 18, 2020 at 5:43 PM Marko Zec wrote:
> 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 an
On Tue, 18 Aug 2020 17:01:37 -0400
Ryan Stone wrote:
...
> On Tue, Aug 18, 2020 at 2:56 PM Marko Zec 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) ^
On Tue, Aug 18, 2020 at 2:43 PM Eugene Grosbein 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 ignora
18.08.2020, 09:17, "Grzegorz Junka" :
> On 18/08/2020 07:54, Julian Elischer wrote:
>> The reason for the two behaviours is that there are two ways that the
>> previous behaviour of "add addresses to the only FIB" could be
>> interpreted and extended once multiple fibs became available. The
>>
___
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"
On Tue, 18 Aug 2020 13:17:48 -0400
Ryan Stone wrote:
> 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
19.08.2020 0:17, Ryan Stone wrote:
> where dummynet wasn't possible
Sorry, missed that. But why wasn't possible?
If you could use ng_pipe, you could probably use ng_ipfw too,
or maybe create small node ng_dummynet to connect NETGRAPH network
with kernel-side dummynet directly.
19.08.2020 0:17, Ryan Stone wrote:
> 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.
> 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 intui
On Tue, Aug 18, 2020 at 1:17 PM Ryan Stone wrote:
> 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.
I've gone back and checked, and
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
2. The
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247912
--- Comment #2 from Martin Birgmeier ---
Hi Li,
Since you want it "before and after the creation of bridge0", the following is
from the host; but the issue actually occurs on the client - I'll provide the
output for that, too.
Host before
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #7 from Vincenzo Maffione ---
(In reply to Kubilay Kocak from comment #6)
I would say
ix/ixl and/or NIC driver & iflib
because it's not something related to the netmap module itself, and it is an
optimization which derives fro
On 18/08/2020 07:54, Julian Elischer wrote:
The reason for the two behaviours is that there are two ways that the
previous behaviour of "add addresses to the only FIB" could be
interpreted and extended once multiple fibs became available. The
single fib case could be interpreted as either of:
The reason for the two behaviours is that there are two ways that the
previous behaviour of "add addresses to the only FIB" could be
interpreted and extended once multiple fibs became available. The
single fib case could be interpreted as either of:
"Add to All N fibs where N == 1" or
19 matches
Mail list logo
