Issues, Workarounds & Localization

Yes. Once the client clock starts to drift relative to the server all sorts of wierd crap begins to happen :

Traffic control on gates; unable to dock; unable to warp; grid won't load; grid will load but won't update; no shield; no armour; no cap; drones disappear, scan probes vanish never to be seen again.

That's just the ones I've seen in the last 3 years, there's probably more.

Only reason I know about this is because I have a laptop with dual NVidia cards where DPC latency (delayed protocol calls) goes through the roof when you set SLI focus on a window. You're looking at tens of milliseconds latency which adds up very very quickly.

SLI full-screen or just run single card and its fine but when run in a window with SLI focus I've seen the laptop clock drift by up to 5 minutes per hour. Its not a hardware fault, its software in my case.

Another historical cause of clock drift was the spread spectrum setting on some motherboards. With it set on then the clock would drift every time the machine was powered on. That may still be the case on laptops where spread spectrum is enabled by default and in most cases cannot be altered.

My solution to client clock drift was to set the machine to update from a stratum 2 timeserver every ten minutes. Windows7 by default only updates time once a week - if the default server actually responds, which in my experience is hit and miss.

HTH.

Edit - the problem is caused because your client clock is changing relative to the server while you are playing, it doesn't matter if your time is 10 hours out as long as it doesn't drift while connected to the server.

I'm not going to mess with my stable clock settings just to play EVE. That is stupid...

Cant be a hardware issue on my part.

6 Core 4800 GHZ Processor
16GB Ram @ 1800 MHZ
1GB ATI Graphics Card

Slightly annoying to say the least...

Hello again!

Our test-server Singularity was updated today with a (potential) fix for this issue. We had to change a bit more than expected, but we are hopeful that the new solution is more stable than before.

I had a short test of this in Singularity, but it would be awesome if you guys (who have this issue on TQ) could try it out! If you already used the test-server at some point or you always wanted to try it: Now is the time for it!
Details: The client is now re-synchronizing with the server every 10 minutes (the time interval might be changed later).
If you are trying this on Singularity, then please take special care of your UI in space after you were logged in for about 10 minutes. Try to jump and dock. It would be great if you are running logserver.exe to get logs for the case that anything breaks - more info at http://wiki.eveonline.com/en/wiki/Logserver. Please send a bugreport if you find any issues (add my name to the title of it) and please also reply in this thread - I will continue to monitor it. It might be possible that 10 minutes is still too long for you guys (if your clock is drifting too fast) and you still have some load lag: please reply in this thread if this is the case.
More information about Singularity can be found here: http://wiki.eveonline.com/en/wiki/Singularity

No, this is not an ATI issue.

I have the same problem and I'm running Eve on a laptop with nVidia Quadro FX 2700M gfx card.

I'm guessing this is more of a client issue rather than a server issue since chat channels work normally, as does local, and if I'm in a fleet, the FC can fleet warp me between celestials eventhough I don't see any of it.

When the system does load, the client sort of tries to catch up with everything that has happened eg. I can see fleet members warping from the gate when they aren't even in the same star system anymore.

For me, Eve has been running smoothly (well, as smoothly as Eve ever has *cough* signed: a software tester) up until Crucible. Not so much anymore.

This is single-handedly the most annoying bug I have come across in Eve as it's literally killing me - I've already lost 2 ships + 2 pods because of this bug.

I don't mind losing ships in battle but I find it hard to accept it when I get podded with implants in a situation where I can do nothing to even try to defend myself.

.d

Edit: I'm happy to see there is a potential fix for this issue (I made the original post before reading the thread all the way). I truly hope you can get the fix to production soon! :)

I was able to find a workaround for this on TQ! By default, the Windows time syncs via NTP with "time.windows.com". I switched it to sync with "time.nist.gov" instead, and that seems to have solved this issue with Eve. I have played for hours without noticing the slightest bit of jump lag.

Habakuk, I've sat and watched the drift time and I begin to see a noticeable difference between my PC clock and the in-game clock at about four and a half minutes. Sometimes it take 6-7 but I've been in a few heavy load systems today and it's making itself apparent quite quickly.

Glorious CEO: Thank you a lot for testing it on Singularity!

DurrHurrDurr: How much is a noticeable difference for you? It might be useful, if you could save a logserver log of being ingame for at least 30 minutes while doing stuff and adding this to a bugreport (with the subject including my name).
For the release of this fix: As the fix is a bit more complicated it is not possible to "hotfix" it - it is currently scheduled to be included in the next client patch for Crucible 1.1.

Caroline Grace: These symptoms look a lot like problems with the clock sync - but it might be that your clock is sometimes a bit too fast and sometimes a bit too slow, which would explain the different issues.

This is some serious clock drift, which you are experiencing there - I'm not sure if we will ever be able to compensate this fully, but it should be at least better with this fix. The instructions for logserver can be found at http://wiki.eveonline.com/en/wiki/Logserver.

As far as I know (as lowly QA dude): Before Crucible there was a clock sync at jumping (which was broken with Crucible), but if you stayed within one system you should have drifted like it is now on TQ.

Is there any possibility that the clock sync at jumping could be reinstated or is that something that's not going to happen?

I can deal with desyncs and weird HP/capacitor readings in-system but this drift from system to system makes travel in any kind of quick or efficient manner unrealistic.