Don't know what you're seeing there, the causality usually goes the other way round: renderers of MMOs rely on the network code on no small part, because the server tells the client which dynamic objects are within drawing distance. The client is allowed to guess and extrapolate to some extend, but this only goes so far. So usually, a higher latency begets a lowered FPS. Haven't heard that this also works vice versa -- until now

Btw, the value that is displayed in-game isn't the sole network latency between your machine and the data center gateway. It's a value inherent to the server cluster and factors in system load of your zone, load on the database, etc. I like to think of it as an "average command processing duration", and it usually is much higher than the ICMP Echo_Request round trip times (a.k.a. ping). E.g. here in Germany, I get a quiet steady ping between 11 to 13 ms to the server farm in Frankfurt/Main. In-game, I usually see a value of 50 on average, up to 150.

Thank you both for the replies. It clarifies a few things.

chris.dillman wrote: »

The higher the frame rate the more free time theres is to spend processing user input and game events.

This is the confusing part for me. If it's not processed on a per-frame basis, how does a higher-frame rate allocate more time to process? If anything shouldn't that be more taxing on the computer?

Shouldn't there be an option to lock the framerate allow the computer to process that on the side?

Don't forget that we're dealing with an MMO, and not an FPS, here. Clients and Server are synchronized by ticks or heartbeats, i.e. the game won't update for anyone before the next tick. Would it come as a surprise that some MMOs internally run with ticks of about 500 ms? Granted, those games have a GCD of 1000 ms or more client-side.

The issue of key-polling is a non-issue for MMOs, really. ESO runs fluid and responsive on the PTS from the EU, and it ran fluid and responsive when the EU server cluster was still in the US. And we're talking about pure ICMP roundtrip times north of 140 ms here. Anything related to "lag" is often caused by the increased server-side system load of large-scale PVP battles, stretching the time in-between updates for everyone within the same zone thread, no matter whether they run 5 FPS or 150 client-side (EVE online even tells the clients about this when need arises and calls it "time dilation").

Why isn't input polling running in a thread of it's own? If it was more advantageous to do it this way, it wouldn't have been done already? ESO isn't a single-player first person shooter, not even an online, multiplayer one. Doesn't matter whether the clients send 10 or 100 or 1000 keystroke packets every tick (but indeed it would, DDOSing your inbound data center gateway doesn't seem so be so clever), as only the last one gets considered for the next tick. Or however some algorithm determines the action to be considered server-side (LOTRO had an input queue, btw, which was quite nice to have. But then again, LOTRO was anything but twitchy).


Edit: Where...? There was a question to my answer, once... Ok, keeping it for future reference, should the question arise again.

Gix wrote: »

I used to get the issue where objects were not loading fast enough when you enter a building... that was when I running the game at 60fps. At 60fps, I sometimes had to wait a full minutes to load the WALLS of an interior area; I'd just be there floating in the sky with NPCs, crates, tables, slowly appearing into view.

Now I changed screen resolution, running the game at 110fps and now objects (and walls) load near-instantly.

The issue of slowly loading wall and floor textures is an older one, seemingly introduced with patch 2.0.1. I haven't seen it anymore in version 2.1 on the PTS, where my frame rate is roughly the same with equivalent graphic quality settings I have on live.