Re: pf queues

On 2023-12-01, 4 <babut@yandex.ru> wrote:
>> On 2023-11-30, 4 <babut@yandex.ru> wrote:
>>> we can simply calculate such a basic thing as the flow rate by dividing the number of bytes in the past packets by the time. we can control the speed through delays in sending packets. this is one side of the question. as for the sequence, priorities work here. yes, we will send packets with a higher priority until there are no such packets left in a queue, and then we will send packets from queues with a lower priority. priorities are a sequence, not a share of the total piece of the pie, and we don't need to know anything about the pie.
>
>> But unless you are sending more traffic than the *interface* speed,
>> you will be sending it out on receipt, there won't be any delays in
>> sending packets to the next-hop modem/router.
>
>> There won't *be* any packets in the queue on the PF machine to send in
>> priority order.
>
> ok. that is, for the sake of some 10% performance(not so long ago Theo turned off smt, and wanted to remove its support altogether. but smt it's significantly more than 10% of performance) you use queues only when the channel overload, that you are not able to reliably detect, but only assume about its occurrence? there's nothing easier! just put packets in the queue at all times :D

I don't know why you are going on about SMT here. But some workloads
are demonstrably *slower* if SMT is used (the scheduler just treats
them as full cores, when it would probably be better to only permit
threads of the same process to share SMTs on the same core). And of
course there are the known problems that became very apparent with the
CPU vulnerabilities that became widely known *after* OpenBSD disabled
SMT by default. But anyway back to packets.

The only constraint on transmitting packets from the OpenBSD machine
is the network interface facing the next-hop router. Say that is a
1Gbps interface. Say you have 200Mbps of traffic to forward from other
interfaces. And that the upstream connection can handle something
between 100Mbps and 200Mbps but you don't know how much. And there is no
way to tell when the upstream router has forwarded the packets.

BTW, HFSC with bandwidth and max set to the same values should be the
same thing as CBQ. But CBQ doesn't help anyway, you still have this same
problem. The only thing I can think of that might possibly help is to
delay all packets ("set delay") and use prio. I haven't tested to see
if that actually works but maybe. If you want real controls on the PF
box you need to cap to the *minimum* bandwidth and lose anything above
that. Or cap somewhere between the two picked as a trade-off between
lost capacity and not always doing anything useful.