| Time |
Nick |
Message |
| 00:31 |
|
Sokomine joined #minetest-hub |
| 00:51 |
|
Ganome317 joined #minetest-hub |
| 02:54 |
|
Miner_48er joined #minetest-hub |
| 06:28 |
|
CWz joined #minetest-hub |
| 07:16 |
|
Krock joined #minetest-hub |
| 07:23 |
|
_Xenon joined #minetest-hub |
| 09:50 |
|
IhrFussel joined #minetest-hub |
| 09:50 |
IhrFussel |
Why is the forum so slow lately? |
| 09:51 |
IhrFussel |
It can take up to 10 secs to load one page |
| 09:51 |
IhrFussel |
Really not pleasant to browse like this |
| 09:52 |
Krock |
*shrug* |
| 10:12 |
Krock |
> Also it's hardly possible to play MT with "200ms RTT and high packet loss"... |
| 10:12 |
Krock |
lolwhat |
| 10:13 |
Krock |
a server step of 0.2 is quite common |
| 10:13 |
Krock |
combining both results in almost half a second of delay, still good enough for gameplay |
| 10:17 |
IhrFussel |
Most servers with many heavyweight mods generally have a lag higher than the actual server step |
| 10:17 |
IhrFussel |
I'm quite happy with my 0.2-0.4 max lag mostly |
| 10:20 |
IhrFussel |
My server step is set to 0.15 but realistically the server cannot keep it at that as soon as 3 people joined |
| 10:35 |
|
Fixer joined #minetest-hub |
| 11:26 |
|
calcul0n joined #minetest-hub |
| 12:50 |
IhrFussel |
To fight the map stalling issues that occur whenever too many certain app users with random names connect I now implemented a command that blocks these users for 15 minutes ... that should help with random flooding |
| 13:38 |
rdococ |
can luacontrollers store functions? |
| 13:41 |
|
calcul0n joined #minetest-hub |
| 13:50 |
BuckarooBanzai |
IhrFussel: how about migrating to 5.x? :D |
| 13:51 |
IhrFussel |
Since the devs don't even know (yet) what exactly causes those issues I'm fairly certain that the exact same apps will be able to stall 5.X servers as well should they ever update to that engine version |
| 13:53 |
IhrFussel |
The most likely cause is a 'full map sending queue' somehow ... cause when it happens only nodes on the map and meta info are blocked (inventories don't work either, not sure if that only applies to storage nodes) |
| 13:54 |
IhrFussel |
Setting max block sends per client to 20 doesn't fix it |
| 13:54 |
Krock |
sad but true |
| 13:55 |
IhrFussel |
Oh writing on signs doesn't work either when it happens...so yes definitely something is blocking map nodes and meta |
| 13:57 |
IhrFussel |
Moving into unloaded map areas while attached to an entity makes the screen stutter a lot |
| 13:58 |
IhrFussel |
But it looks like the client still knows about stairs/slabs etc |
| 13:59 |
IhrFussel |
Cause in my test case the car suddenly went up a little in the void...exactly where stairs should be |
| 14:03 |
IhrFussel |
Here you can clearly see that the client DOES know about the snow levels and also the extreme stutter https://ihrfussels-server.de/cardemo.mp4 |
| 14:05 |
IhrFussel |
The protections at the bottom also update correctly depending on the position in the void |
| 14:06 |
IhrFussel |
To me it feels like the client gets the necessary terrain data from the server but something blocks it from loading it and making it walkable |
| 14:08 |
IhrFussel |
With noclip I can fly into the void and all entities will load correctly so all that works |
| 14:11 |
BuckarooBanzai |
IhrFussel: nice video, but AFAIK the car gets the coords from the server, and the blocks are still loaded/recognized on there... |
| 14:12 |
IhrFussel |
Yes but it is kinda weird that the client still knows where the car needs to step up/go down with no visible nodes |
| 14:13 |
Krock |
interesting. this again confirms that there's a stall in the block sending code |
| 14:13 |
Krock |
the client does not know where the car will drive |
| 14:13 |
Krock |
or can you walk on the nodes without the car? probably not |
| 14:13 |
BuckarooBanzai |
it would all be "ignore" nodes on the client... |
| 14:14 |
IhrFussel |
Without being attached to an entity you cannot move at all unless you use noclip |
| 14:14 |
* BuckarooBanzai |
pulls out wireshark... |
| 14:14 |
BuckarooBanzai |
:P |
| 14:15 |
IhrFussel |
So you mean the server stells the car that there is some obstacle and then it steps up? |
| 14:15 |
Krock |
yes |
| 14:15 |
IhrFussel |
tells* |
| 14:15 |
Krock |
it rather sends the car position very frequently |
| 14:15 |
Krock |
you should see that in the F5 profiler |
| 14:17 |
IhrFussel |
Yeah whenever the screen does a 'hiccup' the position slightly changes in F5 |
| 14:20 |
IhrFussel |
But wait maybe I was wrong that meta cannot be send during that stall... cause the signs I use are from signs_lib ... and those take the meta from the sign node and generate an entity with the value from local text = meta:get_string("text") |
| 14:20 |
IhrFussel |
And the text itself actually displays in the void |
| 14:21 |
BuckarooBanzai |
I believe: mapdata != entity-data (on the client at least) |
| 14:22 |
IhrFussel |
I know but node meta seems to work...reading at least |
| 14:22 |
BuckarooBanzai |
On the server-side: sure, looks like it... |
| 14:25 |
IhrFussel |
So could the screen stutter actually be server steps? |
| 14:27 |
BuckarooBanzai |
IhrFussel: how good is your C++ knowledge? Maybe a first step would be to profile the mapsending code (which ip / how much mapblocks/data is sent to what client) |
| 14:31 |
IhrFussel |
I have about zero knowledge regarding c++ =/ Here is another video that shows that the monster can't even see me in the void it seems https://ihrfussels-server.de/stalldemo.mp4 |
| 14:34 |
|
Fuchs joined #minetest-hub |
| 14:36 |
IhrFussel |
Ignore the last video, I was inside a wall |
| 14:49 |
IhrFussel |
Okay yeah I can confirm that the position in F5 only updates every step (0.15 secs in my case) when entering the void attached to an entity |
| 14:50 |
IhrFussel |
And that is also when the stuttering happens ... so basically the client suddenly doesn't know what's there anymore but the server tells the client to update the visuals anyways |
| 14:55 |
* BuckarooBanzai |
looks at https://github.com/minetest/minetest/blob/master/src/server.cpp and runs away from the 3700 LOC in there... :X |
| 15:04 |
IhrFussel |
Krock, when you say 'queue' do you mean a certain setting that can be changed? Like disk queue? Or is that something entirely internal |
| 15:05 |
Krock |
well yes, there's a total limit https://github.com/minetest/minetest/blob/master/src/server.cpp#L2287 |
| 15:05 |
Krock |
for 0.4.x that also means increasing the per_server setting to some high value |
| 15:07 |
IhrFussel |
So you mean setting max_simultaneous_block_sends_per_client to something very high should help with it? |
| 15:09 |
IhrFussel |
I don't even know how those apps can request so many more blocks at once...do they fake their positions and jump around? There is a max distance setting for block sending |
| 15:09 |
IhrFussel |
On my server it is 5 so max a radius of 5 blocks around the player |
| 15:15 |
IhrFussel |
WAIT |
| 15:15 |
IhrFussel |
0.4 doesn't even use per_client?? |
| 15:15 |
IhrFussel |
I only find max_simultaneous_block_sends_server_total |
| 15:25 |
Krock |
it uses both |
| 15:26 |
Krock |
players can't jump around without the server's permission. that would trigger anticheat |
| 15:30 |
IhrFussel |
But if the per_client would only be full wouldn't the server simply skip the user and go to the next one? |
| 15:31 |
IhrFussel |
I think the total server queue somehow gets full ... I will try setting it to 300 and see if there are any improvements |
| 15:32 |
Krock |
yes, that should be the case |
| 15:33 |
IhrFussel |
I didn't define max sends total cause someone told me that it's not used anymore... so in 0.4 you need to set it still |
| 15:34 |
Krock |
however, if the client keeps discarding the mapblock where they're in, then it tries to re-send the very same mapblock each step |
| 15:34 |
Krock |
since it's priority-sorted, based on the distance |
| 15:35 |
IhrFussel |
Should that be measurable via network monitoring CLI? |
| 15:36 |
Krock |
dunno |
| 15:36 |
Krock |
although the packet would always be the same |
| 15:37 |
IhrFussel |
Why would the client's app discard all those blocks though ... usually those apps don't touch any code that's not relevant to ads/inapp stuff |
| 15:38 |
Krock |
packet loss? mobile connection before timing out? dunno |
| 15:39 |
IhrFussel |
If that is the cause there is not much we can do about it right? |
| 15:39 |
IhrFussel |
I mean how would we fix that server side... |
| 15:41 |
rdococ |
for my digilines scripting language, maybe I could implement futures or promises |
| 15:41 |
IhrFussel |
Maybe limiting sending attempts and if all fail they have to wait a moment before they get blocks again |
| 15:42 |
Krock |
well, the block could be delayed by n of sending retries |
| 15:55 |
BuckarooBanzai |
IhrFussel: i may have the same problem as yours but it presents itself differently: every few weeks the "min-lag" is going from about 10 ms to above 100 ms and the server gets unresposive, but the server log still show activity in the forceloaded zones. In the image: https://i.imgur.com/dhqvTS3.png the lower right is the elevated min-lag. I've writ |
| 15:55 |
BuckarooBanzai |
ten a watchdog mod (https://git.rudin.io/minetest/watchdog) exactly for that but haven't found the root cause yet... |
| 16:07 |
IhrFussel |
My server had a similar problem in the past ... sometimes it would not react to any connections anymore and CPU% would stay at 100 all the time until I manually killed the process ... it fixed itself after I updated the MT version though |
| 17:26 |
|
pyrollo joined #minetest-hub |
| 17:28 |
rdococ |
what programming paradigm should I use for a digilines language? |
| 17:30 |
|
aerozoic joined #minetest-hub |
| 17:46 |
Krock |
digicode |
| 17:47 |
rdococ |
I was thinking of calling the language digilang |
| 17:57 |
Krock |
call it AIDS: Advances Instructions for Digiline Setups |
| 17:58 |
Krock |
confusion=100% |
| 18:08 |
rdococ |
hmm... imperative is the closest to Lua, but would that be best for something that's meant to connect to a digilines network? |
| 18:08 |
rdococ |
I guess the network is reminiscent of object-oriented programming |
| 18:14 |
xerox123 |
o/ |
| 18:18 |
rdococ |
hi |
| 18:18 |
|
IhrFussel joined #minetest-hub |
| 19:54 |
|
Darcidride joined #minetest-hub |
| 20:03 |
|
Darcidride_ joined #minetest-hub |
| 20:50 |
|
Gael-de-Sailly joined #minetest-hub |
| 21:02 |
sfan5 |
once again, it is time for statistics: https://kitsunemimi.pw/tmp/serverlist_stats_2019-05-19.txt |
| 21:03 |
rubenwardy |
hahha |
| 21:03 |
rubenwardy |
so many still on 5.0 |
| 21:04 |
rubenwardy |
also, it's 5.0.1 not 5.1.0 |
| 21:04 |
rubenwardy |
wait |
| 21:04 |
sfan5 |
yes |
| 21:05 |
rubenwardy |
is it protocol ver or user agent? |
| 21:05 |
rubenwardy |
user agent |
| 21:05 |
rdococ |
gUnknown? |
| 21:05 |
sfan5 |
by 5.1 I mean the current dev, not 5.0.1 |
| 21:05 |
sfan5 |
5.0.1 is counted under 5.0 |
| 21:06 |
rdococ |
4.16 is more popular than 4.17, interesting |
| 21:06 |
rubenwardy |
why such a mismatch between server list requests and players? |
| 21:07 |
rubenwardy |
ie: 87% on 5.0 according to serverlist, yet ~50% on 5.0 according to number of players online |
| 21:08 |
rdococ |
lol, 1 guy probably still using Windows 2000 |
| 21:08 |
sfan5 |
might be this one app that appears (?) to be 5.0 but can't join any 5.0 server because it's an incompatible dev version |
| 21:08 |
sfan5 |
¯\_(ツ)_/¯ |
| 21:09 |
rdococ |
weren't there dev versions that called themselves 0.5.0-dev before the 0. was dropped? |
| 21:10 |
sfan5 |
I didn't count those, so they appear under "unknown" |
| 21:11 |
rdococ |
I'm sad there are no time travellers using 6.0 |
| 21:32 |
|
FrostRanger joined #minetest-hub |
| 21:47 |
|
FrostRanger joined #minetest-hub |
