| Time |
Nick |
Message |
| 00:25 |
Exio4 |
what if a mod is supposed to start "dedicated threads" with requested apis? |
| 00:25 |
Exio4 |
i mean, for the multithread problem |
| 00:27 |
Exio4 |
but if it is just that way the thread overhead could be too high for more than a few mods :P |
| 00:49 |
hmmmm |
so as an interim solution, i wonder how well it would work to have a lock for each MapSector and use a lock-free hashtable for the Map structure itself |
| 00:49 |
hmmmm |
it shouldn't be very heavy (at least on unix-like systems where pthread_mutex_* is userspace only) |
| 01:35 |
|
kahrl joined #minetest-dev |
| 02:15 |
|
stormchaser3000 joined #minetest-dev |
| 02:47 |
|
kaeza joined #minetest-dev |
| 04:04 |
|
jin_xi joined #minetest-dev |
| 04:10 |
|
smoke_fumus joined #minetest-dev |
| 04:20 |
hmmmm |
sorta wondering if we should get rid of the MapSector and make Map just contain the MapBlocks itself |
| 04:20 |
hmmmm |
MapSector is from an old, bygone era of 0.3.x |
| 04:23 |
hmmmm |
so, EmergeThread is generating map, then it goes to blit each MapBlock back to Map -> allocates the MapBlocks, fills them up, then does the CAS into Map's hashtable. meanwhile a mod is trying to write there and ends up with a failure because it read just before the write could be completed... so can this situation be dangerous? |
| 04:24 |
hmmmm |
would a mod ever have logic such as if (block = minetest.getMapBlock(v3s16) == NULL) { createMapBlock(... blah blah blah) ? |
| 04:25 |
hmmmm |
the ServerThread would never actually *need* do to anything like that |
| 04:26 |
VanessaE_ |
can't say I've ever heard of such a need but paramat is the expert really on that one |
| 04:26 |
VanessaE_ |
all my mapgen stuff has always done things "safely" |
| 04:27 |
hmmmm |
errr wtf am i saying... mods don't know about blocks, only get_node and set_node |
| 04:27 |
VanessaE_ |
exactly :P |
| 04:27 |
hmmmm |
so I guess what I really want to ask is: is it common for mods to try to set a node if get_node returns nil |
| 04:28 |
VanessaE_ |
yes actually |
| 04:28 |
VanessaE_ |
but normally only in the case of a logic mistake |
| 04:28 |
hmmmm |
okay then that doesn't matter |
| 04:28 |
VanessaE_ |
remember that issue with leaves disappearing along mapblock edges? |
| 04:28 |
VanessaE_ |
(long since fixed of course) |
| 04:29 |
VanessaE_ |
moretrees had a similar bug as I recall, but in reverse |
| 04:29 |
VanessaE_ |
anyway yeah, what you've got in mind should be okay if I read it right |
| 07:10 |
|
PenguinDad joined #minetest-dev |
| 07:52 |
|
ImQ009 joined #minetest-dev |
| 07:54 |
|
darkrose joined #minetest-dev |
| 07:54 |
|
darkrose joined #minetest-dev |
| 08:03 |
|
SirDigby joined #minetest-dev |
| 08:11 |
|
proller joined #minetest-dev |
| 08:31 |
|
rsiska joined #minetest-dev |
| 10:03 |
|
grrk-bzzt joined #minetest-dev |
| 10:13 |
|
RealBadAngel joined #minetest-dev |
| 10:52 |
|
twoelk|2 joined #minetest-dev |
| 10:56 |
|
proller joined #minetest-dev |
| 11:00 |
|
restcoser joined #minetest-dev |
| 11:17 |
|
Shardvexz joined #minetest-dev |
| 11:22 |
|
rsiska joined #minetest-dev |
| 11:34 |
|
Exio4 joined #minetest-dev |
| 11:56 |
|
werwerwer joined #minetest-dev |
| 12:24 |
|
rsiska joined #minetest-dev |
| 12:57 |
|
Fresh_m__ joined #minetest-dev |
| 13:00 |
|
hmmmm joined #minetest-dev |
| 13:09 |
|
ImQ009 joined #minetest-dev |
| 13:21 |
|
PenguinDad joined #minetest-dev |
| 13:28 |
|
PilzAdam joined #minetest-dev |
| 13:32 |
|
rsiska joined #minetest-dev |
| 13:38 |
|
Garmine joined #minetest-dev |
| 15:07 |
|
Jordach joined #minetest-dev |
| 15:28 |
|
Exio4 joined #minetest-dev |
| 15:44 |
|
zat joined #minetest-dev |
| 15:47 |
|
Calinou joined #minetest-dev |
| 15:56 |
|
OldCoder joined #minetest-dev |
| 16:03 |
|
Shardvexz joined #minetest-dev |
| 16:07 |
|
tomreyn joined #minetest-dev |
| 16:14 |
|
rdococ joined #minetest-dev |
| 16:15 |
celeron55 |
hmmmm: mods running in their separate threads were considered originally, but was too much development overhead at that day's point of view |
| 16:16 |
|
kaeza joined #minetest-dev |
| 16:16 |
celeron55 |
hmmmm: i'm fairly sure it's a superior way of doing it but it necessiates a completely new way of making mods interoperate (that will have to be done with message passing) |
| 16:17 |
celeron55 |
it also forces a new group of mods, which is library-like mods |
| 16:18 |
celeron55 |
which run in as many copies as there are mod lua threads that want them |
| 16:18 |
celeron55 |
(so that they can provide direct interfaces for whatever they do) |
| 16:19 |
celeron55 |
think of inventory_plus |
| 16:28 |
celeron55 |
hmm, so it seems like threaded mods would be pretty good, even without initial support from the Map |
| 16:28 |
celeron55 |
and i'm at least personally fine with an asynchronous API (like what javascript APIs do all the time) |
| 16:30 |
|
proller joined #minetest-dev |
| 16:47 |
Megaf |
celeron55: You are quite correct |
| 16:48 |
Megaf |
Threaded mods are a quite welcome things and they can offer a gigantic performance boost, by simply not causing that huge performance lost they cause at the moment |
| 16:49 |
Megaf |
On my four core ARM CPU, I really can't make my minetestserver instance use more than 104% ofmy CPU |
| 16:49 |
sfan5 |
uhh |
| 16:49 |
Megaf |
and I believe is not actually the server process that is using the CPU, but some mod |
| 16:49 |
sfan5 |
1 (one core) can't have more than 104% |
| 16:50 |
sfan5 |
also can we not just have a C++ modding interface? |
| 16:50 |
Megaf |
so, if a mod could use more core, it will leave one whole core all for the server itself |
| 16:50 |
Megaf |
sfan5: yep, so I believe it uses 100% of one core and 4% of another core |
| 16:53 |
Megaf |
at the very moment minetestserver is using 109.3$ |
| 16:53 |
sfan5 |
oh god |
| 16:53 |
sfan5 |
how expensive |
| 16:53 |
Megaf |
However, it's avarage use is 18% |
| 16:53 |
sfan5 |
(you used $ instead of %) |
| 16:54 |
Megaf |
s/$/% |
| 16:54 |
Megaf |
better? |
| 16:59 |
|
diemartin joined #minetest-dev |
| 17:03 |
|
CraigyDavi joined #minetest-dev |
| 17:07 |
|
rsiska joined #minetest-dev |
| 17:07 |
Megaf |
According to 'top' minetestserver is using 9 threads at the moment |
| 17:12 |
Megaf |
my minetest.conf settings is set to num_emerge_threads = 4, I will increase that number |
| 17:14 |
Calinou |
how can I enable “give_initial_stuff†by default in a game? |
| 17:14 |
Calinou |
minetest.conf in the game directory does not seem to work for this |
| 17:14 |
Calinou |
only physics |
| 17:15 |
PilzAdam |
Calinou, user minetest.conf overrides game's minetest.conf |
| 17:15 |
|
rsiska joined #minetest-dev |
| 17:15 |
Calinou |
OK |
| 17:15 |
PilzAdam |
also, do you have the give_initial_stuff mod in the game? |
| 17:15 |
Calinou |
yes |
| 17:17 |
Calinou |
still does not work, I removed it from my minetest.conf |
| 17:18 |
Calinou |
oh, it works now |
| 17:18 |
Calinou |
thanks |
| 17:19 |
|
CraigyDavi joined #minetest-dev |
| 17:21 |
|
restcoser joined #minetest-dev |
| 17:22 |
|
Garmine joined #minetest-dev |
| 17:42 |
Megaf |
Interesting, now I set the number of threads to 16, minetestserver is now using 21 threads, and CPU usage is very load, down to 6% with one using mining and building |
| 17:43 |
sfan5 |
you can only set the number of emerge threads |
| 17:43 |
VanessaE_ |
megaf, never set that value higher than the number of cores you have, minus 2. |
| 17:43 |
sfan5 |
there are others too |
| 17:43 |
VanessaE_ |
(4 cores, set it no higher than 2) |
| 17:44 |
VanessaE_ |
and that ^^^^ is why. |
| 17:44 |
sfan5 |
CPU usage is very load |
| 17:44 |
sfan5 |
can someone explain that sentence? |
| 17:45 |
VanessaE_ |
I'm sure he meant "low". :P |
| 17:46 |
Megaf |
VanessaE_: indeed |
| 17:46 |
Megaf |
typo |
| 17:46 |
Megaf |
I'm not typing well today |
| 17:49 |
Megaf |
VanessaE_: I don't quite understand that. It just feels like minetest server is not very good with SMP |
| 17:54 |
|
nore joined #minetest-dev |
| 17:56 |
VanessaE_ |
Megaf: there are more threads going on in the minetest server than just the mapgen. you don't want to overshadow the rest of the server with the mapgen |
| 17:56 |
VanessaE_ |
and that setting is ONLY for the mapgen. |
| 18:01 |
|
Zeitgeist_ joined #minetest-dev |
| 18:01 |
|
Zeitgeist_ joined #minetest-dev |
| 18:07 |
celeron55 |
i am going to pick up voxel area entities to be the next really visible feature |
| 18:07 |
celeron55 |
any naysayers? |
| 18:07 |
|
iqualfragile joined #minetest-dev |
| 18:08 |
VanessaE_ |
works for me.. |
| 18:09 |
celeron55 |
as related to: https://forum.minetest.net/viewtopic.php?f=7&t=9147 |
| 18:11 |
iqualfragile |
technical question: does minetest create a mesh from the voxels and then render that or render multiple instances of a block for each material? |
| 18:11 |
iqualfragile |
or something else? |
| 18:13 |
celeron55 |
it generates an irrlicht mesh which consists of one meshbuffer per material(~=texture) |
| 18:13 |
iqualfragile |
how often is it rebuild? |
| 18:13 |
celeron55 |
with auto-generated texture atlases it could be closer to one meshbuffer per mapblock |
| 18:14 |
celeron55 |
every time it changes |
| 18:14 |
iqualfragile |
so its one mesh per mapblock per material atm? |
| 18:14 |
celeron55 |
yes; in the opengl sense of things (where mesh = vertex array) |
| 18:15 |
iqualfragile |
ok, great, because to my understanding the main issue with octrees is that you would have to traverse them on every render, which would notbe the case in this case |
| 18:15 |
iqualfragile |
right? |
| 18:16 |
celeron55 |
if there is any extra slowness in access time compared to the current speed, it's not going to work well |
| 18:17 |
iqualfragile |
well, it would be log(n) instead of 2 |
| 18:19 |
iqualfragile |
you would need about 7 comparisions to reach a positon |
| 18:19 |
iqualfragile |
or would you? |
| 18:19 |
iqualfragile |
nah, not really, as you could just take a or some subtrees which contain your local area |
| 18:20 |
iqualfragile |
so you would need to traverse about ?6? layers |
| 18:20 |
celeron55 |
it doesn't make any sense to store mapblock contents in an octree; they are so small that large parts of them fit to CPU cache which makes them blazing fast |
| 18:21 |
celeron55 |
if you want to try using an octree for something, try the mapblock storage itself |
| 18:22 |
iqualfragile |
but that would not make too much sense, would it?, the great advantage about an octree is to be able to store bigger blocks consisting of one material in less space |
| 18:23 |
celeron55 |
so you are running out of memory with minetest but have extra CPU time to spare? |
| 18:23 |
celeron55 |
i don't believe that |
| 18:24 |
iqualfragile |
i would be if i would decide to divide the currently existing blocks twice |
| 18:24 |
celeron55 |
on the client generally the most space is consumed by the meshes, if my calculations are correct |
| 18:25 |
iqualfragile |
so map storage is it then |
| 18:25 |
celeron55 |
or, similarly much as by the blocks |
| 18:25 |
iqualfragile |
(because minetest maps are quite big) |
| 18:26 |
celeron55 |
you can try anything though, if it turns out to be measurably better without drawbacks, of course it will be used |
| 18:30 |
celeron55 |
i wonder how much weight should be put in a multithreaded modding api |
| 18:30 |
celeron55 |
it might not require that much work to implement, considering sapier has already done something relateed with the main menu |
| 18:31 |
iqualfragile |
i really fear that it would make all the mods crash all the time |
| 18:31 |
iqualfragile |
right now people do not even catch nul pointers |
| 18:31 |
celeron55 |
it would make minetest not need to crash if a mod crashes |
| 18:31 |
celeron55 |
and it would allow mod unloading at runtime |
| 18:32 |
iqualfragile |
sounds good, but it would imply a split of definitions and coding of mods (which i would be happy about) |
| 18:32 |
celeron55 |
imply what? |
| 18:32 |
iqualfragile |
s/imply/require/ |
| 18:33 |
celeron55 |
oh ah, you mean like registering nodes |
| 18:33 |
iqualfragile |
yes, exactly |
| 18:34 |
iqualfragile |
definition := there is something, uses these textures/that model |
| 18:34 |
celeron55 |
this is a good point; the mods might still need a part that initializes them that is not run in a separate thread |
| 18:34 |
celeron55 |
and that part cannot be unloaded |
| 18:34 |
iqualfragile |
i personally think it was kinda wired to even put that stuff into lua in the first place |
| 18:34 |
Anchakor |
have you guys given up on farmesh-like stuff? |
| 18:34 |
iqualfragile |
Anchakor: yes |
| 18:35 |
celeron55 |
Anchakor: it's not a priority |
| 18:35 |
iqualfragile |
visit #freeminer, i think they are implementing something like that |
| 18:35 |
Anchakor |
saw this lately http://www.reddit.com/r/VoxelGameDev/comments/2398aw/voxel_model_octree_lod_mesh_texture_storing/ |
| 18:36 |
iqualfragile |
oh, right, sacrificing a bit of memory an octree could actually save quite some memory by saving the median value of an subtree in that node and not loading any more if you are far away |
| 18:37 |
iqualfragile |
(i hope that was formulated understandable |
| 18:37 |
iqualfragile |
) |
| 18:37 |
celeron55 |
but my question really was not anything about the details of threaded mods but instead i wanted to ask whether they are important |
| 18:38 |
celeron55 |
~tell sapier can you give an assessment on how hard implementing the base thing in those would actually be? it's hard to have a good opinion without any facts |
| 18:38 |
ShadowBot |
celeron55: O.K. |
| 18:39 |
iqualfragile |
what would the advantages be? loading/unloading at runtime would have limited use in my opinion as minetest takes about 2 secs to restart |
| 18:39 |
iqualfragile |
single mod crashing |
| 18:40 |
celeron55 |
the advantage is that the server execution wouldn't have 5 second pauses due to a mod doing something |
| 18:40 |
celeron55 |
which is completely unacceptable and is not repairable in any other way |
| 18:40 |
celeron55 |
because some mods just have to process a lot of stuff |
| 18:41 |
|
Megaf joined #minetest-dev |
| 18:41 |
celeron55 |
the server choppiness actually limits minetest a lot; for example clients can't have smooth movement because the server just isn't there to transfer the continous data |
| 18:41 |
|
Guest71509 joined #minetest-dev |
| 18:41 |
iqualfragile |
i can mostly, but not fully agree with that, but just allowing mods to start a thread "manually" would be suffient i think |
| 18:41 |
|
hax404 joined #minetest-dev |
| 18:42 |
iqualfragile |
+c |
| 18:42 |
celeron55 |
it will be optional because dropping backwards compatibility isn't likely needed (it would provide almost no benefits) |
| 18:43 |
iqualfragile |
just allowing mods to spawn a thread sounds like a lot less work then to change the whole thing |
| 18:44 |
celeron55 |
it can't be implemented by changing the thing; in practice you just add to it in order to make it happen |
| 18:44 |
iqualfragile |
what? |
| 18:44 |
celeron55 |
the way how the mod sees it can be a change or addition though, maybe it indeed should be strictly an addition |
| 18:45 |
iqualfragile |
i am a bit slow atm, litle sleep, just ate lots of food, sorry about that |
| 19:08 |
|
restcoser joined #minetest-dev |
| 19:16 |
|
BlockMen joined #minetest-dev |
| 19:28 |
BlockMen |
sapier, game pause in singleplayer does not work anymore since the formspec fix |
| 19:36 |
|
sapier joined #minetest-dev |
| 19:41 |
sapier |
Blockmen I'm gonna check pause in singleplayer, can't be a big deal |
| 19:44 |
sapier |
Celeron55 I'm not sure if It's only me but once people talk about mod threading I always have feeling they think all performance issues will vanish at once ... that's not gonna be true. In fact for what I know mods most mods out there will even cause more lag if done in separate threads. There are mods out there wich would really benefit. But those mods would have to be completely rewritten to gain any benefit. |
| 19:44 |
sapier |
And they could already be rewritten to do way better. |
| 19:46 |
sapier |
Creating fully separated mods using message passing methods for mod communication will render all mods useless. And as you said we need to find whole new ways for communication as well as common used data ... rough estimation for base code is about 1-2 months of development (full time) ... then about half a year to get it stable and feature complete |
| 19:46 |
sapier |
I can't even guess effort required by mods |
| 19:47 |
|
nore joined #minetest-dev |
| 19:47 |
sapier |
and of course the basic issue required for all multithreading is added too ... map locking |
| 19:48 |
sapier |
I guess that's gonna be additional 1-2 months ... but we need this for any really usefull multithreaded thing so I don't mix it up |
| 19:49 |
sapier |
on the other hand the asynchronous job based aproach (my personal preference so this estimation may be biased) |
| 19:50 |
sapier |
we already have most code for it in I guess making it available for mods is only a couple of days. To get it at least somewhat usefull I assume we need to enable it to allow vmanip operations. give that another half a week. |
| 19:52 |
sapier |
imho things like mapgens and maybe pathfinding could be done with async job based mechanisms too. I don't have benchmarks to proove this by now true |
| 19:53 |
sapier |
spawn algorithms could be done in async (with vmanip support) too |
| 19:54 |
proller |
vmanip = lot of copied data |
| 19:54 |
sapier |
that's true proller but memory is cheap |
| 19:54 |
sapier |
and better work on a copy then locking map causing main thread to hang too |
| 19:55 |
proller |
what if other thread change copied block? |
| 19:55 |
sapier |
of course it'd be better to have a database providing a shadow copy mechanism but that's gonna be way more work |
| 19:56 |
|
cg72 joined #minetest-dev |
| 19:56 |
sapier |
well the only way to prevent this is either lock whole map ... then we don't need to do the threading work |
| 19:57 |
sapier |
or improve database for smaller locking |
| 19:58 |
sapier |
e.g. transactions would be an option, tell map "i need block xyz > abc" and if someone changes that block you're told about it and have to do your operations again |
| 19:59 |
sapier |
if someone changes it before you're done |
| 20:00 |
sapier |
but that's not really mod related but map/database thingy |
| 20:00 |
VanessaE_ |
minor topic change. the problem megaf is having with clients timing out and causing a cascade of timeout-server-lockup errors seems to be spreading. cg72 came here to report the same issue but I forgot to warn her of the webchat being muted in this channel. |
| 20:01 |
proller |
connection buggy? woow! |
| 20:01 |
VanessaE_ |
shut up, proller. |
| 20:01 |
proller |
i know how to fix |
| 20:02 |
sapier |
megaf's initial issue is already fixed |
| 20:02 |
VanessaE_ |
if it involves reverting some commit or another, then it's not a fix. |
| 20:02 |
proller |
revert bug bunch of shitcode |
| 20:03 |
iqualfragile |
there are lots of reverts lately |
| 20:03 |
iqualfragile |
should/can we apply to gsoc '15? |
| 20:03 |
ShadowNinja |
iqualfragile: only remember two within a few months. |
| 20:03 |
sapier |
no it's just prollers regular background noise of reverts ;-) |
| 20:04 |
ShadowNinja |
celeron55: ^ He actually owns the nick troller... |
| 20:04 |
iqualfragile |
yeah, me, too about 2 |
| 20:04 |
ShadowNinja |
And IMO a few reverts are better than code sitting around unmerged for months. |
| 20:04 |
proller |
wtf in logs? 00:04:21: ERROR[ConnectionSend]: con(4/1)RunTimeouts(): Peer 6 has timed out. (source=peer->timeout_counter) |
| 20:05 |
iqualfragile |
can just restate it: the core devs would just need to meet once a week and discuss a few pull requests |
| 20:05 |
iqualfragile |
regulary |
| 20:05 |
iqualfragile |
that would solve lots of issues |
| 20:06 |
Megaf |
There's a Hang Out for that |
| 20:06 |
sapier |
proller your peer 6 didn't answer for 5 seconds |
| 20:06 |
proller |
woow? |
| 20:06 |
proller |
whhy 100+ in logs? |
| 20:06 |
iqualfragile |
Megaf: well, it does not seem to be working well |
| 20:07 |
sapier |
that's good question peer id's should be rotated so peerid 6 shouldn't be reused for quite some time |
| 20:07 |
proller |
sapier, stop touching connection while you not use it |
| 20:07 |
sapier |
can you provide a log? |
| 20:08 |
sapier |
as always proller I'll help if you give me chance to help, I can't do anything if you refuse to get support |
| 20:08 |
proller |
start public server and look |
| 20:08 |
Megaf |
sapier: I can provide a virtual server |
| 20:09 |
proller |
you cant help blindy change code and not viewing at result |
| 20:09 |
Megaf |
but I think you can host your own server, cant you? |
| 20:09 |
sapier |
I've got only dsl 3000 that's not a base for a public server |
| 20:09 |
proller |
its very good base |
| 20:10 |
sapier |
no it isn't especially as that line us usually maxed out by other ppl using same line |
| 20:10 |
BlockMen |
how is 3000kbit/s good? |
| 20:11 |
sapier |
downstream 3000 |
| 20:11 |
sapier |
upstream hmm 192? |
| 20:11 |
Megaf |
my server is hosted on a 100 KB/s upstream link |
| 20:11 |
sapier |
no it's 384 |
| 20:11 |
sapier |
hmm ok that might explain your timeout's megaf ;-) |
| 20:12 |
|
casimir joined #minetest-dev |
| 20:12 |
Megaf |
I don't think so |
| 20:12 |
Megaf |
I used to host much more complex games with much more load without prolbems |
| 20:13 |
sapier |
but most important issue is It's not usefull to run a testing server and have 99% of issues caused by line stuffed with other things then minetest |
| 20:14 |
celeron55 |
as a fact minetest should be able to work on a 100kB/s upstream link |
| 20:14 |
celeron55 |
if it doesn't, that's a bug that must be fixed |
| 20:15 |
sapier |
yes with about 5 players that's gonna work ... as long as you really have that 100kb upstream |
| 20:15 |
celeron55 |
yes, that's fine |
| 20:16 |
celeron55 |
anyway, if you do network stuff, run a server; it can only help |
| 20:16 |
sapier |
but my line has a typical downstream usage of about 400-600GB downstream per month ... I assume that's gonna tell about it's typical load without even calculating the details |
| 20:17 |
proller |
porn! |
| 20:17 |
Megaf |
lol |
| 20:17 |
proller |
minetest better than porn! |
| 20:18 |
VanessaE_ |
600GB/mo downstream? eep |
| 20:18 |
VanessaE_ |
that's a fuckload of porn :P |
| 20:18 |
sapier |
well as that line is used by my little brother too that guess could even be real |
| 20:19 |
Anchakor |
you could share the porn to reduce the usage, just sayin :) |
| 20:20 |
sapier |
well as eveything is streaming data lately sharing is quite difficult ... even squid is unable to cache streams ;-) |
| 20:21 |
Megaf |
sapier: I will set up a real server at my home so you can use it |
| 20:22 |
Megaf |
and you better optmize the code, its a 950 MHz AMD Duron CPU XP |
| 20:22 |
Megaf |
I think you wouldnt want it |
| 20:22 |
sapier |
thank's megaf, I'm thankfull for any bugreports (especially as those contain logs) |
| 20:23 |
Megaf |
sapier: but really, 100 KB/s of upstream is more than enough |
| 20:23 |
sapier |
single core? puuuhh ... all the connection optimizations have been targeted at beeing able to use multiple cores more efficient |
| 20:23 |
Megaf |
I can host 15 users with that upstream |
| 20:23 |
Megaf |
my biggest problem is missutilizations of the ARM cores |
| 20:24 |
proller |
and now super multithread connection can transfer 10gbps ? |
| 20:25 |
sapier |
if you have a device that fast you could give it a try ... I'd be interested at the results |
| 20:25 |
|
CraigyDavi joined #minetest-dev |
| 20:25 |
proller |
now its only 1-3 mbps on localhost |
| 20:25 |
proller |
try yourself |
| 20:26 |
proller |
singlethread enet give me 30-50 megabytes per second |
| 20:27 |
proller |
maybe your "optimizations" needs revert? ;) |
| 20:27 |
sapier |
It's way better for me on singleplayer but I found out that it's gonna perfom better with more players too |
| 20:27 |
proller |
how much ? |
| 20:27 |
sapier |
but I had way less performance with previous implementation |
| 20:27 |
proller |
prev was more stable |
| 20:27 |
sapier |
that's a lie |
| 20:28 |
sapier |
I was never able to download even 10 mb of textures with previous implementation |
| 20:28 |
proller |
you newer plays in multiplayer, how you detect "lie" ? |
| 20:28 |
proller |
it was wery slow, but stable |
| 20:28 |
proller |
and tunable to good speed |
| 20:29 |
VanessaE_ |
proller, in the old implementation, the engine was lucky to get 50 kbps. now it can do 10+ Mbps. without cURL. |
| 20:30 |
proller |
but you can play only 3 minutes to disconnect |
| 20:30 |
VanessaE_ |
and he has done multiplayer many times, on my servers. |
| 20:30 |
VanessaE_ |
my servers have *never* disconnected me unless I explicitly shut them down. |
| 20:30 |
proller |
what about other users? |
| 20:31 |
Megaf |
yay! I got briefly a 260% load on my server |
| 20:31 |
VanessaE_ |
I can't speak for other users. Some disconnect, some don't. |
| 20:31 |
Megaf |
increasing threads to 16 done the trick |
| 20:32 |
VanessaE_ |
Megaf: G*d damn it that thread setting IS FOR THE MAPGEN!! |
| 20:32 |
VanessaE_ |
and you can't set it higher than the number of cores that you have on your box or it does no good |
| 20:32 |
Megaf |
I don't care, increasing it theres lower avarage CPU usage and now it can use more cores |
| 20:33 |
Megaf |
VanessaE_: well, 100% = once core, 200$ two core |
| 20:33 |
sapier |
proller do you use freeminer or minetest? |
| 20:33 |
Megaf |
my server is a four core |
| 20:33 |
VanessaE_ |
you're not seeing a true measure or you're not doing a proper test of your server. |
| 20:33 |
VanessaE_ |
tru exploring new terrain and get back to us. |
| 20:33 |
VanessaE_ |
ARM is NOT a proper platform to run a server on! |
| 20:33 |
Megaf |
it is |
| 20:33 |
Anchakor |
it is |
| 20:34 |
VanessaE_ |
Not with the mods you run it isn't. |
| 20:34 |
proller |
arm good with freeminer 8) |
| 20:34 |
Megaf |
cheap, efficient and powerful enough |
| 20:34 |
sapier |
megaf I'm not sure if using more then 1 emerge thread is even supported by now |
| 20:34 |
proller |
pc bad too if you use mods |
| 20:34 |
sapier |
haven't there been issues? |
| 20:34 |
|
Eater4 joined #minetest-dev |
| 20:34 |
proller |
sapier, fm now use your connection |
| 20:34 |
Megaf |
17:32:37: ERROR[ConnectionSend]: con(5/1)RunTimeouts(): Peer 176 has timed out. (source=peer->timeout_counter) |
| 20:34 |
Megaf |
17:33:29: ERROR[ConnectionSend]: con(5/1)RunTimeouts(): Peer 172 has timed out. (source=peer->timeout_counter) |
| 20:35 |
Megaf |
No good |
| 20:36 |
|
Megaf joined #minetest-dev |
| 20:36 |
celeron55 |
what is the timeout, then? |
| 20:36 |
sapier |
peer not anwering for 5 seconds |
| 20:37 |
celeron55 |
previously it was 30 |
| 20:37 |
celeron55 |
also how does the new connection thing do pings? |
| 20:37 |
celeron55 |
does it send like my version did, and does it handle it like it did? |
| 20:37 |
sapier |
same as old one but at prio 1 channel |
| 20:38 |
celeron55 |
change the value to 30 and see if there are any more problems |
| 20:38 |
sapier |
ping is high priority so yes ... I'll check the timeout |
| 20:38 |
celeron55 |
it could be just that those people use some shitty connections |
| 20:38 |
celeron55 |
it's easy to go past 5 seconds in a mobile connection |
| 20:39 |
PenguinDad |
I wonder why I never timed out |
| 20:41 |
Megaf |
sapier: c55 is right, please do change the timeout for at least 15 seconds |
| 20:41 |
Megaf |
Or, is there any harm in increasing timeout? |
| 20:42 |
Megaf |
Those players timing out in my server are using tablets and phone, so it can be a shity wifi or 3g |
| 20:43 |
sapier |
wait I was wrong about the 5 seconds, that's ping timeout, not peer timeout peer timeout is still 30s |
| 20:44 |
sapier |
well it's called CONNECTION_TIMEOUT but it's peer timeout |
| 20:45 |
sapier |
ping timeout tells if we didn't receive a packet from that peer for 5 seconds we're gonna send a ping to make it send something |
| 20:45 |
celeron55 |
so ping _interval_ is 5s like it was, and the "the other end seems to be dead" timeout is still 30s |
| 20:45 |
celeron55 |
sounds like the issue is something else then |
| 20:46 |
sapier |
no ping is only sent if we didn't get anything so it's not really a inverval |
| 20:46 |
celeron55 |
well, it's an interval if nothing is sent |
| 20:47 |
celeron55 |
otherwise it postpones it as if it was a timeout... so it's both 8) |
| 20:47 |
sapier |
yes two possible reasons either client is really not responding ... or for some reason server doesn't process anything for 30 seconds |
| 20:47 |
celeron55 |
the server can easily lock up for 30 seconds |
| 20:47 |
celeron55 |
but my latest connection implementation absolutely always processed pings asynchronously |
| 20:47 |
sapier |
invalid packets don't reset timout counter |
| 20:47 |
celeron55 |
there was no way that the server thread could stop it |
| 20:47 |
celeron55 |
is there a way now? |
| 20:48 |
sapier |
yes ping as well as ping ack sending is done out of order to to prevent a stuffed queue from delaying pings too |
| 20:49 |
sapier |
of course I can't speak for os packet queueuing |
| 20:49 |
Megaf |
ok, there are two distinct messages ofplayer timeout on my logs |
| 20:49 |
celeron55 |
the reason for those issues has to be found even if it's going to be wontfix |
| 20:49 |
Megaf |
that one I pasted earlier |
| 20:49 |
sapier |
I fully agree celeron55 |
| 20:49 |
Megaf |
and PlayerNick has time out |
| 20:50 |
Megaf |
What' s the difference? |
| 20:50 |
sapier |
can you show me? |
| 20:51 |
Megaf |
hold on, I will paste bin |
| 20:51 |
celeron55 |
it's possible to enable very spammy logging for the connection in order to debug stuff |
| 20:51 |
sapier |
yes but that's gonna cause other issues ... logging isn't threadsafe |
| 20:52 |
sapier |
I had to add a lock around logging while developing it to get it at least somehow working ... did crash within minutes without it |
| 20:54 |
Megaf |
sapier: http://paste.debian.net/95322/ |
| 20:55 |
sapier |
the first one is low level timeout of peer, second one is player timing up a level higher (caused by the low level timeout) |
| 20:56 |
Megaf |
Does it really needs to show that twice then? |
| 20:57 |
sapier |
I don't think so but I don't think it's related |
| 20:58 |
sapier |
do we know about the client versions of the ppl timing out? |
| 20:58 |
Megaf |
May be some sort of tablet version |
| 20:58 |
|
Shardvexz joined #minetest-dev |
| 20:59 |
Megaf |
feromonas timed out twice there, he plays on windows |
| 20:59 |
|
NakedFury joined #minetest-dev |
| 20:59 |
sapier |
ok we know about some broken tablet versions out ther getting out of sync with sequence numbers (that's been one of the major bugs in old implementation too) |
| 20:59 |
sapier |
windows stable or some recent build? |
| 21:00 |
Megaf |
may be the stable version, but I canÂt be sure |
| 21:00 |
Megaf |
cant* |
| 21:01 |
Megaf |
gtg |
| 21:01 |
Megaf |
cya |
| 21:02 |
sapier |
ok |
| 21:07 |
|
Eater4 left #minetest-dev |
| 21:07 |
|
Eater4 joined #minetest-dev |
| 21:12 |
iqualfragile |
sfan5: have you taken a look at the backtrace? |
| 21:14 |
sfan5 |
not yet |
| 21:16 |
iqualfragile |
would be nice, i want to create renderings of the map regularly :D |
| 21:16 |
iqualfragile |
sapier: not entirely true, squid can with a lot of effort cache streaming data |
| 21:17 |
sapier |
hmm maybe but not with simple setup :-) I don't wanna learn how to max out squit too ;-) |
| 21:17 |
sapier |
ShadowNinja: are you sure you needed to revert the shifting too? |
| 21:19 |
iqualfragile |
sapier: i did, its horrible because too often in documentation or articles they make no difference between squid 2 and 3… |
| 21:23 |
iqualfragile |
enought ot :D |
| 21:24 |
|
twoelk|2 joined #minetest-dev |
| 21:25 |
celeron55 |
that getIntegerAsBlock revert is lame; it's not black magic - i don't understand why ShadowNinja doesn't understand what it does :P |
| 21:26 |
celeron55 |
and it isn't even messed up; it perfectly does what it was designed to do |
| 21:26 |
celeron55 |
the issue is that it wasn't designed to do what ShadowNinja thinks it should have been |
| 21:26 |
ShadowNinja |
celeron55: v3s16(0, -1, -1) -> fffffffffefff000 seems sane to you? |
| 21:26 |
celeron55 |
it doesn't operate on bit level |
| 21:26 |
celeron55 |
stop thinking it like that |
| 21:27 |
celeron55 |
it would be one design for it, but it doesn't work based on that design |
| 21:27 |
ShadowNinja |
sapier: Can you check #1226? I added function serialization. http://pastebin.ubuntu.com/7317714/ |
| 21:27 |
celeron55 |
but i'm just repeating myself; see the log when i described it |
| 21:27 |
ShadowBot |
ShadowNinja: Error: Delemiter not found. |
| 21:28 |
ShadowNinja |
https://github.com/minetest/minetest/pull/1226 -- [WIP] Remove dependency on marshal and push the Lua error handler only once |
| 21:28 |
ShadowNinja |
BBL. |
| 21:28 |
celeron55 |
why didn't you eg. copy my explanation in there instead of writing OMG IT'S BLACK MAGIC NOBODY SHOULD TRY TO EVEN UNDERSTAND IT |
| 21:28 |
celeron55 |
that's counterproductive |
| 21:28 |
celeron55 |
somebody else can understand it if you don't |
| 21:29 |
celeron55 |
at least the original creator of it does (which makes already two of us) |
| 21:34 |
|
proller joined #minetest-dev |
| 22:11 |
|
EvergreenTree joined #minetest-dev |
| 22:35 |
|
Gethiox joined #minetest-dev |
| 23:42 |
Megaf |
!up 191.17.35.35 30002 |
| 23:42 |
ShadowBot |
Megaf: 191.17.35.35 port 30002 is down |
| 23:43 |
Megaf |
liar |
| 23:47 |
Megaf |
!up 191.17.35.35 28000 |
| 23:47 |
ShadowBot |
Megaf: 191.17.35.35 port 28000 is down |
| 23:47 |
Megaf |
can anyone do a port scan on my IP please? |
| 23:47 |
Megaf |
191.17.35.35 |
| 23:47 |
Megaf |
sorry, wrong channel |
| 23:48 |
|
VanessaE joined #minetest-dev |
