Bug 1235 - cpufreqd makes game to run too fast
Status: RESOLVED FIXED
Alias: None
Product: Unreal Tournament 2004
Classification: Unclassified
Component: client
Version: 3120 (Initial demo release)
Hardware: PC Linux
: P2 major
Assignee: Ryan C. Gordon
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2004-02-17 18:02 EST by Ludwig Nussel
Modified: 2004-03-07 11:41:10 EST
0 users

See Also:



Description Ludwig Nussel 2004-02-17 18:02:29 EST
The game runs way too fast on AMD64. E.g. Players can run and shoot at least 
twice as fast as on x86. The worst thing is that this even works over the 
Internet. 
 
Computer is an Athlon64 3000+ with SuSE 9.0/x86_64
Comment 1 Andrew 'ashridah' Pilley 2004-02-19 16:12:10 EST
Hmm. have you tried checking that the 'slomo' command has been set to 'slomo 
1'? 
It's possible to run the game from 50% to 150-200% speed based on a 
server-side setting, and i'm fairly certain it gets saved. 
 
Andrew 
Comment 2 Ludwig Nussel 2004-02-19 16:44:23 EST
It's not server side, the intro movie is already too fast. It was this way  
when the game was first started and I didn't change any settings that are not  
in the gui.  
Comment 3 Ludwig Nussel 2004-02-21 12:59:57 EST
Ok, it's not related to the 64bit version. Unter 32bit suse9 it also runs too 
fast. 
Comment 4 Ludwig Nussel 2004-02-21 14:47:34 EST
We found the problem. It's cpufreqd. A recent BIOS update enabled this 
Cool-n-Quiet stuff, which causes cpufreqd to clock down the CPU when the 
system is idle. During normal Desktop usage the CPU runs at 800MHz, when 
running a game at 2000MHz. I guess UT based games have some calibration loop 
at the beginning that gets confused if the CPU changes it's speed dynamically? 
(Postal2 also runs too fast with cpufreqd enabled) 
Comment 5 Ryan C. Gordon 2004-02-22 11:18:07 EST
Hhm...we have some fixes for UnrealEngine3 so we don't rely on RDTSC (which
Cool'n'Quiet and other related technologies make unreliable)...will see about
backporting them to UnrealEngine2 (which ut2004 and postal2, etc, use).

--ryan.

Comment 6 Ryan C. Gordon 2004-03-02 15:10:13 EST
I believe this to be fixed internally now...we now rely on gettimeofday()
instead of the rdtsc instruction; I trust that cpufreqd will alter the kernel's
gettimeofday() reponses appropriately?

I'll send on a new demo build for SuSE to test shortly.

--ryan.

Comment 7 Ryan C. Gordon 2004-03-02 16:18:06 EST
Here's an unsupported binary (i.e. - don't package it in an .rpm or whatnot):

    http://icculus.org/~icculus/tmp/ut2004demo-lnx-cpufreqd-fix.tar.bz2

Please test with and without cpufreqd and see if it fixes the issue.

This is for the 32-bit version of the game, but the same fix should apply to
amd64 if this takes care of the bug.

Thanks,
--ryan.

Comment 8 Ludwig Nussel 2004-03-02 16:42:36 EST
I don't have have access to the system where it happened atm. Maybe I can try 
it tomorrow. 
Comment 9 Ludwig Nussel 2004-03-07 11:41:10 EST
works fine now with cpufreqd enabled