Doggydaddy wrote on Sep 12
th, 2014 at 4:42pm:
Ok.. I STILL have no idea .. what exactly was happening with Mabar that made them pull it early and then now dump it?
Server wide crippling lag when the spectral dragon was up.
Most believed it was due to shadow creature spawns in every room.
My observations.
I believe the main issue was that every instance of the dragon (possible to have multiple at each level range depending on player population) all started at the same time.
A logical step would have been to stagger the starts of the different level ranges at least, and even offset the Epic dragon by 10-15 secs to smooth the load.
Turbine's concern was that players might be able to complete multiple dragons by jumping instances.
Soln: use a lockout or cooldown timer.
There were lots of theories on causes like persistent AOE's, buffs and even flashy effect spells. An interesting observation was that the mobs had no trouble moving and attacking, so lag only affected players. You could see this as you spammed the heal button, whilst nothing happened, and then 30 secs later you just several thousand points of damage roll in over a few seconds as the game re-sync'd.
I believe this tied the problem to comms, not server load.
With each instance having up to 24-30 players, plus lots of mobs - this means an enormous amount of positional and action data has to be passed to each connected client.
In a normal quest, your client has to sync comms with the server that then sends that to 5 other clients. In Mabar this could be up to 30 odd clients at a time. That is an exponential increase in instantaneous comms that are very time dependent.
I think the soln would have been smaller groups - say max of 16 or less if the challenge was modified. Get it back to 12 like a raid.
I suspect the client just was not written with up to 30 simultaneous players in mind. Can't fault that, as DDO would not have envisioned that. But they should have done a Lamm version with 12 players and change the requirements for levers/altars/rooms.
Furthermore a max number of groups to balance server load.
Then change the startup requirement so it runs more frequently.
You get the same number of people through, but spread the load.
These seem pretty obvious, so maybe they didn't work or they didn't try.
Ultimately there were lots of options suggested, but I think it fell in the too hard basket.