devtrackers.gg
That was a typo, thanks for catching it. The issue with macOS was only from downtime today.
That was a typo, thanks for catching it. The issue with macOS was only from downtime today.
Thanks, done.
Known Issue:
Hello everyone,
There is an issue with macOS clients not launching.
A fix is being worked on.
Any updates will be posted here and on the EVE Status Twitter
Update: 12:07 - Mac Client rebuild is ongoing.
Update: 12:26 - Mac Client rebuild still ongoing.
Update: 12:44 - Mac Client rebuild still ongoing.
Update: 13:02 - Mac Client rebuild still ongoing.
Update: 13:15 - Mac Build succeeded. Team is working diligently to get this fix deployed.
Update: 13:37 - Redeployment still underway.
Update: 13:57 - Deployment to Test...
Read moreSalutations,
Please use this thread for reporting and tracking of any issues found in the 21.03 version of EVE Online, first released March 14th 2023.
Technical:
Events:
User Interface:
Greetings!
Please use our feedback threads to discuss the changes going live on Tranquility for the next month and you can keep an eye out for the Known Issues to see what our teams have already identified and are working on solving.
For fleet fights the simple answer is that as the number of players n increases then the number of interactions increases O(n²). Server performance roughly entails a linear increase in the number of interactions and therefore a O(√n) increase in players.
Let me clarify.
The problem that arose from the staging system being on the same node as X47 was resolved shortly after server downtime manually. X47 was the only system on the node for multiple hours before node death.
Those two problems are not related.
Thanks for posting this explanation, Paragon.
Hello everyone,
Yesterday you took to the battlefield and had yourselves a massive brawl in X47L-Q with local reaching over 6,000 pilots. These moments are always awe inspiring and we get extremely excited to witness these battles and wars unfold. It is our goal to deliver the capability for you to create these moments, in ever bigger and more glorious fashion.
I will go over the general circumstances surrounding the issues you experienced yesterday and what we are doing to address them going forward.
As for the issues that ultimately lead to a node death which contained the system in which the fight took place, they were unexpected. At this time it is not known what caused it, we are looking into this and if they relate to the previous recent node deaths.
Following server downtime a new boundary was pushed when an attempt was made to simultaneously log in every participant as the system was loading. Usually battles of this size do not span downtime and w...
Read moreThe answer here is yes and no.
On a universe level then there a number of things to track in parallel and we do. For example, all markets are separate, so is skill training, industry, various matters with corporations and alliances, planetary interaction, project discovery, etc.
But inside a single solarsystem, in a particular scene, then everything must be tracked serially since the simulation has to keep track of in what order events happened and progress the overall simulation in that scene accordingly. With
...Read more
We are investigating what happened there, but currently suspect some sort of an infinitive loop or O(n^m) processing where m is 2+. No amount of server hardware will help.
Reserved for updates.
Update: 13:59 - It’s now possible to reconnect, however load times into the system continue to take extended amounts of time. We will continue to monitor the system status for any additional unexpected disconnects.
Hey everyone,
We’re aware of a large ongoing fleet fight in the system of X47L-Q and subsequent disconnects - we are currently working on restoring normal connectivity to the system.
Due to the heavy load that the server is encountering, the login times are likely to be longer than expected.
Updates will be posted in this thread as normal activity is restored.
I’m told VXRail was looked into some years ago. At the time the idea of having to buy entire compute+storage nodes to expand didn’t make sense for our needs.
It would be very cool to see TQDB as a virtual sql cluster on one of these though - 4tb of mem and 8 tb of storage - spread over multiple compute nodes.
Love and hate is right 
A few years ago, just months before super devs fixed the our numa issues for good nojinx, we were evaluating new DB boxes and had 2 single socket servers in the line up for testing.
An Intel 24/48 core box and the EYPC 64/128 core. Due to whatever was going on within the code base at the time, we could not get the cluster to start with the single numa node. Blocking chains would tie up all the worker threads, max the CPU and threadpool waits would starve the simulation out - sols unable to heart beat. We so hated it…
The EYPC on the other hand made short work of it - was it the fact that it had 128 cores vs. the 48 on the Intel box? Or was it due to windows being unable to address all cores in a single numa node and instead split them into 2 numa nodes.
Numa to the ...
Read more7 years actually, that’s the extended warranty.
But the part that I covered very quickly in the devblog is that in between TQ Tech III and TQ Tech IV then there was TQ Tech IIIS (evidently S stands for “semis” meaning half in Roman numerals). So we are likely to remove the Gold 5122 and Gold 5222 powered machines in a few years time (possibly in 3-4 years), replace them with whatever is most high-end at that time (which will not be FLEX blades since IBM/Lenovo are stopping production), and move the heaviest workload there - JITA, The Forge m...
Read moreUuhhh, I don’t know. @CCP_DeNormalized, can you ask around and reply?
@CCP_DeNormalized and I love to hate NUMA.
