EVE General Discussion

OH YA, and for the smart guy saying the client was still jumping and skipping, watch different videos with TiDi at up to 90% ... its not eve doing that jumping its people running there client with brackets enabled zoomed in during massive battles and crazy crap... that there PC can't handle rendering at 30 fps...

A nice solid PC on the other hand might handle that, check the test reports from the last masstest some guys with GTX5XX cards and i7's were seeing smooth 30+ FPS, while ZOOMED IN, thats UNHEARD OF in the past for these massive lagged battles.

You didn't even read what I wrote, did you?



I wasn't talking about the computer. I was talking about the server: i.e.: the software that is running on whatever hardware is available.



Does the Apache process care what hardware it's running on? Is the Apache process the web server, or the hardware? I don't see my hardware serving web sites, but I do see the Apache process serving web sites. When a client connects to an IP address to fetch a web page, it's talking to the Apache process.

If the hardware is actually the server, what happens when I run Apache and Samba and Postfix and Cyrus IMAPd on the same hardware? Is that hardware simultaneously all my servers? No, it's just a host running some software. The box doesn't care what software is running on it. The web server is the Apache process listening on address X. The file server is the Samba process listening on address Y. The mail transfer agent is the Postfix process listening on address Z. The box that all these servers are running on is only a host, it's not a server. If you're a hardware salesperson you'll advertise boxes as "servers" purely to provide some glossy-brochure differentiation between your "server" products and your "desktop" products since your "server" range has Fibre Channel connectivity while the "desktop" range has more USB ports and quieter fans. The labelling reflects the intended use: a box by itself is not a "server", it is a host.

The sol simulation is something that happens inside the server. The server runs on a host. Meaningless conflation of server and host into one term leads to confusion: if we shut down the mail server for maintenance, do you want me to stop the software, or turn off the hardware? If you refer to the host as the host and the server as the server, things become easier: "we need to shut the mail server down to fix some corruption in the on-disk store." "We need to shut down Marvin to replace a faulty disk, which will mean the mail server and IMAP server must be moved to a different host for the interim."



The only reason Time Dilation exists is because there are too many clients to handle at normal speed. From the perspective of the server, the clients are interacting too fast: "Hey! I can't handle that module activation, I haven't even finished handling your last module activation request! Slow down!" But the client won't slow down, so the server tries to handle more calculations per interval.

When the server can't handle the amount of processing that is required, it stops running lock-step at one second intervals and lets the "one second" processing take as much time as it needs. Thus "one second" on the server takes more than one second on the wall clock. The server is slowing down (from our perspective), but it is also speeding up (from the simulation's perspective).

Better hardware can allow the server to handle more clients before it has to slow time down in order to process all the requests and perform the necessary calculations.

You need to get over the confusion between software and hardware, and accept that when it takes the server longer than one second to process a "one second" cycle of the simulation, the server is slowing time down.

The "lag" that people are talking about in big fleet fights is where the combat simulation breaks. The server just can't process enough simulation elements, regardless of what hardware it's thrown on. So then crazy stuff starts happening: people get to fire infinite rounds from a turret weapon without having to reload the magazine, other people can't get modules to activate in the first place. Ships that are blown up stay on grid, long after the pilot has woken up in their medical clone. Weird stuff.

All that will happen if you double the processing power of the hardware is that you'll get double the number of people piling into a fight before the weird stuff starts happening.

So time dilation is attempting to address the issue by preventing the weird stuff from happening. It does this by removing the restriction on "one second" of simulation time taking one second of wall-clock time. So if you pile twice as many people on grid, you end up with "one second" of simulation time taking two seconds of wall-clock time (as an example). Weird stuff is held at bay: everyone can activate and deactivate modules, people don't get to fire infinite rounds without reloading, etc.

Can you see that these are two different paths to address the problem of "they keep adding ships to the fleet until it lags"?

Hardware path: add more processing power so the server can handle more ships on grid

Software path: do funky stuff on the server so the processing power we have can handle more ships on grid

You'll have to start posting longer comments in more popular threads from now on.

TL;DR.

Anyway, i see. Referring to the software as the "server" makes more sense.

And thx again for the explanation, but i know how it works already
and you're still using "the server is slowing down", which still is wrong anyway.

YOU don't get that part.

Writing stuff like this means people jump on, having no clue and repeating this.

Even if your intention is good, it's still crap.
There's no reason to believe the server is slowing down/speeding up, because that's not happening.

