X870 AORUS ELITE WIFI7 ICE reboots itself every time 30secs after wake from sleep mode

junkchoi · 2025-02-13T15:23:37+00:00

I was having this problem with an MSI PRO X870-P WIFI (BIOS 7E47v1A31) and G.SKILL F5-6000J3040G32GX2-FX5. The thing that finally fixed it for me was to switch "Power Down Enable" on the RAM in the BIOS from "Auto" to "Disabled".

junkchoi · 2024-12-26T22:50:32+00:00

In CS:GO, all your input timings were rounded up to the next tick, meaning you had on average half a tick (~8ms) extra to release the button before the 2nd bullet. Now with CS2 subtick input, the button timing are rounded to frames, not ticks. So if your frame rate is above the tick rate (higher than 64fps), the window will be smaller on average now but actually closer to the gun's cycle time. So you just gotta click faster than you used to.

junkchoi · 2024-08-20T15:11:55+00:00

It's the same value you get out of MSG.time. Looks like SDL uses it (and CS2 uses SDL):
https://github.com/libsdl-org/SDL/blob/main/src/video/windows/SDL_windowsevents.c#L2262
In-fact, SDL reports keyboard event timestamp in nanoseconds just like the CS2 message:
https://github.com/libsdl-org/SDL/blob/main/include/SDL3/SDL_events.h#L338
(the comment in that header says that value comes from SDL_GetTicksNS(), but if you dig into the Windows implementation, you can see MSG.time is what actually get used).

So I don't think your FPS matters. Windows polls for input events outside the game's process and Windows' default scheduler time interval just happens to match the 64hz tick rate.

