Time Nick Message 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 ShadowNinja http://ix.io/9Jf Pass pointed_thing to after_place_node. (Maybe this should be copied?) 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:56 ShadowNinja xyz: Well, getting on their LAN is easier than getting on their computer, so my point still stands. 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 06:01 celeron55 ShadowNinja: nobody refers to minetest_game issues here, so you could just change it to always link to minetest 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: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 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: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 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:37 sapier ok I pushed my next guess 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! 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 18:09 sapier celeron55 I give it a try, but I'd prefere to understand why this happens 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: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: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 :-) 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 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 20:02 sapier I'd assume stable 25 fps as least to be called "playable" 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: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: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 ShadowNinja It might have been that Minetest flooded the connection. 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 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