Game Performance Improvements and Feedback

[Phoenix-daBard]

1. New data center and new operating system need to be optimized regarding Microsoft.
2. Still having some issues w/3rd parties.
3. Barbs have some over performing stacking going on behind the scenes.

Fix will probably address 1 and 3. Feel bad for the people at Turbine that have to deal with 2. Aside from all this lag will continue to be worked on past these items.

There's a server side update in test hopefully for a Thursday update. They're fixing a stacking-lag-isssue that affects Barbos and they've got a change to help with threads migrating across processors caused by swapping from direct Microsoft OS to their new Virtual Machine environment.

Also trying to cleanup network connection routing to the servers but its a long process due to lawyers and contracts being their own source of paperwork in triplicate lag.

There will be a few more updates coming on the current inDesign Fighter enhancements on the forums.
Player's Council is getting an early look now at U31 new loots.
Coming to Lama "Fairly Soon". (but not SOON).

Thank you both, it helps.

[Sam1313]

Here's today's interview with Sev. It's the first six minutes of today's video:

Ah sadness. I didn't even get a chance to log into my home Cannith and play today as I was working from 5:00 AM EST to 7:30 PM EST. Maybe next time. And if you do happen to be on Cannith Hit up Samyel

[Kompera_Oberon]

Wow. Cordovan didn't have to do that, and Sev didn't have to answer, but this is the response from their efforts? Wow.

Wow. Cordovan didn't have to communicate their efforts to resolve the horrible LAG issues? Severlain didn't have to scrape a sparse 6 minutes in order to communicate with the customer base about those same issues?

Could you possibly be more condescending? Yes, this is the response to their efforts, because those communication efforts have been very poor for the past 5 weeks and 6 whole minutes at the start of watching Cordovan play the game is not any kind of solution. There are a large number of players who have been asking, begging, demanding answers, and to provide them in the form of a livestream with a very small viewership is just business as usual for Turbine: Scatter your communications efforts, as sparse as they already are, across a solid double handful of venues and expect the customers to manage to separate the chaff from the seed.

Did you see the post from the player who is deaf? That post alone should tell you that pointing to a livestream is a poor method of communicating with the customer base.

[MeliCat]

That was really great information. Thanks Cordovan.

Any chance we could just see that as a few bullet points in a tweet or forum post?

Yes please. Twitch.TV is slow as for me. Thank you Cordovan for this.

[sudzz]

So, the lag being experienced by those of us who do not have any barbs in the party is coming from where? Please don't scapegoat a class in this manner, not that I play any barbs or barb splashes myself atm, as it will set a bad precedent for folk to not want them in the party. Although I would like the option to switch off visibility of other's cosmetics like useless pets etc as surely they are adding to sever load without any positive contribution to a party in quests.

[Lerincho]

So, the lag being experienced by those of us who do not have any barbs in the party is coming from where? Please don't scapegoat a class in this manner, not that I play any barbs or barb splashes myself atm, as it will set a bad precedent for folk to not want them in the party. Although I would like the option to switch off visibility of other's cosmetics like useless pets etc as surely they are adding to sever load without any positive contribution to a party in quests.

They stated contributing, not causing. Additionally just because they are not in your party does not mean that it is not effecting the overall server. Each party may be their own instance in a dungeon but they are not their own server.

[FeartheBow]

Seem to be having problems hard targeting monsters. Once I do get them targeted it will automatically un-target them and I end up firing into the void.

[LeoLionxxx]

A lot of the time, it will seem that lag will (finally) stop only once every player in the instance/area is dead. Might this relate to how monsters are tracking the players and the hate levels they place upon each?

And of course, having a swarm of a dozen guys pop up at once is a really good way to incur that wonderful lag.

[VinceWhirlwind]

They're fixing a stacking-lag-isssue that affects Barbos and they've got a change to help with threads migrating across processors caused by swapping from direct Microsoft OS to their new Virtual Machine environment.

Also trying to cleanup network connection routing to the servers but its a long process due to lawyers and contracts being their own source of paperwork in triplicate lag.

The chances of the lag being caused by BOTH bad processor scheduling AND networking issues at the same time, is so small it's not funny.

When you're in a project meeting, and they are talking about two completely different issues in relation to the same problem, you know something has gone wrong with your incident management.

What it usually means is that the server guys have tried to divert attention away from the poorly-documented GUI-driven botch they are responsible for by mentioning invented "network problems" often enough to get these imaginary "network problems" onto the agenda. Then you have many hours over many weeks being spent by network guys and their project managers trying to find an imaginary issue and then trying to prove the imaginary issue has been fixed.

And how lawyers and contracts come into "network issues" is anybody's guess.

A genuine "network issue" is generally identified, isolated, and fixed within hours. If it drags out over a week, it is almost always going to be something happening in the application (that is, Layer4 and above - the TCP/IP stack, operating system, and other applications sitting above it).

"Network connection routing" in the datacentre is something that happens in 10s or 100s of microseconds. Delays in the 10s of milliseconds and above are not happening in the networking infrastructure.
Of course, the first thing that has been ruled out in the first few minutes of the incident is that there is no congestion issue - no dropped packets, no switch buffers overflowing, no collisions or FCS errors.
Shortly afterwards, you should be able to see whether traffic is spiking with a lot of TCP retries. In the absence of any lost packets, this tells you the application is at fault. If the TCP connections are up normally and traffic is dipping, the application is at fault. In almost every other case, the application is at fault.

[Cordovan]

Closing this thread to give things a reset and start fresh here.