Time Nick Message 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 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: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: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:28 rdococ what programming paradigm should I use for a digilines language? 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 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