Yeah, seems to be the same thing that happened last week.
It works as normal for a few minutes, then gets completely unresponsive, back and forth.
Yeah, seems to be the same thing that happened last week.
[...] 6 18 ms 13 ms 13 ms ae51.edge1.Dallas1.Level3.net [67.72.0.33] 7 * * * Request timed out. <- maybe fine, might just eat ICMP? 8 27 ms 24 ms * 4.71.220.10 <- maybe flapping? 9 23 ms * * 198.20.200.1 10 * * * Request timed out. 11 * * * Request timed out. 12 31 ms * 14 ms 198.20.200.1
[...] 6 28 ms 22 ms 18 ms ae51.edge1.Dallas1.Level3.net [67.72.0.33] 7 * * * Request timed out. 8 * * 33 ms 4.71.220.10 9 * * * Request timed out. 10 * * * Request timed out. 11 * * 13 ms ZENIMAX-MED.ear1.Dallas1.Level3.net [4.71.220.10] 12 23 ms * 16 ms 198.20.200.1
trittnerxx wrote: »all that matters is they were able to focus on the cooking stream instead of the servers that have been on fire
DewiMorgan wrote: »no oncalls. been going on for an hour, and still no acknowledgement there is an issue. everyone is just going to give up and call it a night because the game is unplayable.
Engineers do not respond to customer service calls, especially when things are on fire. They focus on diagnosing and resolving the problem.
For any large enterprise, there are essentially always engineers on call. I can essentially guarantee that there are some engineers right now with very unhappy faces, because they are not going to have a fun Friday night.
Tech support is generally a different dept, and in this case maybe even a different org (I suspect ZOS user support is done by MS nowadays), and does not typically have any on-call staff.trittnerxx wrote: »all that matters is they were able to focus on the cooking stream instead of the servers that have been on fire
Engineers also don't do cooking streams (but I'm guessing this was just a joke).
TX12001rwb17_ESO wrote: »There is a very strong chance it is a Hardware issue, something is broken and needs replacing, I hate to say this, but I think ZOS should keep the servers down for a few days and work on it, compensate everyone after that with a big Christmas present like 15 free crates or something.
DewiMorgan wrote: »no oncalls. been going on for an hour, and still no acknowledgement there is an issue. everyone is just going to give up and call it a night because the game is unplayable.
Engineers do not respond to customer service calls, especially when things are on fire. They focus on diagnosing and resolving the problem.
For any large enterprise, there are essentially always engineers on call. I can essentially guarantee that there are some engineers right now with very unhappy faces, because they are not going to have a fun Friday night.
Tech support is generally a different dept, and in this case maybe even a different org (I suspect ZOS user support is done by MS nowadays), and does not typically have any on-call staff.trittnerxx wrote: »all that matters is they were able to focus on the cooking stream instead of the servers that have been on fire
Engineers also don't do cooking streams (but I'm guessing this was just a joke).
DewiMorgan wrote: »Yeah, seems to be the same thing that happened last week.
Oof. I've worked for an MMO, and for an ISP, and either way, router problems were always the worst, because the ones with problems were rarely ours: Especially the Friday-night outages were always a hop or two from our data center, so we had to get in touch with their engineers, get through to someone who would escalate it, and then wait on them for a fix. And of course their IP contact records' contact info is someone who has no clue what the router even IS, and can't put us through to anyone who does.
But of course it would look like OUR problem as far as the users were concerned, rather than them blaming some misconfigured router owned by our upstream ISP.
At least when you're an ISP, and your network peers' routers mess up, you have some kinda business relationship and uptime agreements with those peers. A game doesn't get any of that kinda leverage.
Looking at tracert, it looks like a router 4.71.220.10, four hops before 198.20.200.1, mightbe flapping? But can't really tell, tracert is so flakey nowadays. I miss the days when routers didn't deliberately eat ICMP, it made debugging this stuff so much easier.
(hmm.. why's my ISP routing me all the way up to Dallas, if ESO is hosted here in Austin?)[...] 6 18 ms 13 ms 13 ms ae51.edge1.Dallas1.Level3.net [67.72.0.33] 7 * * * Request timed out. <- maybe fine, might just eat ICMP? 8 27 ms 24 ms * 4.71.220.10 <- maybe flapping? 9 23 ms * * 198.20.200.1 10 * * * Request timed out. 11 * * * Request timed out. 12 31 ms * 14 ms 198.20.200.1[...] 6 28 ms 22 ms 18 ms ae51.edge1.Dallas1.Level3.net [67.72.0.33] 7 * * * Request timed out. 8 * * 33 ms 4.71.220.10 9 * * * Request timed out. 10 * * * Request timed out. 11 * * 13 ms ZENIMAX-MED.ear1.Dallas1.Level3.net [4.71.220.10] 12 23 ms * 16 ms 198.20.200.1
The second tracert I see 4.71.220.10 in line #8 and #11, which... yeah. But the second time it resolves to "ZENIMAX-MED.ear1.Dallas1.Level3.net" - which means it's one side or the other of a connection between Zenimax and Level3, and is either in Dallas, or is on a connection TO Dallas (unfortunately routers are often named after where they are, but also often after where they connect to).
So could be Zenimax router, or a Level3 one. If the latter, it'll be a non-fun Friday night for engineers in both companies.
But this is just speculation. I don't work there or know anything. Could just be someone turning the servers on and off like a scene from Airplane, for all I know.