EVE General Discussion

It's funny, because I don't remember seeing anyone saying it was easy. In fact I quite distinctly remember saying the opposite. Here, I'll quote it so you don't need to find it:
The point is that Tidi is a temporary measure. Either they need to find a proper solution (for example multithreading SOL) or they need to face the fact that they can't do big battles, which is what they seem to be leaning to by nuking every aspect of the game that leads to big battles.

Also I hear their pay sucks, so no thanks.

That is where you fail at basic Computer science. You have 2 process you have 2 threads because a process can be scheduled, therefore it is a thread (in some operating systems) or it has a thread (in other operating systems). The only way for a process to not be or have a thread is if you have a cooperative system or a single process operating system, but we are not discussing embedded software here.

You are confusing multi threaded process with multi-threaded system/architecture. Any multi process system is by definition multithreaded, even if each of the process have only 1 thread. BIAB make the SYSTEM multi threaded (if each of their processes is single or multi thread that is not up to discussion and it is not even relevant unless you can prove me that there is strong data dependency in the continuity of their tasks, enough that inter process comunication becomes relevant.


Condidering almost everything made in eve is registered in a database, eve probably already faces inter process data barriers. But if that is not already a bottleneck then BIAB being in another process will surely not be a bottleneck either. Therefore your assumption that the PROCESS need to be multithread for them to achieve high performance is based purely on speculation.


Again multi thread SYSTEM and multi thread PROCESS are different things on a conceptual level (although in some scenarios might map 1:1)

Good lord man, I said none of this. All I said was that they need to multithread their solar system process. You can keep going on about splitting it out into multiple processes but since they need to share address space it's irrelevant. It's one single service in one single process that needs to operate on multiple threads. Whether it's on one CPU or multiple CPUs is irrelevant, but it still has to be one process.

At the end of the day I'm not going to continue this argument with you forever. You have no idea what you are talking about and you clearly want to pretend you have some knowledge on the subject. You're probably a uni dropout or something, but I have no interest in going around in circles. In the absolute simplest terms, their SOL process needs to operate as one process on multiple threads. It really doesn't get simpler than that.

Then don't prove it, I don't care. The assumption will still be that you're lying. Nobody with a degree would get this confused and riled up over such a simple statement.

No, it's where you fail, since while you have two threads, they are different processes. Running two copies of a single-threaded program don't mean that you have magically muti-threaded that process. For one process to be multi threaded, multiple threads must exist withing that single process. This is where you are confusing parallelism with mutli-threading. While parallelism can be accomplished using multi-threading it's not the same thing.

No, I'm not. The SYSTEM is already running in multiple processes, and BIAB is a new service process within that system. The process responsible for all of the stuff happening in a system that causes tidi is called SOL. That SOL process cannot cleanly be broken down into multiple processes, thus to make it able to operate faster than a single core can handle, it must be able to run mutliple threads within that single process. I don't know if language is the problem here, because this is basic computing, like high-school level stuff. There's no way you don't understand why a process might need multiple threads if you have a masters unless it's a masters in comparing rocks.

Live data such as that occurring during big battles, module activations, warps, etc, won't be stored in a database as that would be shockingly bad for performance. That will all be stored in the SOL process running that solar system.

TiDi is temporary? What nonsense is next, short-term duct tape? Or single use tea bags?

you know very well that when duct tape is applied, the strings of destiny ensure it will be no other solution for as long as there is anyone that remember who was the first to put duct tape there.

Ducttape is short term?

*Runs off to fix everything with ducttape applied*

Just want to remind everyone here that if you want to show off your mad tech knowledge you need to include at least 'microservice' and 'container' into your drivel or no one will take you serious.

... Not really. He swooped in with sarcasm about something that nobody said.

I don't think anyone here believe it to be a magical pill to solve all the worlds problems, but when you are overclocking a CPU so much that you have to disable cores to dissipate heat, you're still smashing the overclocked core up to 100% and you're getting lag on top of tidi because of the CPU bottleneck on your single threaded process, multithreading actually is the solution.

I doubt it's going to happen though which is why CCP are just breaking up big fights which is a damn shame.

Ok. I'll bite.
You've championed the need to massively rewrite EVE Online server code to take greater advantage of multithreading and parallelism.

That's... Nice.

Now lets break down the problem with this entire argument and what many people have tried to explain to you.
You have zero idea how the server side is built. You have assumptions and devblogs where things have been publicly described but at base you know exactly zero. Why do you know zero? Because the Tranquility server is a custom built proprietary piece of hardware run by people who have been using it exclusively and tailoring every tiny scrap of physical and software assets for over a decade. You attempting to claim a magic pill that that team hasnt already thought of is on the order of a man looking at a tank and telling someone it needs a new transmission to go faster without ever having physically touched said tank.

To further support your lack of knowledge(and well everyones really) consider that CCP is notoriously data crazy. They collect every bit that isnt nailed down and then dig in the sofa for more. Then they spend weeks looking at it and breaking down every aspect of it in relation to that custom designed proprietary hardware and software that is Tranquility. Also You cant claim to know how their system works by past experience. Nothing exists like tranquility. Its a one off. No one but the crazy nutballs(and we love ya) at CCP has had the raw testicular fortitude to actually build a super computer for a video game.

So.. no. Your argument is utterly and pointlessly moot. It shows a lack of technical and professional understanding of what you simply cannot know. Trust me.. i have intimate knowledge with people doing this to companies and experts. I used to work on nuclear devices. Did you know that by simply mentioning that people will tell you exactly the wrong information. Apparently you can blow up the world or cause black holes and radiation automatically has a halflife of millions of years. Never mind chernobyl or fukushima or anything recent that shows the physical scientifically backed opposite. Why is this comparable to CCP? Well unless you actually work in the field.. you wont find truly accurate information on it. Same with Tranquility. Unless you physically work with it everything you say is raw conjecture and every comment you make as to its design is automatically doomed to be wrong by simple lack of information.

But all that said.. if you seriously have the technical skill to build a superior tranquility(bear in mind this requires the professional understanding of not rebuilding something for exactly zero or nearly zero gain) then email CCP. Im quite sure Hilmar and Seagul would quite seriously welcome such a breakthrough considering how much of their lives theyve invested in EVE and how vested they are in its future success. They also have a track record for making huge changes when needed to support that game and this community. Considering that most other companies would just stop development and go for EVE 2.0 the simple fact that they have basically rewritten the entire game without disruption of service or loss of data should be more than enough proof of their devotion to the project.

Well no, between dev blogs and fanfest, there's a lot of knowledge floating around about the servers and having spoken to the devs at fanfest they are aware themselves that threading the server would solve a lot of problems. It's not that they haven't thought of it, they just don't want to dedicate the time it takes to rewrite it. As for you're idea of looking at a tank, it's more like looking at a tank, seeing it has no tracks and suggesting they stick some tracks on it if they want to get anywhere. We know that they have a CPU bottleneck, we also know that SOL is single threaded, we also know that they are overclocking a beast of a CPU way beyond what it should be at to squeeze the most performance out of it. Unless there's massive improvements in CPU speed on their way the best way to squeeze out more processing power is by going sideway.

True, but data collection should have very little impact on the server, and would also be an absolutely ideal use of multithreading since there's no reason whatsoever that aggregating and sending off data to a database needs to be done in the same thread as combat calcs. Also, you say "proprietary hardware and software" as if that means something. Most development companies will be running their own builds of hardware and software, and most large scale MMOS will run what CCP run. A lot exists like tranquillity actually. A long time ago what they had was pretty unique, but that hasn't been true for many years now. The only thing that makes theirs different is their aforementioned lack of process distribution leading to their strange need to try to set fire to their CPUs.

That's simply not true. Any seasoned developer will be able to tell quite a lot with even limited knowledge of the system. There's certainly not enough knowledge for me to state exactly how it would be done and what processes could be best split onto multiple threads, but a high level view of it like this is pretty straightforward.

I'm sure they have the technical expertise on team to do it, it's more that they don't want to invest development time into it because it's a huge project the immediate benefit is unclear to consumers, but that doesn't mean that it's not what's needed if they want to be able to support big fights with less (or no) tidi.

Again though, you're confusing me saying this is a solution to me saying it's easy. It's not. It's certainly not something that one person can swoop in and change and definitely not for what I've heard the CCP pay. Anyway, CCP seem to have already made up their minds. Large scale fights are just being phased out.

Rewritten the entire game? Where? I've been playing over 10 years and at least half of the game is unchanged from back then. A new UI to pretty it up maybe, but a good chunk for the game works as it always has. It's actually quite the opposite. CCP are notorious for their dislike of touching legacy code. This is why POS code isn't being fixed, it''s just being replaced with POS v2, AKA citadels then will be patched out at a later date.