Time |
Nick |
Message |
00:04 |
|
SFENCE joined #minetest-dev |
01:03 |
|
SFENCE joined #minetest-dev |
01:26 |
|
SFENCE joined #minetest-dev |
01:58 |
|
SFENCE joined #minetest-dev |
02:11 |
|
SFENCE joined #minetest-dev |
02:30 |
|
SFENCE joined #minetest-dev |
02:49 |
|
SFENCE joined #minetest-dev |
03:06 |
|
SFENCE joined #minetest-dev |
03:30 |
|
SFENCE joined #minetest-dev |
03:59 |
|
SFENCE_arch joined #minetest-dev |
04:00 |
|
MTDiscord joined #minetest-dev |
04:04 |
|
SFENCE joined #minetest-dev |
04:11 |
|
SFENCE joined #minetest-dev |
04:25 |
|
SFENCE joined #minetest-dev |
04:53 |
|
SFENCE joined #minetest-dev |
05:17 |
|
SFENCE joined #minetest-dev |
05:23 |
|
SFENCE joined #minetest-dev |
06:01 |
|
hwpplayer1 joined #minetest-dev |
06:09 |
|
SFENCE joined #minetest-dev |
06:22 |
|
hwpplayer1 joined #minetest-dev |
06:32 |
|
SFENCE joined #minetest-dev |
06:45 |
|
SFENCE joined #minetest-dev |
08:21 |
|
fluxionary joined #minetest-dev |
12:12 |
|
hwpplayer1 joined #minetest-dev |
13:06 |
|
SFENCE joined #minetest-dev |
13:29 |
|
hwpplayer1 joined #minetest-dev |
14:53 |
|
SFENCE joined #minetest-dev |
15:20 |
|
SFENCE joined #minetest-dev |
15:23 |
|
bvm joined #minetest-dev |
15:57 |
|
hwpplayer1 joined #minetest-dev |
15:59 |
|
hwpplayer1 joined #minetest-dev |
16:00 |
|
hwpplayer1 joined #minetest-dev |
16:01 |
|
v-rob joined #minetest-dev |
16:13 |
|
SFENCE_arch joined #minetest-dev |
16:16 |
SFENCE_arch |
In single player mode, if you died and server shutdown in the time you see respawn window, uou are not respawned after another start up. |
16:16 |
SFENCE_arch |
Itis behaviors comming from minetest game? |
16:18 |
SFENCE_arch |
hmm. Error on my side. |
17:02 |
|
hwpplayer1 joined #minetest-dev |
17:08 |
|
SFENCE joined #minetest-dev |
17:19 |
|
SFENCE joined #minetest-dev |
17:43 |
sfan5 |
5.9.1 today? |
17:51 |
Krock |
5.9.1 today |
17:52 |
Krock |
writing the changelog. |
17:58 |
sfan5 |
there are a bunch of PRs we still need to merge |
18:12 |
|
v-rob joined #minetest-dev |
18:13 |
Krock |
first draft saved. checking the PRs now |
18:15 |
Krock |
I'll cherry-pick #15150 either after it's either tested or approved |
18:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/15150 -- Revert "Set VBO hints in more places" by grorp |
18:21 |
MTDiscord |
<wsor4035> it will be late (est) tonight before i am able to test that fyi |
18:54 |
|
Sokomine joined #minetest-dev |
19:04 |
Krock |
sfan5: what's the difference between testing #15087 with 5.9.0 or 5.10.0-dev? |
19:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/15087 -- [no squash] Fix network window size logic by sfan5 |
19:06 |
sfan5 |
there isn't really any |
19:12 |
|
hwpplayer1 joined #minetest-dev |
19:13 |
MTDiscord |
<warr1024> sfan5: in 15151, I'm getting a whole bunch of "undefined reference to EnrichedString::whatever" type errors on the final linking step ... did something change recently? |
19:14 |
sfan5 |
sounds like build artifacts that weren't rebuilt for some reason, try a clean build |
19:14 |
|
Sokomine joined #minetest-dev |
19:14 |
MTDiscord |
<warr1024> will do, cya in ~20 min 😅 |
19:33 |
MTDiscord |
<warr1024> Didn't work. |
19:34 |
MTDiscord |
<warr1024> Well, it doesn't solve the problem if you follow the test procedure from 15125 |
19:34 |
MTDiscord |
<warr1024> I can't tell whether or not it improves things in other cases |
19:34 |
MTDiscord |
<warr1024> I guess that's sort of to be expected if you only fix the database locking and not safe file writes |
19:35 |
sfan5 |
how many of those do you have |
19:35 |
MTDiscord |
<warr1024> what do you mean? |
19:35 |
MTDiscord |
<warr1024> The only one I know of off the top of my head is env_meta.txt |
19:36 |
sfan5 |
I was thinking your mod could would call it often |
19:36 |
MTDiscord |
<warr1024> I'm testing this thing mostly in MTG though, and I don't know that game that well. I was under the impression it was considered pretty "barebones" though. |
19:36 |
sfan5 |
code* |
19:36 |
sfan5 |
(I didn't read or attempt much of the instructions, or look at the perf results) |
19:37 |
sfan5 |
I guess maybe your issue not about the map loading then |
19:37 |
sfan5 |
+is |
19:38 |
MTDiscord |
<warr1024> I think it means that map loading is part of the issue, not all of it. |
19:38 |
MTDiscord |
<warr1024> Basically the main thread is running globalsteps in a loop |
19:38 |
sfan5 |
shouldn't the PR make a measureable difference then? |
19:39 |
MTDiscord |
<warr1024> There are points in that loop where it was waiting on disk |
19:39 |
MTDiscord |
<warr1024> one of those would have been via the env lock |
19:39 |
|
SFENCE joined #minetest-dev |
19:39 |
MTDiscord |
<warr1024> I suspect that writing out env_meta.txt and anything else we write as plain files is another. |
19:39 |
MTDiscord |
<warr1024> It might make a measurable difference. I wasn't looking at how broken things were, just whether they were fixed or not. |
19:40 |
sfan5 |
fwiw map metadata, mod metadata and player stuff is also written inside the main loop |
19:41 |
MTDiscord |
<warr1024> Basically if you can saturate the disk with activity enough that the queue length is measured in seconds instead of milliseconds, then anywhere we get stuck waiting on a disk thing to complete will translate into lag in the main thread. |
19:41 |
MTDiscord |
<warr1024> If that doesn't happen on database access, but skipping the database wait just runs us into an env_meta.txt wait at roughly the same place in the disk queue, then we still get much of the same symptom. |
19:43 |
sfan5 |
"Minetest doesn't work well with disk write latencies >1s" would be a wontfix from my side |
19:43 |
sfan5 |
even if technically possible |
19:44 |
sfan5 |
but if I understand correctly this is a spin off from #15000, so it describes some problem you had in normal production usage |
19:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/15000 -- Major Server Performance Regression |
19:45 |
sfan5 |
the "backups or database maintenance" point to me sounds like it's not necessarily the disk usage but rather the database being locked |
19:45 |
Krock |
I suppose if the disk latency is a whole second, then you might have whole different issues with your system |
19:46 |
MTDiscord |
<warr1024> Backups don't lock the database. |
19:47 |
MTDiscord |
<warr1024> I mean, they add work to the database's queue, but it's still serving requests during that time. |
19:52 |
sfan5 |
with the pr applied can you check the profiler for "load block" figures? |
19:52 |
MTDiscord |
<warr1024> Even if "make MT playable when the disk queue length is >1s" is going to be a wontfix, making it run properly when the disk queue length is >0 should be. I would assume that we wouldn't want to add the disk queue length to the globalstep size no matter what size it is. |
19:52 |
MTDiscord |
<warr1024> I can, which profiler am I looking at? |
19:53 |
sfan5 |
F6 profiler |
19:53 |
sfan5 |
also works on the server with some config setting |
19:54 |
sfan5 |
the thing is "don't add disk queue length to globalstep" and "make MT playable when the disk queue length is >1s" have the same solution and it would be to make sure all disk writes are async |
19:54 |
MTDiscord |
<warr1024> right, hence why the wontfix shouldn't matter because it'd end up getting fixed as part of something you'd obviously want to fix |
19:55 |
sfan5 |
i was going more in the direction of not fixing either ;) |
19:56 |
MTDiscord |
<warr1024> Well, that's the default direction that this was going before. |
19:56 |
MTDiscord |
<warr1024> not under load, 100 to 150. Under load, 150 to 200 |
19:58 |
sfan5 |
which value is that? |
19:59 |
MTDiscord |
<warr1024> ServerMap: load block [us] (the rightmost value, not the sample count) |
19:59 |
MTDiscord |
<warr1024> I assumed that was what you wanted since you weren't more specific. There are apparently a bunch of things called "load block" and "save block" in there. |
19:59 |
sfan5 |
oh that one is not relevant |
20:00 |
sfan5 |
it should be "load block - sync" or "load block - async" |
20:00 |
MTDiscord |
<warr1024> I don't have one of those |
20:00 |
MTDiscord |
<warr1024> wait let me check something |
20:00 |
MTDiscord |
<warr1024> yeah, no, I don't have it. |
20:01 |
MTDiscord |
<warr1024> thought it might be a singleplayer vs host server thing but I get the same 3 pages of F6 either way |
20:01 |
sfan5 |
that means the server is not spending any time waiting for the map database |
20:02 |
MTDiscord |
<warr1024> I guess I can check it under load in pure SP to be sure |
20:03 |
MTDiscord |
<warr1024> yeah, I got it when I put it under load. It mostly hovers around like 100 to 400, but it can spike up to about 2000 |
20:04 |
MTDiscord |
<warr1024> yeah, it looks like I've got 3 pages whether in SP or host server mode, but they've got a few different things in them |
20:04 |
sfan5 |
the async or sync figure? |
20:06 |
MTDiscord |
<warr1024> only async |
20:06 |
sfan5 |
that's how it should be and means those are not causing lag |
20:07 |
MTDiscord |
<warr1024> map saving seems to pop up a bit, mostly in the 100 to 200 range, but it's quiet a lot. Map timer and unload though seems a bit odd, with the occasional large figure like 2000 to 4000 popping up there |
20:08 |
MTDiscord |
<warr1024> Well, it's a big improvement, at least, and it might make a big difference when things are in a "middle" load state. |
20:09 |
MTDiscord |
<warr1024> The problem was I needed a minimal repro example that definitely makes the problem visible, because "watch a real-world server for 12 hours and note that there are 5% more intolerable lag excursions" doesn't make for good testing. |
20:10 |
sfan5 |
can you use profiler_print_interval and post the results as text in the issue? |
20:10 |
MTDiscord |
<warr1024> what kind of sample sizes are you looking for? |
20:11 |
MTDiscord |
<warr1024> and are you talking about for my artificial test case, or for a production server? |
20:11 |
sfan5 |
test case is fine, just run it a few minutes |
20:11 |
|
SFENCE joined #minetest-dev |
20:23 |
MTDiscord |
<warr1024> Done. In both cases I just flew around the same spiral area, which I was sure had already been generated during previous tests. |
20:25 |
MTDiscord |
<warr1024> I got about 60 seconds in each test case. Not under load, I didn't see any performance issues. Under load, I saw the original symptoms more or less: about half of the time, MT is running normal 0.05s steps, but then it spent about 20 seconds each minute running steps >=1s. |
20:33 |
|
Desour joined #minetest-dev |
20:45 |
|
SFENCE joined #minetest-dev |
20:50 |
|
vampirefrog joined #minetest-dev |
21:01 |
|
SFENCE joined #minetest-dev |
21:18 |
|
SFENCE joined #minetest-dev |
21:20 |
MTDiscord |
<andrey2470t> Will anybody do a review of #15061? It is already pretty close to the polished out state only with a few artifacts left to fix |
21:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/15061 -- Texture atlas for mapblocks meshes by Andrey2470T |
21:23 |
MTDiscord |
<andrey2470t> Also, it would be good to do testing on Android also, one github user reported about "each block is black" with the atlas, but I didn't find out on which settings it happens |
21:31 |
MTDiscord |
<andrey2470t> And what's about adding it to 5.10 milestone? |
21:53 |
|
SFENCE joined #minetest-dev |
22:19 |
|
SFENCE joined #minetest-dev |
22:34 |
|
panwolfram joined #minetest-dev |
22:56 |
|
SFENCE joined #minetest-dev |
22:56 |
|
v-rob joined #minetest-dev |
23:05 |
|
Eragon joined #minetest-dev |
23:16 |
|
SFENCE joined #minetest-dev |
23:29 |
MTDiscord |
<warr1024> For PR 15151, I don't know if it's worth commenting on the PR thread about it, but it may be worth noting that it might still be hugely beneficial for some use-cases, even if it doesn't completely solve 15125. |
23:30 |
MTDiscord |
<warr1024> It's very uncommon but I seem to remember hearing about somebody who had some special use-case for a remote database, and something like that could be hugely useful. |
23:41 |
|
SFENCE joined #minetest-dev |