> On 2023-12-01, 4 <[email protected]> wrote: >I don't know why you are going on about SMT here. i'm talking about not sacrificing functionality for the sake of hypothetical performance. the slides say that using queues degrades performance by 10%. and you're saying there won't be anything in the queues until an overload event occurs. as i understand it, these are interrelated things ;)
>And there is no way to tell when the upstream router has forwarded the packets. and we don't need to know that. the only way to find out when an overload "occurred" is to set some threshold value lower than the theoretical bandwidth of the interface and look when the actual speed on the interface exceeds this threshold. and then we will put packets in queues, but not early(so that our slaves don't get too tired, right?). but this has nothing with when overload actually happens but not in our imagination. in the most cases there is no bond between what we have assumed and what is actually happening(because there is no feedback. yes, there is ecn, but it doesn't work). i don't like this algorithm because it's a non-working algorithm. but an algorithm with priorities, when we ALWAYS(and not only when an imaginary overload occurred) put a packets in the queues, when we ALWAYS send packets with a higher priority first, and all the others only when there are no packets with a higher priority in the queue, this algorithm is working. i.e. we always use queues, despite the loss of 10% performance. what will happen on the overloaded upstream router is no our problem. our area of responsibility is to put more important for us packets into the our network card. but this requires a constantly working(and not only when an imaginary overload has occurred) priority mechanism. that's why i say that "prio" is much more useful than "hsfc". but it is also possible that traffic as important to us as ssh can take our entire channel, and we don't want that. and that's exactly where we need to limit the maximum queue speed. there may also be a situation where at least some number of packets should be guaranteed to go through some queue, for icmp as example, and here we need hsfc, since priorities alone cannot solve this problem. or we need cbq that could do it all at once. and i exist for all this to work well, it is i who must plan all this competently and prudently- this is my area of responsibility. and look, i need priorities and speed limits for this, but i don’t need to know how the upstream router is doing. if he has problems, he will send me confirmation of receipt less often or he will simply discard my packets. but that's his business, not mine. and in the same way my router will deal with clients on my local network. >BTW, HFSC with bandwidth and max set to the same values should be the same >thing as CBQ. except that the hfsc does not have a priority mechanism. ps: >But CBQ doesn't help anyway, you still have this same problem. the problem when both from below and from above can be told to you "go and fuck yourself" can't be solved, but cbq gives us two mechanisms we need- priorities and traffic restriction. nothing more can be done. but and less will not suit us
