THE SYFRAG CONCEPT – Solving the problem of crowded systems

EVE Technology and Research Center Player Features & Ideas
1

Hello there,
My main character is Tom Deal and…

… Yes …

… i was there in the great battle of Jan23 in 9-4RP2, between GoonSwarm Federation and Pandemic Horde (backed up by its allies of GOTG), where only in one system (9-4RP2) managed to fit almost 6000 players.
The conclusion of that fatidic night, besides our victory over Goons,is that it is practically impossible for one server with current technology, even the fastest and efficient one, to support 6000 client accounts interacting and changing massive information between them, on a decent time and required onlinebasis.
Even with the help of the famous and boring TIDI, server response times under these conditions are painful, at minimum, and almost all the time impossible to manage. For example, on the battle night we had to wait more than half an hour to complete the lock of an enemy ship and almost the same time to enter warp. In fact, it was almost a miracle that the server didn’t collapsed.
So, since that day, as a challenge to my self, I started to develop a concept that I share with you today, that can be the solution of the problem of crowded systems, solution that aims to dilute for multiple servers (mirror servers) the activity until here supported by a single main server.

How?
Through the replication and division of the main server elements by two or more mirrored servers, this event which I called SYFRAG, happens when the number of customers in one system reach the maximum of 2000 clients.
In fact, as you can check on the diagrams I attached to this text, in general, the contend of a system are composed by two element types, the MDE (Main Duplicable Elements), like stations, gates, belts, and so, and RDCE (Regular Divisible Client Elements), like the name means, the clients inside their ships, and, whenever there is a SYFRAG event, the MDE identically replicates in the new servers (Mirror servers) while the RDCE are distributed in an equitable manner by the mirror servers.
Through this way, the original server clients are divided by two mirror servers, lowering the stress of processing the game, which, even not perceptible to the common player, distributes the game processment two servers (or even more if the client number rises) and the massive work that a server as to do under this conditions.

When?
The first phase of the SYFRAG (SYFRAG 12 – 1st escalating – See the below schemes) occurs whenever the server reaches the maximum of 2000 customers, dividing this number by two mirror servers. The DEFRAG 21 process (that is the counter operation or the roll back of SYFRAG - De-escalating) occurs when the total sum of the two mirror servers lowers below 1250 customers.
The SYFRAG 24 (2nd phase of escalating) occurs whenever one of the two mirrored servers reaches the top number of 2000 clients, fact that triggers the event which divide the total customers from two mirror servers (SYFRAG 12 State) between four new mirrored servers. The DEFRAG 42 (operation contrary to the SYFRAG 24) occurs when the total number of clients in the four mirrors became less than 2500.
In summary, this escalating process can be even bigger as it is easy to understand (8, 16, 32 mirrors), which means that one crowded system can gather (theoretically) almost an infinite number of customers (32 * 2000 = 64 000 customers would be the condition for the SYFRAG 3264).

And the client?
The client continues to see on is monitor the total nº of RDCE, however they can only interact directly with the clients that are resident on the same server that they are, and this common server clients have to be properly tagged on the overview. By direct interaction I mean clients that can engage, kill or be killed between them self. Clients in different servers can’t interact between each other.

And the fleet?
The elements of the fleets (RDCE), when SYFRAG occurs, are divided equally (whenever possible) by the mirrored servers. When this is not possible (odd situations) the distribution is random.

And the FC?
FC, despite being a client resident only in one of the mirrored servers for direct interactions purpose (in this case FC acts like an RDCE), he can also see (separated by color tag) all the clients resident in the different servers, which allow him to give specific order per server. However all clients of diferent servers can interact with their fleet FC, for Anchour purposes or Fleet Warp to FC purposes. In this case the position of the FC is present on all servers (in this case FC is an MDE) and all the client elements of the fleet can use these functions regardless of the server where FC is hosted.

