This solved the physics/time glitches for me. I now have ipresentinterval set to 0. I'm running windows 7 x64. Thanks so much moshemoshe, I'm glad I read through the whole thread because I haven't seen this mentioned anywhere else.

Not sure how the DirectX override will effect this. As it stands now, it is capped to 60 so even if the monitor runs at 120Hz, it may only go to 60. Could be something to keep in mind when testing this.

Although it won't make too much difference, shouldn't the minutes be divided by 0.6 to get the decimal equivalent? Sorry for the nitpick, it turned out to be rather useful advice since my days and hours had also gone rather awry...

Edit: for the impatient, setting the timescale to a higher value e.g. 60 will speed up the "minute hand" part of the process. Don't forget to check its initial setting so you can change it back!

what is "useplatformclock"? Google turns up muddy

This right here is proof that this game is a straight port from consoles, every PC dev team worth half a [censored] knows you can't rely on frame timing on them. Consoles meanwhile? Yep, steady FPS (unless you're really pushing it, probably don't rely on frame timing in this case though), steady timing.

One could argue that even where the framerate should be fairly reliable, it's still incredibly bad practice to use it instead of the real-time clock for long term timekeeping. It does look like one of those instances of "why go to the trouble of reading the manual to do it properly when this hack will do..."

I'm merely comparing 1500 FPS v-sync off with 20-30FPS (and very sluggish mouse) v-sync ON. At any rate, I get these numbers only in the menu, and no, my hardware is not defective or being harmed. I'm on WinXP BTW, perhaps that is why i'm not experiencing the dramatic shift in sunset/sunrise times.

Yes, they are designed to do exactly that. A GPU at stock clocks with stock cooling is guaranteed to be capable of running 100% 24/7, assuming it has enough airflow for the cooling system to work. If a GPU wasn't capable of doing so, it would be considered defective.

As a bit of an example, this is the reason that it is possible to overclock. All chips have different performance values - some run cooler at high speeds, others run hotter at low speeds. Unless the company is binning the chips into different performance levels, they will set the performance levels of the product to that of the weakest performer (or something close to it). This allows them to guarantee that what they sell can perform at least as well as they are saying it can. Some can do better (sometimes much better), but none (or at least a negligible number) will do worse.

In a tangentially related matter, this is similar to why there are likely more than 100 paperclips in a box advertised to have 100 paperclips.

If you have vsync on, you should also have triple-buffering on (You can force it on from CCC or the NVidia control panel). It deals with the input lag and slowdown issues you get.

I was playing with this and having essentially no issues, and no crashes (with the LAA fix), although the recent patch took LAA away and blocked it.

Unfortunately, the Triple Buffering option in the NVIDIA control panel is only for forcing it in OpenGL games. To force TB in D3D games you need e.g. D3DOverrider (part of Riva Tuner).

But you will run into problems if you're using the FXAA Injector or any other D3D hook, since tools like D3DOverrider or Fraps can't hook into these. But there's a solution: you can use ENB Series Skyrim Patch as the primary hook into D3D. In its enbpatch.ini you can tell ENB to use a proxy library, so rename your d3d9.dll from the FXAA Injector to something like d3d9_fxaa.dll and tell ENB to use it as the proxy library.

Since Fraps and D3DOverrider are able to hook into ENB's d3d9.dll (thank god!) and ENB uses FXAA's d3d9_fxaa.dll afterwards you will get the benefits of all four: display fps, force Triple Buffering (and/or V-Sync), ENB's Skyrim patch #5 and the Injectors FXAA and/or post processing effects (sharpening, tone mapping etc.).

Activating triple buffering on my HD6950 doesn't entirely solve the mouse lag, it still feels very prominent even though it got better. However, for some reason i also get a bit dizzy when i move fast (prolly more a result of VSync itself).

I've made sure vsync is definitely on but I've found that my day/time thing has got even worse. I'm not sure if it's as a result of tinkering with the gamehour setting or if it's one of those problems where once you've got it, you can't get rid of it...

TB can help to reduce input lag by certain amounts but it doesn't eliminate mouse lag entirely. The main benefit, and this is why I recommend it, is that it eliminates fps caps introduced by vsync. V-Sync alone (with Double Buffering) can reduce fps to nearly the half.

You could try to lower the value for frames rendered ahead to 1 or 0 to reduce mouse lag. Look for such a setting in your graphics card drivers control panel, often called "Flip queue size", "Render ahead frames" or "Maximum pre-rendered frames". The default value for this setting is 3.

More Info on DB, TB and V-Sync: http://www.anandtech.com/show/2794/1

It just occurs to me that a possibly easier way to get the time and date in synch may be to do the following:

• Get the value of gamehour, e.g. 8.34
  
• Get the value of gamedayspassed, e.g. 12.18
  
• Divide gamehour by 24, so in this case you get 0.347.
  
• Replace the fractional part of gamedayspassed with the new value, i.e. 12.347.
  
• If this causes the clock to go back in time, such as gamedayspassed initially being 12.92, add 1, so you get 13.347 instead.

A quick test indicates this seems to work, although I'm not totally convinced that tampering with the variables in question is entirely safe or reliable.

Edit: an alternative approach, if gamehour is a safer one to fiddle with, is to use the same method to calculate it from gamedayspassed, i.e. multiplying its fractional component by 24.

There are several ini tweaks available that should fix lag for most people, no im not talking about the one that was posted at launch.

