Hey all,

First lets start off with a disclaimer. Yes im a ICT person but no im not specialized in networking. Any super specific questions? Go hit your search engine of choice.
I am however found of projects increasing my knowledge and lately I picked up my firewall project again and ran into something lovely.
So lets begin.

To quote; Bufferbloat is undesirable latency caused by routers and cable/DSL modems buffering more data than necessary.
Source of this specific quote is here:
https://www.dslreports.com/faq/17883

So whats this to you? In short, if you have this than stuff will suck. Weird lag for example. Hitreg? Who knows.
Point is, its there and you dont want it.

Do you have it?
https://www.dslreports.com/speedtest
Run that test, do not tab out of it or lose focus. Run it a few times to compare but do notice that eventually all connections will suffer to a certain degree. :)
A+ means its great.
F means how the F are you still gaming. ;)

What to do about it?
Complain to your ISP. Bufferbloat is a problem in either your modem/firewall, or upstream. (aka on their end.)
Or if you feel adventurous, make your own firewall like I did and than put it in your modems DMZ or bridge the modem. :)

What do the possible fixes do?
Updating firmware and hardware itself hopefully includes protocals, ways to talk, to minimize the issue.
Devices which support it can be told to stop ffing flooding you so the queue can calm down. (Explicit Congestion Notification)
You can setup to drop packets so the queue doesnt fill up. (Yes, Im not kidding.. this is better.) (Active Queue Management, like CoDel)
https://rule11.tech/codel-active-queue-management/


TLDR:
* Check if you have Bufferbloat by this testlink:
https://www.dslreports.com/speedtest
* Complain to ISP accordingly or get a good firewall and DIY.

Hey, seems like you are a competent person.
Can you explain this shit? https://forums.unknownworlds.com/discussion/149346/good-evidence-of-broken-netcode
Developers says that my connection is bad, but I've got A+
https://www.dslreports.com/speedtest/20102704

Darkling,

What was your rating before and after your firewall?

Before I was around B-C, mostly B.
But I didnt start my firewall project for this.. it was just positive collateral.

Im currently managing the buffers better, running true firewall rules, and performing traffic shaping.
Much more to do still like VLANs, but one step at a time.


@Myx
Ghouls answer was pretty clear when I read it, but I shall try to recap. (well explain, this post shall be a lot longer.)

Ghoul has the same problem a while back and that was due to packet CRC failures (ISP's local node malfunction). This is a problem on your ISPs end, assuming it was due to CRC.
CRC so far I understand means the packet received wasnt the same as what was send out. It got corrupt.

Let my copy paste what he said for the next part:
-- Somehow the server keeps sending the same reliable packet again and again never receiving the acknowledge message for giving packet from the client. That stops the server from sending any further reliable packets until a certain timelimit is reached and the server discards the complete message queue for given client and restarts from 0 (which takes up to 5-10 minutes).
* ACK packages are important. ACK is used by clients to say 'Hey, I got this packet.. its received, thanks'. If ACK isnt send the packages usually get resend, the server retries. Eventually it will give up.

--While that happens most of the required game data (using reliable packets) is stuck and doesn't update. It is even worse if this happens shortly after connect causing you to end with a black screen in the Ready Room.
* If the above happens, you do not receive any new info which uses the type of packages you didnt send ACKs on.
-- Somehow the server keeps sending the same reliable packet again and again never receiving the acknowledge message for giving packet from the client. That stops the server from sending any further reliable packets until a certain timelimit is reached and the server discards the complete message queue for given client and restarts from 0 (which takes up to 5-10 minutes).
* Basicly a repeat of what he and I both just said above.

-- While that happens most of the required game data (using reliable packets) is stuck and doesn't update. It is even worse if this happens shortly after connect causing you to end with a black screen in the Ready Room.
* End result.

When I was doing traffic shaping on my own firewall its buildin wizard put the ACK packages in a specific queue.
It has THE HIGHEST priority of all the queues. Because if my client does not reply to ACK, stuff is resend, clogging up the queues even more.
ANy traffic should be dropped first to make sure it doesnt drop ACK. At least, thats how I understood all the documentation and various sources I read so far.

Your logs show that what Ghoul said is true, the packages arent being send. So the server retries.
So no matter how good your connection is or is not normally, at that moment it is dropping packages.. for some reason. I wonder how bad it would be on your buffers during that time.. sadly, you cant see in almost all ISP modems.

http://imgur.com/a/VkT9n
You can due to normal browsing some queues are full. It decided to drop 3 packages out those queues because of priority.
But I experience no issues.. My ACK queue having the best prio is empty (its being handled first.)
My game queue when I was gaming never reached max.
Stuff like Peer2Peer is in essence bloat. Its handled dead last always.

thanks for the info.



ugh. might explain why it feels like i'm playing under water these days. time for a new router i suppose

No problems here.

http://imgur.com/a/nGm1u

As a side note.. if you got weird buffer issues or drops, you may want to see if you are allowed to limit your connection in your modem.
Both ingoing (LAN) and outgoing (WAN).

The logic is rather simple.
If you hit your max speed, your ISP is doing QOS and buffering and all that stuff.
If you stay well below your maximum, there is a much better chance you will never hit a max buffer limit, so there is less need for QOS.