| Time |
Nick |
Message |
| 00:04 |
|
loggingbot_ joined #minetest-dev |
| 00:04 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 00:54 |
|
bas080 joined #minetest-dev |
| 01:07 |
sapier |
john_minetest if you wanna have a try: https://github.com/sapier/minetest/tree/network_addon_tcp_2 |
| 01:28 |
ShadowNinja |
http://ix.io/9Jc This fixes replacing nodes. (And fixes code style) Comments? <-- VanessaE. |
| 01:39 |
ShadowNinja |
http://ix.io/9Je This too, it adds protection support to auto-rotated nodes. |
| 01:45 |
|
Taoki joined #minetest-dev |
| 01:45 |
ShadowNinja |
http://ix.io/9Jf Pass pointed_thing to after_place_node. (Maybe this should be copied?) |
| 01:58 |
|
bas080 joined #minetest-dev |
| 02:08 |
sapier |
celeron55 those settings for minetest.conf you gave me, plz don't make em default for me they result in delayed node placing for at least up to 10 seconds |
| 02:09 |
ShadowNinja |
sapier: Any comments on ^? |
| 02:10 |
sapier |
don't seem to contain obvious errors but I didn't have time to test it by now |
| 02:11 |
ShadowNinja |
https://github.com/minetest/minetest/commit/22dbbf0a6fc9547f0dbdb7f6076337b8c6acd48b we (me and kwolekr) agreed to revert this because it didn't work, but it was never actually reverted. |
| 02:13 |
sapier |
ok let's have a look who's maintainer for map related things |
| 02:14 |
sapier |
I think if you ask hmmmm he's gonna remove it quit quickly |
| 02:15 |
ShadowNinja |
I'll revert it as he already agreed to revert it. |
| 02:17 |
sapier |
If I remember correctly I was assigned to mainmenu yesterday too .... unless you feel mainmenu to be part of scriptAPI ShadowNinja? |
| 02:22 |
ShadowNinja |
sapier: It doesn't matter. I officially assign you to the mainmenu section of the ScriptAPI. ;-) |
| 02:23 |
sapier |
ok what about #236 I don't like the idea making minetest passwords even more unsafe by storing them to config file ... the code provided is useless so this is basicaly a feature request |
| 02:23 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/236 -- HTTP Error 404: Not Found |
| 02:25 |
xyz |
why the hell does the bot randomly switches between minetest_game and minetest issue trackers? |
| 02:26 |
kaeza |
< 500 = _game |
| 02:26 |
ShadowNinja |
xyz: It uses <500 == minetest_game >500 == minetest |
| 02:26 |
sapier |
https://github.com/minetest/minetest/pull/236 |
| 02:26 |
sapier |
ok so we should get rid of those 9 pulls below 500 in minetest ;-P |
| 02:26 |
proller |
+1 for storing passwords |
| 02:27 |
sapier |
anyone to implement it including save storage or at least big fat disclaimer ? |
| 02:27 |
sapier |
wait save storage would add a password for accessing save storage so I guess it'd be nonsense |
| 02:28 |
xyz |
should be per-world, otherwise it's fine as is |
| 02:28 |
sapier |
right not it's not saved ad all? |
| 02:28 |
xyz |
err, as in this pull request |
| 02:29 |
xyz |
no fat disclaimers, no passworded save storages |
| 02:29 |
xyz |
just a checkbox "save password" |
| 02:30 |
sapier |
that's some thing I wont gonna merge, storing passwords as cleartext was silly 10 years ago |
| 02:30 |
xyz |
probably should store them in separate config file though |
| 02:30 |
sapier |
that's not gonna be a difference |
| 02:31 |
ShadowNinja |
It's sent to the server as SHA-1, right? Couldn't it be stored like that? |
| 02:31 |
xyz |
users won't paste their passwords accidentally when pastebin'ing minetest.conf |
| 02:31 |
sapier |
but until someone provides anything mergable I guess we don't have to discuss about it |
| 02:31 |
xyz |
why not? |
| 02:32 |
xyz |
if someone provides something mergeable and you just say "fug that i dont like how it is" then what was the point of that someone to spend their time coding this? |
| 02:32 |
sapier |
hashes could be an option |
| 02:33 |
sapier |
as we don't care about passwords really beeing a save authentication hash would at least protect the password itself from beeing revealed |
| 02:34 |
sapier |
and we already send the hash in cleartext through network so storing it on disk isn't actually less save |
| 02:35 |
sapier |
xyz I guess you now have your option how this feature is agreeable |
| 02:35 |
ShadowNinja |
Yes, anyone with wireshark can get your hash, and if you don't know how to use wireshark you probably don't know how to send a custom hash. |
| 02:36 |
sapier |
so unless we switch to encrypted communication password wont get less save then it is now |
| 02:37 |
ShadowNinja |
s/save/safe/g |
| 02:38 |
sapier |
why does english have to have two words for a thing only beeing one word in german ;-) |
| 02:38 |
ShadowNinja |
Because they're two different concepts? ;-) |
| 02:40 |
xyz |
ShadowNinja: no, not anyone |
| 02:40 |
sapier |
you know language is defining concept of mind, australian natives for example don't even know what "next to something" means, they only know north south ... |
| 02:41 |
sapier |
the curious thing about this is the even know where north is within buildings |
| 02:42 |
sapier |
ok I commented what we discussed |
| 02:42 |
sapier |
anything missing? |
| 02:42 |
ShadowNinja |
xyz: +suitable skills |
| 02:43 |
ShadowNinja |
(And on the server or client's LAN) |
| 02:43 |
xyz |
ShadowNinja: yes, yes, you forgot this point |
| 02:43 |
xyz |
about lan |
| 02:43 |
sapier |
what about lan? |
| 02:44 |
xyz |
world specific? |
| 02:44 |
xyz |
you meant server specific |
| 02:44 |
sapier |
yes |
| 02:44 |
sapier |
ok fixed |
| 02:45 |
sapier |
do we want to save passwords for different names too? |
| 02:46 |
xyz |
no |
| 02:46 |
xyz |
just save name + password hash per server |
| 02:47 |
sapier |
ok so if there's someone to implement it we can merge it |
| 03:04 |
|
NakedFury joined #minetest-dev |
| 03:07 |
|
sapier left #minetest-dev |
| 03:48 |
|
ShadowNinja joined #minetest-dev |
| 03:56 |
ShadowNinja |
xyz: Well, getting on their LAN is easier than getting on their computer, so my point still stands. |
| 04:04 |
|
us_0gb joined #minetest-dev |
| 04:15 |
VanessaE |
ShadowNinja: no complaints if it works :) |
| 04:16 |
VanessaE |
(everyone hates my code style :( ) |
| 04:55 |
us_0gb |
VanessaE: What's wrong with your code style? |
| 04:56 |
VanessaE |
us_0gb: ask ShadowNinja :) |
| 04:56 |
us_0gb |
Well, ShadowNinja? |
| 04:56 |
us_0gb |
That was dumb of me. You already called him. |
| 04:57 |
* us_0gb |
blames his headache, though that probably isn't the cause |
| 05:16 |
|
mrtux joined #minetest-dev |
| 05:20 |
|
darkrose joined #minetest-dev |
| 05:31 |
|
hmmmm joined #minetest-dev |
| 05:36 |
|
ShadowNinja joined #minetest-dev |
| 05:36 |
|
ShadowNinja joined #minetest-dev |
| 05:37 |
|
hmmmm joined #minetest-dev |
| 05:39 |
|
book` joined #minetest-dev |
| 05:39 |
|
e1z0_ joined #minetest-dev |
| 05:40 |
|
VargaD joined #minetest-dev |
| 05:40 |
|
IceCraft joined #minetest-dev |
| 05:40 |
|
IceCraft joined #minetest-dev |
| 05:40 |
|
xyz|imag1nary joined #minetest-dev |
| 05:53 |
|
NakedFury joined #minetest-dev |
| 05:53 |
|
mrtux joined #minetest-dev |
| 05:54 |
|
bas080 joined #minetest-dev |
| 05:57 |
|
darkrose joined #minetest-dev |
| 06:01 |
celeron55 |
ShadowNinja: nobody refers to minetest_game issues here, so you could just change it to always link to minetest |
| 06:38 |
|
damiel joined #minetest-dev |
| 06:49 |
|
e1z0 joined #minetest-dev |
| 06:53 |
|
e1z0 joined #minetest-dev |
| 06:55 |
|
e1z0 joined #minetest-dev |
| 07:23 |
|
mrtux joined #minetest-dev |
| 07:35 |
|
harrison joined #minetest-dev |
| 08:16 |
|
proller joined #minetest-dev |
| 09:50 |
|
sapier joined #minetest-dev |
| 09:53 |
sapier |
If there's no one against it I'm gonna merge the patch from https://github.com/minetest/minetest/issues/1052 in 15 min |
| 11:30 |
proller |
ShadowNinja, https://github.com/minetest/minetest/commit/0fd5c61c00819ae3eaf298739e8cf879e2d43820 - this not works even when blocks already loaded ? |
| 11:41 |
proller |
for me - it works ok, found new spawn point if old built |
| 11:41 |
proller |
also after revert spawn ~always in stone |
| 11:46 |
|
jin_xi joined #minetest-dev |
| 11:48 |
celeron55 |
that hash saving in a separate file seems like a valid usability improvement |
| 11:48 |
celeron55 |
with a setting to turn it completely off, nobody should have to complain |
| 11:49 |
sapier |
I add those requirements to my comment |
| 11:50 |
proller |
and reverting something works at 50% instead of fixing - very bad idea |
| 11:52 |
sapier |
we don't use challange response for password hashing do we? |
| 11:54 |
proller |
its game, not banking |
| 11:54 |
celeron55 |
we don't use really anything at all |
| 11:54 |
celeron55 |
actually, we could have an even simpler system, by hashing only the password without anything else in the hash |
| 11:54 |
celeron55 |
it was ridiculous to find out that fluxbb does that 8) |
| 11:55 |
sapier |
lol :-) |
| 11:55 |
celeron55 |
(a fork of punbb) |
| 11:55 |
celeron55 |
it isn't even configurable or modifiable to do anything else |
| 11:55 |
sapier |
I've already given up to make minetest more secure I stick to prevent getting it even less secure :-) |
| 11:56 |
celeron55 |
i still think the mod api stuff should be put in; now it should be doable when you have push access and all |
| 11:57 |
sapier |
celeron I guess the latest udp fixes version still hangs for some seconds on shutdown for you? |
| 11:57 |
celeron55 |
i can't test now |
| 11:57 |
celeron55 |
i'm at work not doing work |
| 11:57 |
sapier |
ok no problem |
| 11:58 |
sapier |
I'm just out of options without ability to reproduce it I need to find a new way to get more information about it |
| 11:58 |
sapier |
maybe a wireshark trace could help |
| 12:33 |
|
iqualfragile joined #minetest-dev |
| 12:38 |
|
ImQ009 joined #minetest-dev |
| 12:56 |
|
hmmmm joined #minetest-dev |
| 13:24 |
|
Gethiox joined #minetest-dev |
| 14:31 |
|
bas080 joined #minetest-dev |
| 15:09 |
|
Yepoleb_ joined #minetest-dev |
| 15:40 |
|
Ritchie joined #minetest-dev |
| 15:54 |
celeron55 |
sapier: network_fixes_udp_1 seems to still hang at logout |
| 15:55 |
celeron55 |
i mean, singleplayer quit |
| 15:55 |
celeron55 |
(until disconnect timeout) |
| 15:56 |
sapier |
I know ... can you please do a wireshark trace as well as backtrace of all threads in hang state? maybe that information shows what's wrong there |
| 16:04 |
|
PilzAdam joined #minetest-dev |
| 16:06 |
|
Anchakor_ joined #minetest-dev |
| 16:09 |
celeron55 |
sapier: where's the updated dissector? |
| 16:10 |
celeron55 |
hmm, actually this one in the repo seems to work quite fine |
| 16:12 |
sapier |
not for all packets |
| 16:12 |
sapier |
but fine enough for connect/disconnect |
| 16:18 |
celeron55 |
i can't tell anything from this except that the client continues trying to send pings and gotblocks |
| 16:18 |
sapier |
if client is sending pings he didn't get the shutdown for some reason |
| 16:19 |
celeron55 |
oh now i found one disco |
| 16:20 |
sapier |
the disconnect is queued like any other packet so if you really pushed a lot of packets to queue this might explain the delay |
| 16:21 |
sapier |
but for what reason should client send that much unreliable data to server? |
| 16:21 |
celeron55 |
the server seems to receive the disco, because right after it it stops sending anything |
| 16:21 |
celeron55 |
then the client stays on and tries to send stuff to the server |
| 16:22 |
|
kaeza joined #minetest-dev |
| 16:22 |
sapier |
that's even more strange |
| 16:23 |
sapier |
ok wait disconnect is just a command so client will send additional packets if it's thread isn't stopped, if someone keeps pushing new commands to client it may never shutdown |
| 16:24 |
sapier |
but the only one pushing commands to queue is client itself which is waiting for send thread to shutdown |
| 16:25 |
sapier |
hmm and receive thread, it's pushing the acks |
| 16:25 |
celeron55 |
http://c55.me/random/2014-01/tscrot-2014-01-07_18-22-28.png |
| 16:25 |
celeron55 |
maybe the client likes disco! |
| 16:26 |
sapier |
:-) yea ... I first was wondering what the hell disco means :-) |
| 16:26 |
sfan5 |
disco is the worst and the best abbrevation for disconnect |
| 16:27 |
celeron55 |
it's the only one that anyone is allowed to use |
| 16:29 |
sapier |
no the ack guess can't be true too as receive thread has to shutdown at worst 10 packets/aka 0,5 seconds after thread shutdown is requested |
| 16:35 |
|
Calinou joined #minetest-dev |
| 16:37 |
sapier |
ok I pushed my next guess |
| 16:42 |
|
Zeitgeist_ joined #minetest-dev |
| 16:42 |
celeron55 |
hung on first try 8) |
| 16:43 |
proller |
reduce number of packets - https://github.com/freeminer/freeminer/commit/123afc37dc83468b989fb9d192b93b2023dd5c93 |
| 16:47 |
Calinou |
"Got Blocks?" |
| 16:47 |
celeron55 |
Calinou: ? this is #-dev |
| 16:48 |
celeron55 |
bad ununderstandable jokes are disallowed! |
| 16:53 |
|
Jordach joined #minetest-dev |
| 16:54 |
|
rubenwardy joined #minetest-dev |
| 17:05 |
|
NakedFury joined #minetest-dev |
| 17:09 |
|
BlockMen joined #minetest-dev |
| 17:17 |
xyz |
what about understandable ones? https://gist.github.com/xyzz/79abb066dd3772ff631d |
| 17:18 |
proller |
5% better than old funcrions passing |
| 17:19 |
celeron55 |
so you found moonscript |
| 17:19 |
xyz |
the purpose of this mod is to troll people |
| 17:19 |
xyz |
by the way, why can't we access marshal serializer in mods? |
| 17:21 |
celeron55 |
sapier: apparently client can stop itself on the connection timeout just fine, so can't the same mechanism be used for this? |
| 17:22 |
xyz |
celeron55: correct |
| 17:22 |
xyz |
I've just found it |
| 17:22 |
celeron55 |
sapier: like, even as simply as just lowering the timeout to like 1 second when the client is disconnecting |
| 17:23 |
celeron55 |
it's a bit hacky though, maybe |
| 17:47 |
|
nyuszika7h_ joined #minetest-dev |
| 17:49 |
|
Gethiox2 joined #minetest-dev |
| 17:51 |
|
salamanderrake joined #minetest-dev |
| 18:02 |
|
smoke_fumus joined #minetest-dev |
| 18:09 |
sapier |
celeron55 I give it a try, but I'd prefere to understand why this happens |
| 18:10 |
|
john_minetest joined #minetest-dev |
| 18:10 |
|
salamanderrake joined #minetest-dev |
| 18:11 |
proller |
sapier, just try enet ;) |
| 18:12 |
sapier |
I guess you have to be blind or even more ignorant then I thought if you haven't realized I already have a enet variant published |
| 18:15 |
sapier |
btw proller you could try to find out why enet doesn't provide correct jitter values might be relevant on comparing protocols |
| 18:17 |
sapier |
according to enet jitter counter jitter is exactly 0 .... but that doesn't match it's own rtt variance so at least one of those numbers is wrong |
| 18:18 |
sapier |
"I guess you have to be blind or even more ignorant then I thought if you haven't realized I already have a enet variant published" sorry bout that proller I guess you're not guilty for celeron55's new superfast laptop |
| 18:19 |
xyz |
wat |
| 18:20 |
sapier |
I didn't want to be that harsh that sentence actually got |
| 18:22 |
sapier |
celeron55 I pushed a variant reducing the peer timeout on disconnect ... but of course this only helps if it's really the timeout causing the shutdown |
| 18:35 |
|
Akien joined #minetest-dev |
| 18:38 |
celeron55 |
this is getting a bit away from the "let's just fix udp quick and then continue on something else" plan 8) |
| 18:38 |
celeron55 |
well this appears to not hang now |
| 18:38 |
celeron55 |
in whatever way it happens to avoid it now |
| 18:39 |
sapier |
yeah ... it's your fault why do you have to buy a new pc triggering that much threding issues ;-) |
| 18:40 |
sapier |
did it work by chance only or mutliple times? ;-) |
| 18:41 |
celeron55 |
it hanged very often, and now i tried at least 10 times without hang |
| 18:41 |
sapier |
ok I already squashed the commits, once vanessae put that version in duty and can confirm it works for her too I'm gonna merge it |
| 18:42 |
celeron55 |
i can see it when it takes 0.5 seconds instead of 0 |
| 18:42 |
celeron55 |
it happens like half of the time |
| 18:42 |
celeron55 |
well, 30% of time |
| 18:43 |
sapier |
the original bug isn't fixed |
| 18:43 |
celeron55 |
add a comment on that hack that it's a hack and why it's there |
| 18:43 |
sapier |
ok |
| 18:46 |
sapier |
lol ... I guess I should've written this comment earlier, I think I know what happens |
| 18:47 |
|
khonkhortisan joined #minetest-dev |
| 18:47 |
|
NakedFury joined #minetest-dev |
| 18:49 |
sapier |
no ... my idea doesn't match code :-( |
| 18:53 |
celeron55 |
i don't really understand why you can't trigger what the timeout triggers without using the timeout for it |
| 18:53 |
celeron55 |
what the timeout does is... deletes the server peer |
| 18:54 |
celeron55 |
no less, no more |
| 18:54 |
sapier |
yes but the send thread doesn't acually know anything about what it's sending |
| 18:55 |
celeron55 |
i reallyy think the timeoeut patch is just fine |
| 18:55 |
sapier |
actually it shouldn't be necessary to wait for timeout as the thread is supposed to exit if it's requested to exit and there's no unreliable packet left to be sent |
| 18:55 |
celeron55 |
-y |
| 18:55 |
celeron55 |
maybe just change it to having a timeout of 0 |
| 18:56 |
sapier |
I fear using 0 might cause disconnect not beeing sent in real client/server usecase |
| 18:56 |
celeron55 |
well let it be 0.5 then |
| 18:56 |
celeron55 |
it's fine goddamnit! |
| 18:57 |
celeron55 |
if there's a minor problem caused by it, it can be fixed later when somebody investigates it and sees the comment about the hack |
| 18:57 |
sapier |
:-) it's like always when you "just want to do this little fix" ;-) |
| 18:58 |
sapier |
It'd be interesting if other have that hang too :-) |
| 18:58 |
|
EvergreenTree joined #minetest-dev |
| 18:58 |
|
EvergreenTree joined #minetest-dev |
| 19:00 |
celeron55 |
the next question is, what block sending settings work but are fast or is there need for some kind of feedback from the network layer to the block selector |
| 19:01 |
celeron55 |
a long way back in time it actually had such; it controlled the "block send window" based on how much stuff the network layer had in queue |
| 19:01 |
celeron55 |
i think it currently does not have that |
| 19:01 |
sapier |
I could make block layer just drop unreliables once queue is full |
| 19:02 |
sapier |
ahh network layer |
| 19:02 |
sapier |
but I'd have to queue unreliables per peer in this case ... I already was about to implement this |
| 19:02 |
celeron55 |
currently the block sending window is a static configurable value, namely max_simultaneous_block_sends_per_client and max_simultaneous_block_sends_server_total (the latter of which should really be removed, it's useeless) |
| 19:04 |
celeron55 |
and the client replies only after it has generated the mesh of the block, because on some computers it's the bottleneck and the block sending has no sane reason to overload it |
| 19:04 |
celeron55 |
i'm referring to the node placement delay you mentioned with the settings |
| 19:05 |
sapier |
hmm that could explain why I've seen that much lag with your config setting |
| 19:05 |
sapier |
:-) same thought |
| 19:06 |
celeron55 |
the network has a queue for reliable packets, right? |
| 19:06 |
|
salamanderrake joined #minetest-dev |
| 19:06 |
celeron55 |
i mean the low-level protocol implementation |
| 19:06 |
celeron55 |
and if that queue gets filled up, then node placement gets laggy |
| 19:06 |
sapier |
yes |
| 19:06 |
sapier |
actually it's multiple queue levels |
| 19:07 |
sapier |
first of all theres the bottleneck connection queue all commands have to pass it |
| 19:07 |
sapier |
receive thread catches all commands from this queue and requeues the reliables per peer |
| 19:07 |
celeron55 |
two options: use a different higher-priority channel for node placements, making block sending sometimes out of sync because there are no timestamps in our data, or just lower the block sending window based on send queue size |
| 19:07 |
sapier |
unreliables are just put to packet send queue |
| 19:08 |
sapier |
we have 3 channels, 1 high 2 medium 3 low prio |
| 19:08 |
celeron55 |
third option: find some value that usually works but is a bit higher than the current one |
| 19:08 |
celeron55 |
sapier: the node placements are currently in the same channel as block transfer, right? and it's because of keeping them in sync |
| 19:09 |
sapier |
I don't know but if this is true we could just move block transfer to a lower prio |
| 19:09 |
celeron55 |
then they can get out of sync unless we add timestamps to blocks and single-node modifications; it's an issue with tcp+udp too |
| 19:09 |
celeron55 |
and with enet too if it's channels are used similarly |
| 19:10 |
sapier |
yes |
| 19:10 |
celeron55 |
actually in tcp there is only one stream... |
| 19:10 |
sapier |
I put channels on top of it |
| 19:10 |
celeron55 |
so nodes will need to go in reliable udp |
| 19:10 |
celeron55 |
oh, maybe that fixes it enough there |
| 19:11 |
celeron55 |
assuming OSes allow you to minimize OS buffer sizes |
| 19:11 |
sapier |
of course if a prio 3 packet is already about to be sent It has to be completed prior sending a prio1 packet |
| 19:12 |
celeron55 |
can you try putting blocks in a low-priority channel? |
| 19:12 |
sapier |
I already send blockdata at lowest prio (at least in to client direction) |
| 19:13 |
sapier |
and addnode is sent at highest prio ... lets have a look about the responses |
| 19:13 |
celeron55 |
umm... so where's the queueing happening |
| 19:14 |
sapier |
maybe it's the connection bottleneck |
| 19:15 |
celeron55 |
how do you see the lag |
| 19:16 |
sapier |
I place a node it's shown as gridbox only, some seconds later it vanishes completely and will reappear even more seconds later |
| 19:16 |
celeron55 |
oh that means your mesh generation is overloaded |
| 19:16 |
celeron55 |
network isn't lagging |
| 19:17 |
sapier |
I thought so as there's no difference between rudp(mt) tcp and enet |
| 19:17 |
xyz |
are you running release build? |
| 19:17 |
sapier |
no |
| 19:17 |
xyz |
well, that's why |
| 19:17 |
celeron55 |
with -O0 it's bound to be slow as it's a heavy CPU-based algorithm |
| 19:18 |
sapier |
I've got -O1 ... remember the pretty printing gdb issue :-( |
| 19:18 |
xyz |
sapier: have you managed to get intel vtune to run? |
| 19:18 |
celeron55 |
algough i guess with -O1 it should already be fast enough |
| 19:18 |
sapier |
no I switched to gprof |
| 19:18 |
xyz |
alright |
| 19:18 |
celeron55 |
we can't rely on it being fast enough though; how do we handle that |
| 19:18 |
sapier |
I guess it's not as good as vtune but way more simple to use |
| 19:18 |
xyz |
vtune is really simple |
| 19:19 |
sapier |
maybe if I'd manage to start it xyz :-) |
| 19:19 |
xyz |
/opt/intel/vtune_amplifier_xe/bin64/amplxe-cl -collect hotspots -run-pass-thru=-timestamp=sys -r /tmp/vtune.du ~/minetest/bin/minetestserver --worldname nonbloat --disable-unittests |
| 19:19 |
celeron55 |
sapier: what values did you use for those max_simultaneous_block_sends_*? |
| 19:19 |
xyz |
well, this probably means you've done something wrong D: |
| 19:19 |
xyz |
sapier: what was the issue? |
| 19:20 |
sapier |
I don't have a bin64 folder |
| 19:20 |
sapier |
oh wait, I'm just blind |
| 19:23 |
sapier |
hmmm minetest doesn't seem to come up using that command line xyz |
| 19:23 |
xyz |
sapier: are you sure you have world named nonbloat? |
| 19:24 |
xyz |
are you sure you have ~/minetest/bin/minetest? |
| 19:24 |
sapier |
I started gui |
| 19:25 |
sapier |
not opening up any world at beginning |
| 19:25 |
xyz |
well then what's written in the log? |
| 19:25 |
xyz |
on terminal |
| 19:26 |
xyz |
I guess you're still doing something weird; just try the GUI |
| 19:26 |
sapier |
last line is GLSL version: 3.3 ... so pretty normal startup for minetest ... except the window isn't shown at all |
| 19:26 |
xyz |
ah, that's strange |
| 19:26 |
sapier |
ok to be precise the window content isn't shown |
| 19:27 |
sapier |
do I have to build it in a special way? |
| 19:27 |
xyz |
no |
| 19:27 |
sapier |
gprof requires special build |
| 19:27 |
xyz |
try running minetestserver |
| 19:28 |
sapier |
but I gprof did at least show the tcp thread to use cpu power, same thing vtune said |
| 19:28 |
celeron55 |
sapier: can you answer? |
| 19:28 |
celeron55 |
two numbers |
| 19:29 |
sapier |
I used the numbers you gave me yesterday, I don't have them here but I'll have a look in log |
| 19:29 |
xyz |
you could also try building a kernel module and running advanced hotspots |
| 19:29 |
celeron55 |
oh okay, those are 1000 and 100 then |
| 19:29 |
celeron55 |
they are overly high and probably more suitable for causing network bugs than gameplay 8) |
| 19:30 |
sapier |
http://paste.ubuntu.com/6705020/ this config |
| 19:30 |
xyz |
well do know that running advanced hotspots test could freeze your PC if your CPU is no good |
| 19:31 |
sapier |
hmm as I've got a amd cpu I guess this will fit "not good cpu" as of intel perspective :-) |
| 19:31 |
celeron55 |
when you have time, try something like max_simultaneous_block_sends_per_client=16 and verify that it doesn't overload your -O1 mesh generation |
| 19:32 |
celeron55 |
this is really one thing i need to consider to send to the server in addition to the viewing range |
| 19:32 |
xyz |
sapier: not sure about amd, but I think it'll work fine |
| 19:32 |
sapier |
16 and 160 maybe? |
| 19:32 |
celeron55 |
the server one shall be 10000; we don't need it |
| 19:32 |
sapier |
hmm should have no effect with single client |
| 19:34 |
celeron55 |
(it's effectively set by the maximum user count multiplied by the per-client value) |
| 19:34 |
sapier |
hmm still feels a little bit slower then before but I could misinterpret it |
| 19:34 |
celeron55 |
freeminer uses 10 i think |
| 19:34 |
celeron55 |
current default is 4 |
| 19:34 |
sapier |
visible delay but usually < 1s |
| 19:35 |
sapier |
with 16 |
| 19:35 |
sapier |
I'm trying 4 now |
| 19:35 |
celeron55 |
but it's good to know that it's not a network issue but rather a mesh generation issue; it probably needs to be dynamically figured out by the client |
| 19:37 |
sapier |
ok with 4 it's almost gone increasin if I use 8 and 12 |
| 19:39 |
proller |
ettings->setDefault("max_simultaneous_block_sends_per_client", "20"); |
| 19:39 |
proller |
fm ^ |
| 19:40 |
sapier |
I could live with 16 but I don't know about what minimum system requirement we target |
| 19:43 |
|
w_laenger joined #minetest-dev |
| 19:44 |
|
w_laenger left #minetest-dev |
| 20:02 |
sapier |
I'd assume stable 25 fps as least to be called "playable" |
| 20:03 |
|
kahrl_ joined #minetest-dev |
| 20:04 |
sapier |
VanessaE john_minetest could you try https://github.com/minetest/minetest/pull/1090 I'm gonna merge them if you both can confirm it works |
| 20:17 |
celeron55 |
john_minetest: often games are rated for "minimum" and "recommended" because it's kind of arbitrary |
| 20:18 |
celeron55 |
for minetest minimum is "your smartphone" and recommended is "any new computer" 8) |
| 20:28 |
|
werwerwer joined #minetest-dev |
| 20:43 |
|
sapier1 joined #minetest-dev |
| 20:48 |
|
Jordach joined #minetest-dev |
| 20:57 |
VanessaE |
sapier: I will give it a try soon |
| 20:57 |
VanessaE |
still trying to catch up with some other stuff, in a manner of speaking. |
| 20:58 |
VanessaE |
(1090 that is) |
| 21:02 |
sapier |
basically it's a complete network connection rewrite |
| 21:03 |
sapier |
should fix issues with lag and on downloading huge amounts of data |
| 21:03 |
sapier |
actually you have to use it on server to have a real effect |
| 21:04 |
sapier |
but of course you should still be able to connect to old servers as good/bad as before |
| 21:27 |
celeron55 |
i started a server at c55.me:30002 running that branch |
| 21:27 |
celeron55 |
it has NeuromancerGame so you could clear cache and see how infinitely long it still takes to pull all the stuff |
| 21:27 |
celeron55 |
(my uplink is 1Mb/s) |
| 21:28 |
celeron55 |
(i would've rather ran nodetopia but it's too lightweight for this test) |
| 21:29 |
sapier |
do you use old client to connect? |
| 21:30 |
celeron55 |
what? to connect where? |
| 21:30 |
sapier |
oh you suggested trying to connect :-) sorry thought you already tried :) |
| 21:31 |
celeron55 |
john_minetest: interested? |
| 21:34 |
sapier |
connecting too |
| 21:34 |
|
salamanderrake joined #minetest-dev |
| 21:35 |
sapier |
this doesn't feel right |
| 21:36 |
PilzAdam |
connecting... |
| 21:37 |
sapier |
ok my client uses compatibility mode but I'm on enet branch ... aborting and switching to 1090 |
| 21:37 |
PilzAdam |
or rather, trying to connect |
| 21:37 |
PilzAdam |
I cant even ping c55.me |
| 21:38 |
sapier |
I was able to transfer data |
| 21:38 |
ShadowNinja |
14 packets transmitted, 1 received, 92% packet loss, time 13003ms |
| 21:39 |
PilzAdam |
lol |
| 21:39 |
sapier |
92% loss? |
| 21:39 |
ShadowNinja |
^ Pinging c55.me. |
| 21:39 |
kaeza|toaster |
you killed c55 D: |
| 21:39 |
ShadowNinja |
There, it's at 0% now. |
| 21:39 |
sapier |
don't expect any protocol to do well with a connection beeing that bad :-) |
| 21:40 |
|
celeron55 joined #minetest-dev |
| 21:40 |
ShadowNinja |
It might have been that Minetest flooded the connection. |
| 21:40 |
|
Miner_48er joined #minetest-dev |
| 21:40 |
celeron55 |
23:37:31 <+sapier> this doesn't feel right |
| 21:40 |
celeron55 |
23:37:36 < celeron55> i wonder how long it takes |
| 21:40 |
celeron55 |
23:39:55 < celeron55> no this thing is too heavy, none of you is going to get it downloaded |
| 21:40 |
celeron55 |
23:40:09 < celeron55> please give up, i'll replace the game 8D |
| 21:40 |
celeron55 |
23:40:25 < celeron55> closing server |
| 21:40 |
celeron55 |
23:40:39 < celeron55> i am trying to install nethogs while doing this but the connection is all jammed up |
| 21:40 |
celeron55 |
23:40:46 < celeron55> so i can't even know the upload speed |
| 21:40 |
celeron55 |
23:41:05 < celeron55> the udp protocol clearly doesn't play nice with tcp 8) |
| 21:40 |
celeron55 |
it just hogs it all up and jams everything |
| 21:41 |
sapier |
wow :-) |
| 21:41 |
ShadowNinja |
Yep, I got 92% packet loss with ping. |
| 21:41 |
sapier |
at least we can now saturate the network link with minetest |
| 21:42 |
ShadowNinja |
Perhaps it should be limited a bit... |
| 21:42 |
celeron55 |
i removed the mobs mods from it, let's see now |
| 21:43 |
celeron55 |
oh, nethogs can't udp |
| 21:43 |
PilzAdam |
how much media do we have to download? |
| 21:43 |
PilzAdam |
I get ~80 Ki/B |
| 21:43 |
celeron55 |
still too much, probably |
| 21:43 |
sapier |
imho the only relevant thing is that new clients don't cause lag for others, it's up to server owner to take precautions a single service doesn't block others e.g. on linux you could use traffic control to fix it |
| 21:44 |
PilzAdam |
now its at 10 Ki/B |
| 21:44 |
celeron55 |
so how is the transfer going? 0%? |
| 21:44 |
PilzAdam |
done |
| 21:44 |
celeron55 |
i don't care about absolute speed, i care about if it finishes some day |
| 21:45 |
sapier |
I'm in |
| 21:45 |
sapier |
moving around and map is loading |
| 21:46 |
PilzAdam |
wow, that map loads fast |
| 21:46 |
PilzAdam |
(the already generated parts, I guess) |
| 21:46 |
celeron55 |
max_block_generate_distance = 12 |
| 21:46 |
celeron55 |
max_block_send_distance = 12 |
| 21:46 |
celeron55 |
max_simultaneous_block_sends_server_total = 1000 |
| 21:46 |
celeron55 |
max_simultaneous_block_sends_per_client = 10 |
| 21:46 |
celeron55 |
emergequeue_limit_diskonly = 50 |
| 21:46 |
celeron55 |
emergequeue_limit_generate = 50 |
| 21:46 |
celeron55 |
it uses those settings and runs on this insanely fast laptop |
| 21:47 |
celeron55 |
and a shitty ADSL |
| 21:47 |
PilzAdam |
what is "insanely fast"? |
| 21:47 |
celeron55 |
well the fastest you can get |
| 21:48 |
sapier |
I've got a rtt of 0.07s with max at 0.5 seconds |
| 21:48 |
sapier |
and average jitter arount 0.09 |
| 21:49 |
sapier |
I'm disconnecting and reconnecting to see if downloading causes lag for you |
| 21:50 |
PilzAdam |
yes, it does |
| 21:50 |
sapier |
pretty bad? |
| 21:50 |
PilzAdam |
the server doesnt react at all now |
| 21:50 |
sapier |
that's bad |
| 21:50 |
PilzAdam |
now it works again |
| 21:50 |
VanessaE |
celeron55: keep your eyes on the server's CPU usage while sapier is downloading media. |
| 21:51 |
sapier |
too late already finished |
| 21:51 |
PilzAdam |
and it hangs again because john joined |
| 21:53 |
sapier |
how much upload does your adsl connection have celeron? |
| 21:53 |
celeron55 |
around 1Mbps (should be) |
| 21:53 |
celeron55 |
outgoing traffic is quite variable at the moment |
| 21:54 |
celeron55 |
which is probably because people are moving around and it's transferring that large map area |
| 21:54 |
sapier |
oops ... guess I know where lag is from, I assume it's fine to send 1024 packets per send step ... roughly 4mbit |
| 21:54 |
sapier |
guess I should make this configurable |
| 21:55 |
sapier |
below this 4 mbit a equal distribution of packets for all peers isn't possible |
| 21:59 |
celeron55 |
make it configurable and let's see if it works perfectly then (i have doubts 8)) |
| 21:59 |
sapier |
what's perfect ;-) |
| 21:59 |
celeron55 |
constant rtt=0, 100% bandwidth usage |
| 21:59 |
sapier |
there's still a chance os internal buffers may overflow |
| 22:02 |
PilzAdam |
I get tons of 23:02:03: ERROR[main]: WARNING: before createPlayingSoundAt: invalid name |
| 22:02 |
PilzAdam |
and 23:02:03: ERROR[main]: WARNING: updateListener: invalid name |
| 22:02 |
sapier |
ok pushed |
| 22:02 |
PilzAdam |
probably all the fire |
| 22:02 |
sapier |
protocol can't fix client starting up prior receiving all media |
| 22:03 |
celeron55 |
okay, i'll update the server |
| 22:03 |
sapier |
max_packets_per_iteration is the setting you should change |
| 22:03 |
sapier |
I'd reduce it to 256 at first try |
| 22:03 |
celeron55 |
maybe 500 |
| 22:04 |
VanessaE |
bbl |
| 22:04 |
sapier |
500*512bytes in worst case |
| 22:04 |
sapier |
actually 552 bytes |
| 22:04 |
sapier |
ähhm 554 ... :-) |
| 22:04 |
celeron55 |
hmm oh, so it should be set to 100000/512 |
| 22:05 |
celeron55 |
let's see what happens at 200 |
| 22:05 |
sapier |
it's not per second so this isn't exact but I think it's a good guess |
| 22:06 |
celeron55 |
or, well, that'd be for 100kBps uplink |
| 22:07 |
sapier |
actually that number is only used to calculate how much packets for a single peer are queued in a single step prior next peers packets are queued |
| 22:07 |
celeron55 |
why is it so high? |
| 22:07 |
celeron55 |
the default |
| 22:08 |
sapier |
seemed to be fine on localhost :-) ... maybe wrong testcase |
| 22:08 |
celeron55 |
lol |
| 22:08 |
celeron55 |
"let's assume servers have 1000MBps uplink" |
| 22:09 |
celeron55 |
"localhost has!" |
| 22:09 |
sapier |
vanessaE didn't complain about it too but I guess she's got plenty of upstream too |
| 22:09 |
celeron55 |
anyway it's running now |
| 22:09 |
celeron55 |
try to join simultaneously for maximum effect |
| 22:09 |
celeron55 |
john_minetest! |
| 22:09 |
sapier |
joining |
| 22:10 |
sapier |
I think best testcase is some people beeing online and multiples downloading |
| 22:10 |
sapier |
if this works without lag it's pretty good |
| 22:10 |
sapier |
especially if this works on adsl line ;-) |
| 22:11 |
celeron55 |
iptraf reports upload at... ehm, that's a totally random number, 11000kbps |
| 22:11 |
celeron55 |
what the fuck man |
| 22:11 |
celeron55 |
well i won't have lag anyway as i'm local |
| 22:11 |
celeron55 |
we need a third tester |
| 22:11 |
sapier |
you will have lag |
| 22:11 |
sapier |
you're a client as all other clients |
| 22:12 |
sapier |
so you can starve like all others if there's a basic queuing error |
| 22:12 |
celeron55 |
well, i had no problems last time |
| 22:12 |
sapier |
woods are burning |
| 22:13 |
sapier |
lots of sound messages |
| 22:14 |
sapier |
is anyone else online? |
| 22:14 |
celeron55 |
i think burning down a NeuromancerGame forest is one of the most ridiculous ideas |
| 22:15 |
sapier |
here's fire all over |
| 22:16 |
pitriss |
If you need tester I can help if you want someone.. What i need? latest git client? |
| 22:16 |
sapier |
no 1090 |
| 22:16 |
sapier |
#1090 |
| 22:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/1090 -- Network fixes udp 1 by sapier |
| 22:17 |
sapier |
clear your cache and tell us once you start connecting |
| 22:17 |
pitriss |
oh ok.. so git pull + git apply this patch? |
| 22:18 |
celeron55 |
it might not apply directly, i'd add sapier as a remote and git checkout sapier/network_fixes_udp_1 |
| 22:19 |
sapier |
celeron55 how's your network utilization right now? |
| 22:20 |
celeron55 |
it's hard to tell because every monitoring tool reports something different |
| 22:20 |
sapier |
:-) |
| 22:20 |
celeron55 |
maybe i'll just ping google |
| 22:20 |
celeron55 |
ping to google is fine(-ish) at the moment |
| 22:21 |
sapier |
I get rtt's up to 2 seconds but those might be lost packets |
| 22:21 |
celeron55 |
there are some mobs walking around here |
| 22:21 |
celeron55 |
you might want to come watch them as they give good visual feedback of all kinds of lag |
| 22:24 |
sapier |
lol apples don't burn |
| 22:25 |
pitriss |
celeron55: can you guide me through that git woodoo? :) I'm not much skilled with git. I have pulled latest git now.. how i add sapier as remote? |
| 22:26 |
pitriss |
*how can |
| 22:26 |
celeron55 |
git remote add sapier https://github.com/sapier/minetest.git |
| 22:26 |
celeron55 |
git fetch sapier |
| 22:26 |
celeron55 |
git checkout sapier/network_fixes_udp_1 |
| 22:26 |
celeron55 |
then build and you have what we have |
| 22:26 |
celeron55 |
after that just checkout master to get back |
| 22:27 |
celeron55 |
john_minetest: can you rejoin now with cleared cache? |
| 22:31 |
pitriss |
ok building done.. |
| 22:31 |
pitriss |
So i will connect at c55.me 30002 ok? |
| 22:32 |
sapier |
yes |
| 22:32 |
sapier |
what about current lag? |
| 22:33 |
celeron55 |
yes, go ahead |
| 22:33 |
pitriss |
hmm hmm is it connecting? it is hang on connecting to server |
| 22:34 |
sapier |
give it time you need to download some textures |
| 22:35 |
pitriss |
ok i will wait.. |
| 22:36 |
sapier |
but you should see progress ;-) |
| 22:36 |
celeron55 |
it's outputting about half of the bandwidth according to one monitor, and something totally different according to something else |
| 22:36 |
celeron55 |
actually more like 25% |
| 22:36 |
celeron55 |
i wonder why it's so low |
| 22:37 |
pitriss |
then something go wrong.. |
| 22:37 |
pitriss |
should i have curl enabled? |
| 22:38 |
sapier |
doesn't matter |
| 22:38 |
sapier |
you just timed out pitriss |
| 22:38 |
pitriss |
ok.. weird.. |
| 22:39 |
sapier |
you're sure you built the right version? |
| 22:40 |
celeron55 |
i don't understand at all, but when sapier connects, one monitor says 1300 "Kps" and an another one says 10000 "kbps" |
| 22:40 |
pitriss |
yep I did everything as celeron55 wrot |
| 22:40 |
celeron55 |
both of which don't make any sense and the first doesn't even have a valid unit |
| 22:40 |
celeron55 |
john_minetest: ok |
| 22:40 |
sapier |
hmm strange |
| 22:41 |
pitriss |
ok i rebuilded client without curl.. |
| 22:41 |
pitriss |
now |
| 22:41 |
celeron55 |
the lag seems to be fairly minimal now though, with occasional spikes reported by john |
| 22:42 |
sapier |
guess some small short spikes are way better then before |
| 22:42 |
sapier |
especially if you consider we're on a adsl connection right now :-) |
| 22:42 |
pitriss |
ok I'm logged in.. |
| 22:48 |
celeron55 |
so should we take a comparison check with current master? |
| 22:48 |
celeron55 |
8) |
| 22:49 |
celeron55 |
i'm sure it will be completely awful; shutting down and building now |
| 22:50 |
celeron55 |
i guess clients don't need to be changed |
| 22:50 |
celeron55 |
this is mainly a server thing |
| 22:50 |
celeron55 |
aand running |
| 22:50 |
celeron55 |
don't clear cache yet... |
| 22:51 |
pitriss |
ahh too late |
| 22:51 |
celeron55 |
lol 8) it'll take forever plus infinite time |
| 22:51 |
celeron55 |
actually maybe not; it seems to be transferring quite fast (?) |
| 22:51 |
pitriss |
It looks good.. |
| 22:52 |
pitriss |
yep 3/4 done |
| 22:53 |
celeron55 |
sapier wasn't laggy when pitriss was joining |
| 22:53 |
sapier |
there are only 7mb of textures |
| 22:53 |
celeron55 |
it's a good test size, maybe |
| 22:54 |
sapier |
vanessae's game has 28mb |
| 22:54 |
celeron55 |
(it also contains some models and sounds) |
| 22:54 |
sapier |
do you experience lag right now? |
| 22:54 |
celeron55 |
i can't tell; there's really nothing moving |
| 22:54 |
celeron55 |
let me place some moving thing |
| 22:54 |
sapier |
place nodes |
| 22:55 |
celeron55 |
they have prediction |
| 22:55 |
sapier |
isn't enough on huge lag ... but pitriss as well as me use fixed client right now |
| 22:55 |
celeron55 |
i placed two mice 8) |
| 22:56 |
sapier |
I guess the effect isn't that big |
| 22:56 |
sapier |
almost done joining |
| 22:56 |
pitriss |
yep I didn't recompiled |
| 22:56 |
sapier |
but takes quite a lot more time |
| 22:56 |
celeron55 |
it might have more effect if you weren't in europe |
| 22:56 |
celeron55 |
as the old congestion control can't cope with high ping |
| 22:57 |
sapier |
I don't know how old one did work at all ... rtt usually isn't a indicator for congestion :-) |
| 22:57 |
celeron55 |
it's here and working 8) |
| 22:58 |
sapier |
:-) guess our test doesn't tell anything if old one did work in this usecase too |
| 22:59 |
pitriss |
should i recompile my client ? |
| 22:59 |
sapier |
I don't think that's gonna make a difference but we can try, I've got 0.4.8 around I use this one |
| 22:59 |
celeron55 |
yes i'm wondering why anything new was coded, this is just fine, lol 8D |
| 23:00 |
celeron55 |
i have to sleep now though and will shut down this computer the server is on |
| 23:00 |
sapier |
because it wasn't fine for vanessae celeron ;-) |
| 23:00 |
celeron55 |
i'm sure this helps for long-distance media and map transfers |
| 23:01 |
celeron55 |
this test didn't happen to include those |
| 23:01 |
|
Amaz joined #minetest-dev |
| 23:01 |
pitriss |
i can use some old 0.4.7 for test too..:) |
| 23:01 |
sapier |
true so we need to wait for vanessae to give feedback about the new variant, the old one seemed to fix her issues |
| 23:02 |
sapier |
0.4.8 client disconnected |
| 23:02 |
celeron55 |
ideally VanessaE would have joined this now |
| 23:02 |
celeron55 |
sleep -> |
| 23:02 |
sapier |
good night |
| 23:02 |
pitriss |
gn celeron55 |
| 23:03 |
|
Megaf joined #minetest-dev |
| 23:06 |
|
BlockMen left #minetest-dev |
