[Fixed] "Too many packets" error
#1
Many people seem to run into this error quite often.

From the logs that I've seens, the main cause seems to be the updates we're doing in the blockticking - the more block types we actually process, the more blockchanges there are to be sent to the clients. With a viewdistance of 9 (default), there could be as many as 361 packets to be sent per tick (1/20 sec). That means that in a mere 5 ticks the packet queue is almost full. If the client's TCP stack lags behind more than 1/8 second, they are bound to be disconnected due to the "packet queue full" error.

Also the bandwidth used is increasing. Each BlockChange packet is 12 bytes, each MultiBlockChange is at least 19 bytes. That could easily add up to 80 KiB/sec just for the blockchanges.

We need to find a better way of handling this.

(to be continued)
One solution comes to my mind that could be easy enough to implement: Delay the blockchanges sending for chunks that are far from the players. For example, if the distance to the player is less than 48 blocks, send each blockchange. If it's between 48 and 128 blocks, send blockchanges only every 4 ticks. If it's further, send blockchanges every 16 ticks.
That means that single-block changes won't be sent that often, they will get queued and combined into multiblock change packets that have a much better "blocks per network byte" ratio. Those multiblock packets will grow, too, but only 4 bytes per block changed, unlike 12 bytes for a single-block change packet.
Instead of doing "every 4 ticks" or "every 16 ticks", we could even do things as "at least 4 changes", "at least 16 changes", but we'd still need to cap the max delay to, say, 20 ticks, so that the blockchanges eventually do get to the players.
Reply
Thanks given by:
#2
I've also noticed that when chunks are being sent to the client, other packets are waiting (like chat, chest opening), which makes a big lag feeling when you're moving.

EDIT:
I just compiled the newest revision and i am getting too many packets almost instantly. :/
https://dl.dropbox.com/u/21041937/LOG_1339057451.txt
Reply
Thanks given by: xoft
#3
I have committed a temporary hotfix for this - I just set the packet queue limit to 5 times higher a number - 10k packets, instead of 2k packets. Not sure if it would help at all.

I still wonder - what's in all those blockchange packets? The generator should generate a world that shouldn't have that many block changes.
Reply
Thanks given by:
#4
Maybe that's this issue with water I told you about earlier? I can make a video of it if you want.

EDIT:
cChunk::TickGrass() is doing it! I've commented out the whole function and problem is gone.
Reply
Thanks given by:
#5
There were reports of this error even before the TickGrass() existed, so it can't be the sole cause. Still, the function should be mostly inert - there shouldn't be too many spots where the grass could grow in a freshly generated world.
Luksor, could you please test Rev 566, but with the old packetqueue limit (changed in Rev 565), and post a log?
Ah, finally I found out why I was unable to replicate the issue - I had my viewdistance set to 5 instead of the default 9. Setting it to the default made the issue immediately manifest itself.

So I found and fixed one error in TickGrass(), but there's still something fishy going on, there are still too many blocks turning into grass, so there must be another bug somewhere in there.
Great, that was hilarious! Smile
One part of TickGrass tried to turn all dirt blocks into grass. The other part tried to turn all grass blocks back to dirt. So the two were fighting and the protocol sufferred.

The main problem, the error in TickGrass, has been fixed in Rev 567, but for saved levels where that fight took place, the post-game still plays out - those underground grass blocks still need to be turned to dirt.

If you delete your level, you should probably be okay from those "too many packets" errors. If you don't want to delete your level, you'll need to log in a few times, it will slowly repair itself. Or you can wait for a proper protocol fix (not sure if it's gonna happen, though).
Or you can set your default viewdistance (in settings.ini) lower for a moment, that way you can login and walk around.
Reply
Thanks given by: Taugeshtu
#6
I think the error should be fixed completely in Rev 568.
Reply
Thanks given by:
#7
WOW! The communication between server and client works amazing for me now. Not only you fixed too many packets error, but also Downloading Terrain is a lot faster and from what i can see the chunks are streamed faster. Amazing work xoft!Big Grin
Reply
Thanks given by:
#8
Didn't you just forget to remove the viewdistance=5 from your settings.ini? Smile That would explain the faster terrain download; none of the work I did could actually improve on that (I think).
Reply
Thanks given by:
#9
I was suprised too, i'll download some speedhack mods and test it.Tongue
Reply
Thanks given by:
#10
A little comparison between r567 (top), and r568 (bottom):
https://dl.dropbox.com/u/21041937/mcs.gif
Reply
Thanks given by:




Users browsing this thread: 2 Guest(s)