So I’ve read that for warping, a “time to warp” of 2.3s is really 3s due to how the servers handle ticks.
So, question: Does this apply to weapon rate of fire too?
Thanks in advance…
1 Like
Yes or rather No, but…
The server tick thing is basically: the client and the server exchange updates once a second.
It balances out over time. So, if a weapon has a 4.2sec cycle time, then over a long period it will have fired on average every 4.2 seconds - the actual time of firing is recorded in more resolution that just unitary seconds. Do doing 100 damage every 4.2 seconds works out over time as 23.8dps, rather than 100 damage every 4.2 seconds (rounded up to 5) = 20dps. Bascially, every now an then the gun firing message slips into an earlier messaging tick.
It’s complex - it’s all to do with timing of messaging related to the timing of events. the Align and Warp time is where it is most noticeable, and you are right: the whole second boundaries are important in that case - and 2 seconds is the magic number, But it does depend on a few other things - mainly network performance.
So, as always the answer in Eve is “yes and no, but…”
And I got away without using the phrase “quantisation of time”!!!
8 Likes
Great answer…
So basically, as combat takes place over a “longer” period, don’t worry about it as “it” will average out…where as a warp is a single event were you are literally competing against milliseconds versus the dude with the scram.
Great to here…you just saved me a lot of pointless math…
Thanks for your time!
o7
2 Likes
…and a perfect summary. Thank-you.
Agree completely with the previous posters, but wanted to highlight this. Based in Australia, playing with people from all over the world, it’s been my experience that those in Europe will be calling points on things (after a gate jump, for e.g.) and my grid hasn’t loaded, which can be a little frustrating 
So the amount of time it takes for your client to ‘speak’ to the server can sometimes be >1sec and that can have a big impact on what you see in game.
Isn’t the internet wonderful!
Regards,
Cypr3ss.
1 Like
I’ll resist the opportunity for so many cheap jokes, but yes, you are absolutely right. The server cluster is in London and well connected, but latency is critical and from anywhere outside western Europe it’s going to be an increasing issue. You can’t (as I recall) easily test the network performance to the Eve Cluster as it (sensibly) drops pings rather than responds to them.
Generally for people on ISPs with connections to the major back-bone providers (the inter-net “proper”) then its not a cause of problems - but you can’t beat geographical distance. In general, and to CCP’s credit, Eve is relatively undemanding of the network for many tasks.
Pity those in New Zealand: the FC is calling and they’re still loading the 1950s.
(Sorry, but the temptation was too great…)
The guys in corp based in the UK & Germany seem to get amazing response times to the Eve servers, but guys in Denmark/Italy/USA did not (here I’m talking ‘insta-lock’ response times), which I find interesting.
Lol, it’s perfectly acceptable to joke about the Kiwis… some might say they’re asking for it. 
Regards,
Cypr3ss.
Yep, generally very good connectivity. I’m probably getting better than 15ms from here in the UK. From Australia that’s going to be nearer 150ms at best.
Insta-lock is more a feature of the ship you are using and the way you are fitting it. There’s fast, but then you can build for very high sensor resolution and that can lock in less than a server tick - and that’s what the trick is: “tick 1: ship seen on Grid” “tick 2: target and scramble ship” “tick 3: scrambled” (very simplified - once tick of lock time) - so if you can be away before the end of the second tick (being visible to scram landing), then you’re away.
That’s very simplified, there’s a lot of detail in there, but it’s a flavour, and why smartbombing - that doesn’t need the targeting tick - works to catch interceptors.
That’s inaccurate.
The client sends data to the server as soon as it’s being triggered. The timestamp is definitely being honoured and the server runs through all “events” in ordered fashion.
All cycle times are definitely accurate and not only accurate on average. If you don’t believe that you can actually time things to figure it out yourself, though it’s a pain in the ass to do so.
The reason why I know that the server definitely honours exact cycle times is because I am reliant on it when it comes to ganking stuff at a gate under sentry fire.
OK. I’ll give way to your knowledge.
The critical issue with the server side is needing to process all actions at the rate they are coming in - honouring the timestamps, but having to handle late messages. That process a second of updates per second where lag starts to happen. And where TiDi kicks in.
Real-time systems are difficult where a single state is needing to be honoured on each transaction (I’ve a background similar realtime transactional stuff).
A HUGE pain in the ass in a way. I really wonder how they’re doing it. I’d love to offer my own solution to their problem of “cramming more people into a system” … but they’re ignoring me. 
I can think of many approaches. The challenge is how do you handle an that comes in late but is timestamped ahead of actions you’ve already processed? That’s where ticks come in - it forms a window in time - miss being in that window and I’ll slip you to the start of the next. And you do an update to all clients at the end of the window telling them what the consolidated state now is. It’s one approach where the response is also important - i.e you can’t wait for all the clients before responding in case one person delays everything.
[Hard to do handwavy discussions in only text]]
Shy of spending a lot of time talking to Eve developers (which would be interesting) it’s going to be a lot of speculation on our side.
Which is the nice way of saying that the above is “thoughts without hard evidence” and thus probably wrong.
I only care about one single approach, which is the one I’d be going for: runtime generated code running on a real-time priority process owning a whole core.
- Allows for easy in-order execution, honouring the timestamps.
- Removes most, if not all, memory reads.
- Would allow late insertion of an “event” at the cost of thrashing the cache. Can not actually recommended this.
- Can easily be mixed with Python code, if required. No, I’m not talking about runtime generated python code. Talking strictly native x86.
From there I’d just expand.
More cores.
More nodes.
I’ve been doing that “everywhere I came across” at least once.
Linux and Windows aka x86 and on ARM, specifically on the Nintendo DS.
This is actually a good question. Given that TQ can’t run backwards in time, I guess all packages received after a certain “deadline” are getting processed in the next “tick”. I’m not actually fully convinced that it works that way, because of a thing about Destiny, the physics engine.
See … whenever you do something that affects “physics” you add a “one tick delay” to processing it, for some reason. This covers stuff like points, scrams, webs and movement, but not painting, dampening or shooting.
It’s the reason why we - as in, the collective of “us who did this” in the past - used to recommend attempting shooting insta-undockers immediately instead of pointing them, because locking and pointing can let the target get away, while locking and shooting doesn’t.
I assume that it still works the same way nowadays. I used to get a lock (aka a visible box on the overview), yet the target got away. The reason was that I’ve used a module which affected physics.
So, with that in mind, it might be the case that not all timestamps are being honoured as they are, but maybe physics related packages getting processed by Destiny adds a delay, maybe because it runs on fixed intervals like all physics engines out there, at least as far as I know. No idea how to add more detail into this.
I have no idea. These are really interesting implementation details, though.
1 Like
I completely agree - this kind of detail in a system is absolutely fascinating.
I look at Eve with a certain amount of amazement both that it exists and that it run as well as it does. They’ve solved some distinctly non-trivial problems in producing the sandbox we play in.
1 Like
…ask a question on which pizza is best, get a 12 hour lesson on the agriculture methods and history of wheat farming in Europe over the past 500 years.
Eve…got to love it.
Thanks folks!
2 Likes
Heh, but once you know all about where the wheat comes from (and how it’s produced) you’ll be better able to make a decision on which pizza is ‘best’ 
Regards,
Cypr3ss.
2 Likes
Now, flour is from wheat and you add yeast and water to make the basis of a good pizza. Though of course, you need to have the right type of wheat and also get the balances of the various parts correct.
Alternatively, you just make beer instead.
But, @Runa_Yamaguchi, you are absolutely right - its the depth of the rabbit hole that’s so interesting about Eve. You have to love it and wonder at it. We’re playing a game of laser firing billiard balls in a swimming pool - but its a joy!
2 Likes
The server doesn’t care about any timestamps from the client. An action coming in is timestamped when it is received by the server and all actions go into the queue as received. The client is then corrected, in the reply or next tick, on the state of the master simulation that the server runs.
6 Likes
@CCP_Explorer, thank-you. Of course! I should have thought it through (I’m an idiot security wonk not a developer). I was assuming a problem that didn’t have to be a problem in this case. It can be a challenge for the systems I more frequently work with.
I occasionally see the “temporal glitches” in the Eve client where the client resynchronizes with master.
I’ve so many questions I’m itching to ask, I find these big realtime systems fascinating, but I won’t impinge on your time. Thank-you for all your work on Eve - it’s unique.