Jump to content

faramir118

Members
  • Posts

    541
  • Joined

  • Last visited

    Never
  • Donations

    0.00 GBP 

Posts posted by faramir118

  1. sorry for double post...

    I don't think adding vmap checks will solve the falling-underground problem, because vmaps don't perform tests on terrain terrain. I can see the corner cases where the random destination is on the other side of a wall, so our path takes us through 10 rooms. This is a problem with the naive random destination selection - it only cares about euclidean distance, not walking distance.

    There are some detour-provided things we can leverage to solve this problem. dtNavMeshQuery::findLocalNeighbourhood will give us reachable polygons within a certain range, which can confine our 'random' destination to an area that is reasonably within the walking distance we specify.

    I am going to start writing something to explain this project, more detailed than 'look at the code'- what has changed, what is new, how it works, etc. This will hopefully help any reviewer(s).

  2. Maybe something gone missing at porting.

    The dep/recastnavigation/RecastDemo/Bin/ dir was missing, but I fixed it just now. Now there is no difference between mmaps_clean and mmaps_rewrite

    It isn't related to the flying problem of course :)

  3. @leak

    I know there are some platform limitations on the number of concurrent aio operations a process (or even system) can have. I have tried my best to combat this, but in some cases it will be better to use a reactor for performance reasons (I have logging which should alert people when this is the case).

    As for the windows problem you specifically pointed at, I may be able to help:

    The FD_SET macro silently fails if fd_set::fd_count >= FD_SETSIZE

    Also, deep in ACE, there are no bounds checks when adding sockets to the fd_set

    The select reactor will lose all data sent to sockets added after the platform-specific size limit was reached, because the socket is never included in select calls.

    One solution for the Trinity codebase (mangos has some different classes, but we would need the same thing to address this problem).

    Count the number of current active connections in RealmAcceptor

    In RealmSocket::open, if this count is greater than the platform limit,put the RealmSocket in a queue - do NOT call Base::open or RealmSession::OnAccept

    When a socket closes, it should unregister itself, then dequeue a RealmSocket and call its Base::open and RealmSession::OnAccept

    The platform limit should be ACE_DEFAULT_SELECT_REACTOR_SIZE

    (this is all very similar to the algorithm I came up with for the aiocb list limitations)

    @anybody that cares :)

    I've made further improvements to my aio branch - please check them out and let me know what you think.

    I tested 750 clients again, this time with CMSG_PING every 30 seconds. Latency seemed high, but I'm unsure if it is due to the proactor or if it's because those 750 clients are all in one .NET thread. More testing needed...

  4. Decided to try a little test:

    750 clients, idle at character screen (my c# client, so not even CMSG_PING)

    I think it shows the weakness of select-based servers, and that for large servers there is some performance gain to be found.

    I'll work on having the clients send data (ping or some invalid opcode w/ data). This should give a more realistic comparison since we will get to test completion callback vs fdset scanning (and also will ignore the 'overhead' of the mangos core ;))

    Download results here.

    PS: found some crashes related to outstanding async operations which dereference already-deleted sockets, so I will have to work on that as well.

    PPS: should have probably explained the images...

    • For the CPU graphs, look at the graph and not the label.
      The label is the % at the moment I took the picture, which could have been during a context switch, etc.
    • There is a CPU spike when the clients start connecting, and you can use the private bytes graph's slope to judge connection rate
    • The select/debug graph is off a bit, clients were running slow due to attached debugger
      Thus, actual connection rate is probably higher
    • If there are any questions, just ask!
  5. @salja

    Can use use the mmap debug commands to test your server first?

    • .mmap stats, .mmap loadedtiles
      Lists stats about the navmesh for your current map/instance
    • .mmap path
      Tests the navmesh by generating a path to your current target (turn on gm mode to see the path)
    • .mmap testarea [radius]
      Like .mmap path, but test multiple mobs around you (for load testing)
    • .mmap loc
      Sort of like .gps

    They may help you solve your problem, or will at least give us more information.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use