http://skyrimnexus.com/downloads/file.php?id=337

I do not recommend copy and pasting the files, instead take your time and add all the extras at the bottom of each category into your own files.

If you still experience lag you can always adjust it.

While this should work, the issue for myself and some others who can't seem to get the fix to stick seems to be the game calculating the days passed slower than the clock:

For simplicity's sake, I set gamehour and gamedayspassed to 00.00 and 180.0000, respectively, which was my "next day." That should mean that at the following midnight my day will roll over on time, right? Except it didn't... at 12am my gamedayspassed was 180.9606. When I tested this on my beginning save, the game rolled over correctly and the gamedayspassed value was in synch with the gamehour.

In summary, the issue for myself and a few others seems to be that the gamehour is passing faster than the actual gameday. Gonna see if I can find a console command that shows the day interval used to calculate time passage and see what's going on.

Update: On further testing, I think it may have something to do with going over 100 days. I tried that fix again and it seemed to work, but my gamedayspassed was showing as 18 instead of 180. When I reset it to 180 time started slowing down again. Any of you good at maths know a way to write it out so that too many numbers doesn't confuse the engine?

Can't edit so a follow on:

This has nothing to do with vsync and everything to do with how many days you played. Let me know if you can duplicate the bug because I've been able to.

1. Load a save with less than 100 days
2. Wait until right before the day turns over WITHOUT using wait/rest... just sit around in real time. Use "show gamedayspassed" when the day changes and note the value. Should be around 11pm, for whatever reason.
3. Reload the save, "show gamedayspassed," then use the command "set gamedayspassed to 182.xxxx". Don't change the decimals, just move the day over 100. Wait again without using wait/rest and you'll notice the day won't roll over at the same time. Use "show gamedayspassed" again and you'll see that time has actually slowed down.

I'm no expert but I'm guessing the third number for the day is throwing the decimal off and time slows down when you get into triple digits because the clock and the gamedayspassed are out of synch.

I've dropped the timescale to 12 (which I suppose could have a bearing on it, but didn't seem to in the early part of the game) so gamedayspassed isn't as high: 63 in my case. But the problem I'm seeing is that gamehour is regularly lagging gamedayspassed, and no matter how many times I reset it, within just a few minutes of playing there's already a difference. It doesn't seem to be related to vsync since it's definitely on now, but I guess it could be related to the amount of time that's passed: it certainly wouldn't be the first time Bethesda have managed an overflow or rounding error. I think that seems like quite a reasonable theory.

I'm having the same issue with my date as well, my day is changing at 9pm, and I have iPresentinteraval=1 in my ini.

How do i enable triple buffering for my Nvidia GTX580? I know about the option in the control panel of my drivers, should i enable it there and then am good to go or?

Okay, I have some news on this from my end: for me, using the command prompt (bcdedit /set useplatformclock true) failed to fix this, and it did not matter whether V-Sync was on or off, the game time still fell out of sync regardless.

This leaves one possibility: modified timescale. I normally play with the timescale set to 8, but the game's default timescale is 20, and the day timing might have been built around that, with Bethesda assuming that no one would change it. I am going to see if that has any merit.

My apologies in bumping a thread that was 15 pages back, however I have the same issue. I copy/pasted my Skyrim folder located under My Documents to my external drive then deleted it from My Documents. Afterwards, I uninstalled Skyrim via Steam and then reinstalled it by downloading (as opposed to installing off disc). I did not alter the ini files in any way nor did I use my previous save files. I started a new game and by the time I reached Riverwood my day was changing approximately 30 minutes ahead of schedule. I am running an Intel E8500 stock clock at 3.16Ghz, 4GB of ram and an ATi HD 6870 at stock clock (minus the fan being manually set to 40% at all times) with Win7 Pro as my OS. I did not try the time fix via the OS on this save but I did on my previous save and it did not have any noticeable difference. I'm running at Ultra settings with 4xAA and 8xAS and it runs fairly well.

edit: One thing I did notice was that my bindings for my left and right hands had stayed even after re-installation (I had set left mouse button for left and right mouse button for right hand). I checked and didn't see that this game uses Steam Cloud (unless I missed it) so does that mean there would be residuals left after an uninstall?

Im pretty sure you have to manually delete the skyrim .ini every time you un/re-install your game, otherwise it wont get deleted. Well either that or there something left in the registry, pretty sure its the ini not getting deleted though.

Aye I copy/pasted it to my external drive then deleted it.

The iPresentInterval variable causes the game to "smooth" the interval between displayed frames. If you set it to 0, frames will run as fast as possible, making the game appear to run faster and stutter less. But this is 100% guaranteed to cause problems.

The reason problems happen is that Bethesda's games use animation frames as timers. Scripts run every frame, and most events are not timed on the basis of elapsed time but on the basis of elapsed frames. The iPresentInterval variable introduces a delay to make the execution time of each frame appear more consistent, so that frames in which a lot of script code runs take about the same amount of time to run as those in which little or no script code runs.

Setting iPresentInterval to 0 caused similar bugs in Fallout3 and Oblivion. Doing that fixed the "microstutter" problems and made the game appear smoother, but it caused scripted events to go out of synch with animations. The most obvious effect was that dialogue was no longer lip-synched; the longer a NPC spoke, the more out-of-synch their face became with their speech. But more serious problems would eventually occur.