StarryWisdom
commented
4 years ago all of hermes is now single threaded, the overhead in complexity for multi threading prevented me looking into lag, it seems to be better on the windows AWS server, any future issues will be raised as individual issues
reported lag when running hermes
given its artemis it of course is hard to tell when it is artemis or not (oh how nice it would be to have a ping timer)
testing on 15/6/19 implied it is hermes (summary given to me was nebula server->windows no hermes seemed better, windows no hermes-> windows build 4 seemed worse, window4->windows10 seemed worse as well, unable to test nebula no hermes as server runner at that time was unaware of how to set it up)
there was an interesting suggestion for repruduction of lag - spawning in ships and waiting for the sandbox to rename them - the objectIntel packets obviously are not predicted, no testing was done with the selecting of ships and/or connection to port 2011 vs 2010
theorical causes (and thus soultions) not hermes in reality is artemis/AWS/something- if hermes is not the cause no fix is needed latency due to cpu use - related issue wtf is hermes doing that takes 30% of a AWS core? some sort of locking issue - I aquire the main lock a silly amount of times - it would be somewhat unsprising if this was a bottleneck, I dont think its user visable but maybe? main packet forwading is broken and only dealing with one pakcet - im fairly sure this is not happening but maybe change to be super double sure
soultions In retrospect I think the highly threaded nature of hermes was a mistake - I probably should fold it down to a single thread, even if this doesnt reduce CPU usage (which it should) we should be able to cope with 40+ players, in doing this it may well solve latency issues (locks go away, CPU use should drop), also after that is done it will probably be eaiser to wield better debugging tools
intermedate steps finalise build 11 hermes_write needs to be switched back to non blocking