CCP_Explorer

Further, DTAG customers may want to consider adding their complaint to BGP Flaps, Long-lived TCP Connections | Telekom hilft Community on DTAG’s forums.

I want to comment on that thread:

Ist halt kein Telekom Problem … die nutzen das Peering was der Anbieter vorgibt.

We have seen this happen at ISPs, where they do get the correct BGP information from Cloudflare on the route to Tranquility but the ISPs’ equipment either has out-of-memory issues or a prefix limit and throws the correct routing i...

Some EVE players who are customers of Deutsche Telekom AG (DTAG) and have been affected recently by random disconnects have reported to us that they have resolved the issue by installing https://cloudflarewarp.com/, which is software from Cloudflare, and using it in full WARP mode. You can read more about this software here ...

No.

The issues were happening in ISPs’ network systems before reaching the local Cloudflare locations in Australia.

See also my next post with more details about Deutsche Telekom AG as that may be relevant to players in Australia and New Zealand.

That is indeed a bit of a mystery.

A sudden route change will result in stateful network devices on the new path to reply with a TCP RST to reset the connection. At that point the EVE Client needs to reestablish the connection to Tranquility through the new Cloudflare location that the network connection is going though. Normally this will result in all running EVE Clients to reset since normally they would all be transmitting and receiving messages.

There is an edge case if the network route flips back and forth very quickly and it so happens that one the clients was not transmitting/receiving then it would stay connected (or there would be packet loss but a re-transmission would be requested and succeed and no RST packets would be sent.

Hence we suspect some other network equipment failure at Deutsche Telekom AG where only some of the connections are terminated (for reasons unknown to us).

We are not seeing this pattern from other countries starting 1-2...

Just noting that I’m going to be using that thread @Mike_Kingswell linked for DTAG disconnect issues.

First off: Please DO NOT post any of your details as a reply in this thread as they will contain private information. Rather send us a support ticket with those details; but most importantly open a support ticket with Deutsche Telekom AG about network route instability (if DTAG is your ISP).

Earlier this year then customers of Virgin Media UK experienced a very similar issue as is described in this thread and as we are seeing in metrics now for Germany. See this forum thread: 20...

If you are a Deutsche Telekom AG customer and have been experiencing more disconnects since 1-2 August, then please create a support ticket. If you are playing from Germany and have been experiencing disconnects since the beginning of August even if your ISP is not DTAG, then we want to hear from you. We are trying to understand what is happening in this graph:

Cloudflare was experiencing issues this morning; they have posted a blog with details: https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/

Cloudflare had issues this morning, they have posted a blog on the outage: https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/

Cloudflare has just posted a blog on this morning’s outage: https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/

Cloudflare has posted a blog on this morning’s outage: https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/

The issue 5 days ago and the issue this morning are not related. Cloudflare has posted a blog on what happened this morning: https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/

Please send a Support Ticket to CCP’s Customer Support.

Location? Australia or Korea? We are looking into tunnel and/or carrier issues at the moment with our network partners, which started at 12:25 EVE Time.

Edit: It does look like there are some network issues in Australia at the moment.

The chat cluster is hosted in AWS but there is hardware underneath that cluster in AWS as there is for all cloud services. AWS has informed us that “one or more of your Amazon RDS DB instances are scheduled to receive maintenance on the underlying hardware” and that the instance will either not be available for a few minutes (single AZ) or fail over (multiple AZ). Neither option works for us, so we are manually performing the actions.

False. Wormholes are generated and managed by the Wormhole Manager, which is in the game logic code (Python). (The state is persisted in the DB.)

I’m not even authorized for datacenter access.

AMD’s approach of a high number of cores doesn’t fit well with Microsoft’s licensing of SQL Server per core. I would love for Microsoft to measure volume, throughput, usage for licensing purposes somehow differently than just counting the cores.

That would be a massive undertaking; migrating all tables, views, functions, and stored procedures from T-SQL to PL/pgSQL, along with all monitoring, metrics, and institutional knowledge; and would therefore have to entail massive benefits.

Did we ever get EVE started on that 28C Intel box?