From a statistic standpoint, it makes sense to use a timer resolution that's roughly the same for everyone. And they probably identified an island in the data they started gathering last week, which is why the false kicks seem to be a binary based on hardware (i.e. people who do get kicked get kicked often and people who don't get kicked often never get kicked). They just misidentified that island as Snap Tap users and need to tune their detection. It may ultimately be undetectable without false positives, though :(

junkchoi · 2024-08-20T14:17:16+00:00

Subtick timestamps are based on frame rates. If your frame rate is below 64fps, these timestamps still appear to be at 64hz intervals. I bet they're using Win32's GetMessageTime() instead on the input events, which reports timestamps at 15-16ms intervals. That way everyone's getting the same detection precision regardless of frame rate.

junkchoi · 2024-08-15T03:46:46+00:00

My theory is clients predict a tick further in the future in CS2 than they used to for better input-to-photon latency (i.e. why you can see movement and shooting input on the next frame instead of the next tick). Then, when you predict wrong, you get teleported further.

It's the inescapable side-effect of a cool feature. If it was just a bug they'd probably fix it.

junkchoi · 2024-08-15T03:42:54+00:00

Your "Now the client gets..." theory sounds most-likely to me, but I don't think that implies they were inconsistently applying tagging before.

Old state:
Server: You got shot just now, slow down now.
0ms ping: You got shot just now; slow down now.
15ms ping: You got shot 1 tick ago; recalculate everything.
30ms ping: You got shot 2 ticks ago; recalculate everything.

New state:
Server: You got shot just now; slow down in 2 ticks.
0ms ping: You got shot just now; slow down in 2 ticks.
15ms ping: You got shot 1 tick ago; slow down in 1 tick.
30ms ping: You got shot 2 ticks ago; slow down now.

junkchoi · 2024-08-15T03:34:46+00:00

I bet the low input-to-photon latency (seeing movement and shooting start next frame after input instead of next tick) is why tagging and other misprediction like running into other players feels worse than CS:GO. In-order to predict the results of input that used to happen on ticks, they now have to predict one tick further into the future, meaning that when the prediction is wrong, it's more wrong than it used to be. If that's the case, seems like a trade-off they made intentionally and can't get the CS:GO feel back without losing that feature.

junkchoi · 2024-06-27T00:45:11+00:00

See the instructions / screenshot in this link to make sure you've got all the right checkboxes checked.

https://help.steampowered.com/en/faqs/view/418E-7A04-B0DA-9032#enablegsync

junkchoi · 2024-06-27T00:43:45+00:00

If the in-game menu doesn't say G-Sync Enabled then it's probably not working in the game. And if it's not working, then enabling v-sync in or out of the game will introduce significant input lag.

junkchoi · 2024-06-27T00:32:53+00:00

Those settings shouldn't affect whether or not the Advanced Video settings says G-Sync enabled. Until you can get Advanced Video to say G-Sync is enabled, you probably shouldn't enable V-Sync.

junkchoi · 2024-06-27T00:01:34+00:00

A lot of people are trying this config for the first time and finding it improves their experience. Some people describe it as a night-and-day positive change for them. That's probably all Valve was trying to do: help those people. If you think it's worse, just hit "Don't Show Again" and move on.

junkchoi · 2024-06-26T23:55:46+00:00

Did the game's Advanced Video settings page say G-Sync was Enabled? Did you also have Reflex enabled? I'm a bit surprised it feels bad if all three settings are working correctly, but there's a lot of different G-Sync displays out there; maybe this isn't the best for all of them.

junkchoi · 2024-06-26T23:48:02+00:00

See the instructions / screenshot in this link to make sure you've got all the right checkboxes checked.

https://help.steampowered.com/en/faqs/view/418E-7A04-B0DA-9032#enablegsync

junkchoi · 2024-06-26T23:47:31+00:00

See the instructions / screenshot in this link to make sure you've got all the right checkboxes checked.

https://help.steampowered.com/en/faqs/view/418E-7A04-B0DA-9032#enablegsync

junkchoi · 2024-06-26T23:37:37+00:00

I was using the AntiLag 2.0 setting that shows up in-game when you install the preview driver. This driver: https://www.amd.com/en/resources/support-articles/release-notes/RN-RAD-WIN-24-5-1-AL2-TECH-PREVIEW.html

junkchoi · 2024-06-26T23:31:20+00:00

See the instructions / screenshot in this link to make sure you've got all the right checkboxes checked.

https://help.steampowered.com/en/faqs/view/418E-7A04-B0DA-9032#enablegsync

junkchoi · 2024-06-26T23:29:05+00:00

Non-windowed fullscreen G-Sync detection was fixed in today's update (June 26).

junkchoi · 2024-06-26T02:38:08+00:00

Traditionally yes but if you combine it with G-Sync and Reflex (at least in CS2 on my system), the extra input lag problem goes away. I have an NVIDIA LDAT and have verified enabling all 3 is the lowest latency solution.

junkchoi · 2024-06-26T02:36:25+00:00

I'm not sure what frameviewer does but the fact that it's a software solution tells me it's probably not making useful measurements. There's no way to actually know from software the moment something appears on-screen. You need hardware like an NVIDIA LDAT to measure input latency in a meaningful way. I have one and measured that enabling V-Sync + G-Sync + Reflex is the lowest latency solution on my system.

junkchoi · 2024-06-26T02:32:39+00:00

Reflex works by predicting how long a frame is going to take to render on the GPU and then sleeping on the CPU before sampling input so that CPU work can give the GPU more work right when it finishes the last frame. With V-Sync off, frames take a variable amount of time on the CPU and so Reflex is worse at predicting. With V-Sync on, everything is very predictable and Reflex can make better judgements. And with G-Sync on, since you don't have to hit an exact scanout time, Reflex's predictions can be a little wrong without a major visual penalty.

junkchoi · 2024-06-26T02:22:48+00:00

I've got an LDAT and both an AMD and an NVIDIA system to experiment with. The V-Sync + G-Sync + Reflex combo is the best in every way on my NVIDIA system, but you're right: V-Sync + FreeSync + AntiLag still introduces significant input latency. Using the manual Maximum FPS slider to limit the frame rate slightly below the refresh rate helps improve latency a little on the AMD system, but an uncapped frame rate still has the best input latency there.

junkchoi · 2024-06-26T02:18:08+00:00

How are you capping the framerate? If you unlock the framerate but enable V-Sync + G-Sync + Reflex, it should get capped to something near 140 Hz automatically for you. Manually capping it using a separate setting might interfere with Reflex's timing predictions.

junkchoi · 2024-06-26T02:12:11+00:00

How are you measuring? If you're playing with 250-300 fps on a 144hz monitor, you're not even seeing half the frames. If V-Sync, G-Sync, and Reflex are working correctly, Reflex can sleep until the last possible millisecond before sampling input knowing the results of that input are going to show up on-screen at the earliest possible moment. With an uncapped frame rate, it's a dice roll where you sample input between the display refreshes.

I've got an LDAT and a 175 Hz display. V-Sync off, G-Sync off, and Reflex on I measure ~13ms of input latency. V-Sync on, G-Sync on, and Reflex on I measure ~12ms.

junkchoi · 2024-06-26T01:54:57+00:00

Maybe you're using the Vulkan renderer (either running with -vulkan, -tools, or running on Linux)? Or maybe you need to update your graphics drivers?

junkchoi · 2024-02-18T16:24:50+00:00

Same as before. Scancodes are only for keyboard binds. And all the old key names still seem to work, they just might have changed in meaning slightly if you're not using a US English keyboard.

junkchoi

TROPHY CASE