And the Stations? And the market?
The stations are MDE, so once SYFRAG occurs, they are replicated but their damage info is divided by the number of mirrored servers, process that require an Online Date Syncro (ODS) of these damage values between all servers. Market orders and contracts are divided equally by the number of mirrored servers (odds are random distributed).

And the inputs and outputs in the system?
The mirror server RDCE distribution occurs at the time of SYFRAG, but also when there are new client entries on the crowded system, and this entries can happens through gate, cyno, or login. In this case the distribution process of clients through mirrors is similar to SYFRAG.
The outputs of the mirrored systems occur in a normal way, being 1 less client to all the mirrored servers sum.

What happens when SYFRAG or DEFRAG occurs?
When SYFRAG or DEFRAG event triggers, the game stops for the players that are inside the systemor entering it. During this process (may take a few minutes), a message appears on screen that says (SYFRAG escalating process is running. Prepare for battle). Something like this also for DEFRAG de-escalating process).

Conclusion
I hope that the above explanation of the concept was clear enough, and that this idea can help you (dev community) and us (player community) to have an even better game than we already have today, especially in the case of massive client system battles / gatherings.
I’m also at your service if you have any doubt that I can help to clarify.

RFASantosaka Tom Deal

SYFRAG BIG PICTURE

SYFRAG%201

SYFRAG DETAIL

SYFRAG%202

2

Need an abstract of this.

1 Like
3

I’ve seen variations of this suggested before. I believe the Devs have come out and said that splitting a system up can’t work without a major rewrite of the server code. Regardless, randomly splitting all the fleets in the battle onto different shards would be tough for organization. If you jump in with your fleet and half is on mirror1 while the other half is on mirror2, it’s going to throw things off. Especially if by random chance all (or even most) of the FC’s are on one mirror but not the other.

Also, what happens if one side of the battle begins winning on one mirror but the other side begins winning on the other? Taking 9-4RP2 into account, what if on mirror1 PH destroyed most of GSF and routed the rest, while on mirror2 the opposite happens? At that point you have GSF blasting away at the keepstar with impunity on one mirror while PH is repping it on the other and neither side is able to attack the other.

That being said, it’s not a terrible idea, and some sort of solution needs to be found. The huge battles big enough to get reported by non-eve sites are great to read about and definitely a draw for new players. However the reality is disappointing when they see what it’s like. No matter what CCP does to improve their HW and increase performance, we just keep pushing those boundaries harder and harder. Even with TiDi and reinforcement for planned battles connection problems occur. I don’t know if there is a true solution for it though.

4

There was full TiDi during the Burn Jita weekend with only 1600 pilots in system.

I think the true scale of the problem is being hidden by the assumption that the issues are caused by epic fleet battles. I couldn’t believe how much the game struggled to cope with some minor Freighter ganks.

New hamster needed.

5

I had suggested that they do their code re-work to allow a “node” to be as small as a grid, and then create reasons for players to be on each of the grids to control objectives which significantly influence the fight.

In that particular suggestion, 4 different nodes would have been able to share the load by simply having 4 separate fights. It’s not infinitely scalable, but I suspect it’s a lot more feasible than trying to have concurrent servers trying to share the load of a single battle.

Also solves the issue of “blobs”… invariably you just end up with alpha doctrines when fights get this big.

6

Hamsters are no longer doing the job. We need new hamsters… from space… miniaturized to fit in the current locations of our current hamsters. Perhaps call it Steve.

7

Hi Donky, thanks for your reply.

First of all its a fact that, with the present tecnology, there isnt a perfect solution for this issue, however im convinced that there is a better solution than the current one, and SYFRAG Concept i believe that can be that better solution once correctly implemented.

About your doubts:

Has you can read on my description, fleets would be ‘distributed in an equitable manner by the mirror servers. When this is not possible (odd situations) the distribution is random.’
This means that only when there is one kind of ship that random distribution will be aplied.