That's - at best - a simple explanation for all of those who do not get what's happening anyway
and then these misinformed people take this information and spread it around ... and that's bullshit.

I agree with most of what you wrote, because it's simply true and states the facts,
but the server is not slowing down. The server is slowing simulation time down, yes.
But the host is NOT slowing down. ^^

The software is NOT getting executed slower ! :)

If the server has lag, people know there are too many people on grid.
So, if they know there are too many people on grid,
they know the server* can't cope with what's going on ... it's too much.

Means, when people say "the server is slowing down" we get a hell lot of people having
no clue about what's really going on, just repeating stuff they've heard or read and didn't understand
and then go ***** around with their half-assed wisdom pretending to know what's happening
and claiming that THE SERVER IS SLOWING DOWN, WHICH HELPS LAG!

So, the server is slow already and is slowing down even more because that helps lag.

WOW, THAT MAKES SENSE ! :)


That's my whole point.
People are idiots. Look at who started this thread,
look at other threads about time dilation.


As an example for clarification of what i'm talking about:

in help-chat a noob came in and asked why some of the wrecks are yellow.
One guy answered "it means HANDS OFF" and i bitched at him because that's simply not true
and told the noob that, what he actually meant to say, is: "this wreck belongs to somebody else."

We had an argument for about 10 seconds ... *lol* ... he gave in when i told him that
his words will lead the noob to a totally different way of thinking,
which can affect the whole noobs life just because of the bias he creates with HANDS OFF !
(if bias is the right word to use here)

So ... the server is not slowing down.
Please stop educating people the wrong way.


Thx.



*actually, host would be more correct in this case, because it's the host who executes the code
and there's more code to execute per second than the host can cope with.

How so? This is probably one of the most crippling blow to the effects of server overload to ever be implemented.
No.
It already is, of a sort.

As a programmer, I find TiDi pretty darn interesting as well as impressive.

Yep.

I really don't have anything to add other than that haha. Only thing I can say is I wish more games would, or rather, should, make use of this.

Correct me if I'm wrong but as I understand the following happens.

First let me explain how a server handles stuff.

A host (eve online server) can only handle X amount of request and can only send X amount of information to the other players about those request. Request being the input of players (keyboard clicks and mouse clicks) and information being the collection of those request.

So If I press the (warp button) the server handles my 'request' sends information back to my pc and my pc handles that information, the host also sends information to all the other players in that area. So there is a constant input and output of the information and requests that needs to be handled by the server and saved to a database (chache and hard saved).

The sending of information by the host is handled in so called 'packages' which are bundles of information.
The sending of information by the client (us the players) is handled by a single line of information (not a bundle)

People tend to mix up lag allot with choke and loss

• This is Loss:

Lets say the server can handle 1000 request every second.
The server can send 1000 bundles of information a second as well.

Now when 5000 people do a request to the server at the same time, the server can't handle the input anymore.
What happens is that the bundles that get send back to the clients (we the players) do not contain all the information that the 5000 people send to the server. That’s called loss.

• This is Choke:

Lets say I send a request to the server Request A and Request B. Request A is send back in information bundle 1.
But where is Request B? Request B could not be handled in bundle 1 and is send with bundle 2. This is choke.

• This is Lag:

The time it takes for your computer to talk with the server.
If you have 200ms that means it takes 200 milliseconds for your pc output to reach the server and then another 200ms for the server to respond again. That is a total of 400ms (almost a half of a second, for shooters this is allot) You have a ping of 400.

Now to my understanding TiDi doest not solve lag at all, it solves choke and loss.

What it does is give the server more time to create the bundles of information (slowing down the server) so 5000 people punt in a request to the server. The server now takes 5 seconds instead of one second to build up the bundles of information and send it back.

Conclusion

Choke is information send back in a different bundle that expected.
Loss is information lost during the translation of a request to the information bundle send back
Lag is nothing more then information traveling slower then wanted.

Lag and los and choke are ofcourse related to each other, lag results in choke, and choke results in loss.
So you can opt to fix lag or you can opt to fix loss and / or choke and leave lag as it is.

Lag can only be solved by more / faster hardware or as World of Warcraft does it, just giving a message back that your request can't be handled right now. CCP opt to fix it trough fixing choke and or loss.


TiDi does not fix lag, it fixes choke and loss making battles better predictable


Edit: fixed some mistakes.

Bob Jan