Although this isn't definitive proof by any stretch of the imagination, given the different IP prefixes, it is more than likely that the server that you indicated belongs to an internet provider in the Southern California area and the one that follows it is probably owned by the same company providing internet to the the San Diego area. (I base that supposition on the fact that companies and corporations tend to buy blocks of internet access - rather than single IPs. So if you see the same subnet mask, it is generally owned by a given company. In this case, the two that appear to be the same company have the subnet mask of 66.209.64.000 - or 66.209.64.xxx, if you prefer, while the SOE one at the end has a completely different IP. Again, it is possible that SOE could own them all, but rather unlikely.) tl;dr Probably not SOE hardware.
Is there any progress in resolving the lag problems? It's seriously awful and should be addressed asap. This has made me want to quit more than bad encounters or zone crashes or whatever else.
Increment stacks are an interesting mechanic, but the amount of calculation and checks going on with it has to be comparatively enormous when profiled against persistant, duration, and instant based effects. I suspect if they were localized, but intensified, these increment stack effects would see greatly improved performance. Increments should be limited to self or at most group conditions, and with only the rarest of exceptions to raid or pbae wide. The second thing that would help increment stack effects is if they were only applied to events that occurred less often, but not necessarily rarely. Typical healing events and on-hit events are frequent. Too frequent for increment stacking on the scale that we are on, where it likely causes the most problems. This is probably not a good place to use increment stacks. Instead, possibly on-cure, on-death, on-rez, on-gain/on-lose target (aggro); or other slightly less common, but not entirely rare events in the same vein. One in particular I have considered is on-out-of-range. This would possibly be nice -- out of range because of line of sight from slight elevation variance, and just barely out of range to this point has been annoying to say the least. Increment stacks that tracked these edge case events for barely out of range and applied an occassional override to the normal rules of range through the use of increments might be well received. Range checking can be expensive computationally, so it should not need to apply to everything, but I think if it was applied to the areas that are most annoying to players it could work out well -- explicit healing, explicit cures, and ressuraction. No proc heals, no proc cures... just those that are explicitly cast by a player. I am sure many would say it should be available to damage/offensive events, but I think that would run the line of circumventing some base expectations of most encounters, eg highly exploitable when damage can start to bend the rules. Area, encounter, and viral effects that do individual mob [damage] reporting back to players should at the least be aggregated (eg just the total/cumulative value). Simply send the total damage done during an encounter or an area event, instead of every individual hit or occurance. It may even be more ideal if there was server-side filtering, to limit reporting even more significantly, on a broader scale. To encourage its use, server-side filtering should be opt-out. In other words, reporting would be almost entirely off by default for everyone, and we would have to explicitly opt-in to send us reports/messages. EQ1 did this years ago, and it really surprises me we havent seen it here yet. Most people don't run ACT or any other parser, and by changing reporting to where only the people who do parsing are getting detailed data event reports by explicitly opting-in would significnatly reduce the transfer load. This I am sure would be a fairly significant undertaking, but perhaps it can be effectively kludged in for the worst offending, in terms of reporting (for like ETOX). Just so an intern doesn't get crazy with it, do not filter mob detriment or effect or emote reporting, as this is something we need to know every time for every person, even if every player is not always paying attention to it with a parser.
POPULATION / ZONE PROGRESSION General Some raid aoe spells in Plane of War [Raid], Harrow’s End [Raid], Sleeper's Tomb Unearthed [Raid], and Sleeper's Tomb: a Temporal Leap [Raid] have been modified to reduce zone lag. Are you sure? After this update its double worse then before
Sadly I wouldn't expect much. As you in Equillibrium probably know best, the game has been increasingly laggy since SF and the PQ's of DoV. I wonder how much of EQ2 is now ran on Virtual Servers versus actual separate towers.
Seems all hope is lost for the needed improvements in this game. Seems like a good time to quit and hope that EQNext will be the white horse.
When you experience lag can you try to traceroute to your EQII server and see where the lag is? We've had a few people send us these but they were all OCONUS and to have the network guys track these down we need more data from CONUS.
As an aside we are also spending a bunch of time getting some of the code to run more efficiently to help as well. We made changes last week that increased character load times by 2 orders of magnitude. This is a critical issue for us. Please keep the reports and info coming.
I can't believe you just asked that and tried to imply that a lot of the problem is the internet itself =/. I'm pretty sure those traceroutes had nothing to do with the game, but with the forums when the forums started to take a dump. I also hope you meant decreased!
I'm not sure why you think I'm blaming the internet. There is a issue we have seen with various raiding guilds getting high packetloss from a switch downstream from our datacenter. We are trying to isolate that issue to resolve it. There are also inefficiencies in the game but we have been working on fixing those as well. And the traceroutes I am talking about weren't posted on the forums so they aren't the ones you are thinking of.
Honestly I hope there are switch problems, it just feels unlikely since it's every server everywhere complaining about the lag. Is there a good way to either know the ip or address of each individual server?
There is (was? it didn't time out on us last week) a bad switch in Vegas, prior to reaching SOE hardware. But it would appear that only a moderately small percentage of EQ2 players went through that exact switch. Regardless, SOE has been helpful enough to look into it. However, server lag is a very real, on-going, entirely separate issue.
Sorry this is off topic; did you fix the loading ui resources bug as part of this? Because if you didn't it doesn't matter how fast everything else is loading it will still hang there for 30-60s if/when that bug occurs. (If you have no clue what I'm referring to there is a thread in support forums about it in detail). Again, sorry for the off topic.
I've spent the last few weeks on live watching raids to see the issues and what we can do to continue our improvements. There is a new command on live today "/combat_filter" which will cause the server to filter what combat data you receive. One of the things that I noticed on these raids is that some spells cause a ton of combat messages to come back to each person. I want to see how much this is actually effecting people before we make huge changes to how it works. *** DO NOT USE THIS UNTIL NEXT PATCH *** *** CURRENTLY BUGGED *** How /combat_filter <filter#> works This command will turn on server-side filtering of combat data. Filter #'s: 0 => None (same as before the patch) 1 => Self (you will only get combat messages for yourself/your pet) 2 => Group 3 => Raid As this is a testing command, this value does not persist through zoning so you will have to set it each time you zone. If you are seeing huge lag please try "/combat_filter 1" and see if that helps and then reply to this thread.