‘FC, despite being a client resident only in one of the mirrored servers for direct interactions purpose (in this case FC acts like an RDCE), … all clients of diferent servers can interact with their fleet FC, for Anchour purposes or Fleet Warp to FC purposes.’

This maybe the most complex challenge of SYFRAG but i think that can be solved like i explained above.

‘The stations are MDE, so once SYFRAG occurs, they are replicated but their damage info is divided by the number of mirrored servers, process that require an Online Data Syncro (ODS) of these damage values between all servers.’

This means there is an ODS that sincronise the MDE damage and repairing between the mirror servers. Check the SYFRAG DETAIL Sqhemes

Also when one side is winning that means the total number of players are decresing (through the death of the defeated) so somehow the sum of surviving clients will reach the DEFRAG event low number wich triggers the system de-escalation and gathers again the remaining players on the same server.

8

I don‘t think fragmentation is the right way to solve the issue, but maybe reducing the resolution of the simulation is. TiDi just stretches the time to do calculations, but precision keeps the same.

Why do you need exact individual movement calculation in a blob moving together on grid? People are fleet warping all the time, and anchor. Simulate the swarm, not the fish. Same for skills, tracking, etc., create clusters of similar ships and skilled people in the blob.

9

The crimewatch-system adds a significant amount of load to the server, which causes the number of players to be lower.

10

I’m still in favor of copying Futurama’s doom field. First rule of economics is People Respond to Incentives. The incentive is to bring the biggest fleet. There’s literally no downside; load the node, even if it breaks the server. There are a lot of very good arguments against Increasing fight capacity, key in my mind being that taking part in a tidi fight isn’t fun. Increasing capacity just means more people will get to experience a reason to quit EVE. Making big fights bigger has no value. Making big fights more fun does.

That’s where the doom field idea would kick in. When tidi gets high enough, random stuff should just start dying until tidi goes away. It doesn’t prevent big fights, but it would both accelerate them and disincentivize them. Less tidi = more fun. Fewer ships = less tidi.

edit: if you really want to copy Futurama’s doom field, the field could be permanent, get tidi’d and you’re gonna go boom sooner or later. Great way to thin out the capital proliferation problem.

1 Like
11

While keeping TiDI down is more fun, having your ship randomly blow up to keep it down isn’t. Also, even if you keep it completely random one side is naturally going to end up with more “doomed” ships then the other making battles less about numbers and skill and more about how much BOB likes you. Especially if large ships get doomed. I mean think about the uproar of loosing a titan simply because TiDi occurred and it’s number came up.

12

Wrong paradigm. You’re still thinking from the “let’s tidi the sh1t out of the node” paradigm. New paradigm would be “how close are we to tidi? Too close? Let’s wait before committing our reserves. It would be stupid of us to overload the node, so let’s not do that unless the level of risk in losing really demands it.” If my titan died because the FCs committed it too early before they knew what the tidi level was going to be, I’d be pissed at the FCs not the tidi. But, there is literally no real way to prevent tidi except by making tidi hazardous in and of itself.

13

You would need some sort of indicator as to how close to TiDi a system is. Even with that I can see it getting a bit abused though. Battle builds up, you’re close to the TiDi limit, then suddenly one team docks up their regular ships and then begins spamming corvettes and frigates like there’s no tomorrow. These ships are so weak they would normally get wiped out by the other teams fleets despite having 4 times the number of normal ships but they warp from point to point all across the system doing nothing but living as long as they can to abuse TiDI.

Assuming it’s random which ships are “doomed” then the non-corvette fleet will lose out on this overall. If you try and make it so that cheaper ships are more likely to be doomed to counter this then battles become extremely top-heavy favoring capital ships. Having a doom mechanic isn’t a terrible solution to the TiDI problem, but I do think it’s too easily exploitable.

14

Its possible the new citadels may have impact on server performance.CCP is notorious for releasing content that isn’t optimised(anyone remember the CQ gpu drain when it came out?)

1 Like
15

No one more interested in this subject?

16

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.