> On 22 Jun 2025, at 4:39 PM, Thor Lancelot Simon wrote:
>
> On Sun, Jun 22, 2025 at 03:52:30PM +, Emmanuel Nyarko wrote:
>>
>>
>>> On 22 Jun 2025, at 2:54???PM, Thor Lancelot Simon wrote:
>>>
>>> On Sat, Jun 21, 2025 at 03:19:14PM +0100, David Brownlee wrote:
If there reall
> On 21 Jun 2025, at 2:19 PM, David Brownlee wrote:
>
> On Thu, 19 Jun 2025 at 01:25, Emmanuel Nyarko wrote:
>>
>>> On 18 Jun 2025, at 6:54 PM, Emmanuel Dreyfus wrote:
>>>
>>> On Wed, Jun 18, 2025 at 03:11:30PM +, Emmanuel Nyarko wrote:
1. Remove all the existing disciplines (open
On Sun, Jun 22, 2025 at 03:52:30PM +, Emmanuel Nyarko wrote:
>
>
> > On 22 Jun 2025, at 2:54???PM, Thor Lancelot Simon wrote:
> >
> > On Sat, Jun 21, 2025 at 03:19:14PM +0100, David Brownlee wrote:
> >>
> >> If there really no useful setups which fq-codel could replace?
> >> Including "I n
Thor Lancelot Simon writes:
> I think the *ability* to have more than one queueing discipline is important.
Agreed; it's critical to allow improvements and to allow NetBSD to be
useful as a research platform.
> Whether all (or most!) of the disciplines we already have should remain,
> though, i
> On 22 Jun 2025, at 2:54 PM, Thor Lancelot Simon wrote:
>
> On Sat, Jun 21, 2025 at 03:19:14PM +0100, David Brownlee wrote:
>>
>> If there really no useful setups which fq-codel could replace?
>> Including "I need to simulate packet loss and odd bandwidth behaviour
>> to stress my other syst
On Sat, Jun 21, 2025 at 03:19:14PM +0100, David Brownlee wrote:
>
> If there really no useful setups which fq-codel could replace?
> Including "I need to simulate packet loss and odd bandwidth behaviour
> to stress my other systems"?
I use 'tc' at work to simulate WAN conditions when testing a nu
On Thu, 19 Jun 2025 at 01:25, Emmanuel Nyarko wrote:
>
> > On 18 Jun 2025, at 6:54 PM, Emmanuel Dreyfus wrote:
> >
> > On Wed, Jun 18, 2025 at 03:11:30PM +, Emmanuel Nyarko wrote:
> >> 1. Remove all the existing disciplines (openBSD has taken this step
> >> already)
> >
> > That will break t
At Wed, 18 Jun 2025 15:11:30 +, Emmanuel Nyarko
wrote:
Subject: ALTQ modifications proposal
>
> The previous disciplines are not well maintained and adding
> another discipline makes it worse(maintainability).
I haven't actually touched any of this code (just used it) so I have
questions. :
On Thu, Jun 19, 2025 at 12:25:29AM +, Emmanuel Nyarko wrote:
> sadly, that doesn?t look possible. Fq-codel is just three params(IRC) and the
> rest are a lot for a single queue.
That sounds like a good reason to keep existing disciplines.
--
Emmanuel Dreyfus
m...@netbsd.org
On Thu, 19 Jun 2025, Emmanuel Nyarko wrote:
so i just want to have just codel. no #ifdef blocks, just either
simple have it in base during boot, or modload it when you need it.
Thr #if blocks should be replaced with module_hook()s. That way we
make a run-time decision on whether ALTQ is avail
> On 18 Jun 2025, at 7:22 PM, Paul Goyette wrote:
>
> On Wed, 18 Jun 2025, Emmanuel Nyarko wrote:
>
>> Hi all,
>>
>> I have already spoken to a few developers about this and now want to make
>> everyone aware.
>>
>> The current state of ALTQ:
>> ALTQ code is very large with so maany queuei
On Wed, 18 Jun 2025, Emmanuel Nyarko wrote:
Hi all,
I have already spoken to a few developers about this and now want to make
everyone aware.
The current state of ALTQ:
ALTQ code is very large with so maany queueing disciplines.
The state of the art per my research is Fair Queuing CoDel FQ-C
On Wed, Jun 18, 2025 at 03:11:30PM +, Emmanuel Nyarko wrote:
> 1. Remove all the existing disciplines (openBSD has taken this step already)
That will break the setups of long-time users.
But if fq-codel is able to replace all existing disciplines, perhaps
you could keep the existing configur
13 matches
Mail list logo
