Note to the programmers: as a 35 year veteran of the tech industry who used to write and debug low level code in real time systems, and who as a customer/user tried to chase a similar problem in DAoC a decade ago (before the rules that customers couldn’t look at things like this), it appears to me that this issue is happening client side, because the client is prioritizing something (I would guess loading and unloading spell effect objects) (or possibly loading and unloading textures related to spell effects from the graphics card’s texture cache) ahead of simply draining the queue of location updates coming from the server. While this could be TCP packet drops happening near the server (ie some sort of policing by the router to the internet where the servers are hosted) I think it’s happening client side.
Can we please get some client side counters/instrumentation of events such as fetches of textures from disk, loads of textures to the graphics card, loads and unloads of objects to the client engine, per second? This would go a long ways toward tuning.
If there is a low level action in the client engine which is spin waiting while it goes to disk to get textures to load, that would explain the drastic performance improvement I saw going to solid state disk…and means that the game should perhaps load the entire library of particle effect and player armor textures to memory, so this low level action doesn’t ever block the main client thread waiting on disk
In the case of DAoC a decade ago, my conclusion was that each time a spell was cast, the game called a heavy weight call in the client engine to instantiate the spell effect as a separate object, executed the spell effect, and then called a heavy weight call to remove the spell effect object. This is in my opinion an architectural blunder, because it results in O(n^2) heavy weight calls to instantiate spell effects…on every client. Even if GW2’s limit of 5 affected players or mobs, not counting boss-casted spell effects which land on everyone, makes this O(n), it’s O(n) with a very large coefficient. Sorry for use of programmer jargon.
I think this assumption is not correct, because if i was alone and far away from SM, (for example in QL) I did no see any battle / or particle effects and still has huge skill lag if somebody fight in SM. Client should not use any calls in this case.
IMHO this is a problem on server-side. Because 20-40 sec is not s TCP-level delay. Simply too much SQL-requests or CPU-calculation at same time. Because if no battle = no lag. And If battle starts somewhere, then skill-lag starts too everywhere.
Also unfortunately it can means that this problem is impossible to fix easily, need to rework a huge part of the engine, may be change game mechanics too. I hope I’am wrong.