Minetest logo

IRC log for #minetest-dev, 2014-01-07

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext