Please help me avoid false positives from wPrimes' anti-cheat system for 24hour+ runs

[DrSwizz]

I have been benching some old system (mostly 486 and early Pentium) and I have been having serious issues with wPrime.

No matter what I do wPrimes cheat detection system seem is being triggered around midnight. I have experimented with with different settings for the system (cache/system/memory timings; over/underclocking etc), but no matter what I do the anti-cheating system still gives me false positives. Could someone please help me out?

Edited September 4, 2010 by DrSwizz

[Christian Ney]

Are Bios clock and Windows clock same ?

[DrSwizz]

Are Bios clock and Windows clock same ?

 

I was not aware there was a difference between them. I never adjust the clock thru windows, I only set it in the BIOS.

[Christian Ney]

ok so if you set it correctly into the bios before installing windows, it is going to be the same

Edited September 5, 2010 by Christian Ney

[Antinomy]

What OS and wPrime version do you use?

[DrSwizz]

What OS and wPrime version do you use?

 

I have had this issue on several systems: I have used NT 4.0sp6, XP SP1 & XP SP2

[Antinomy]

Very strange. wPrime 1.55 and additional libraries installed?

[DrSwizz]

Very strange. wPrime 1.55 and additional libraries installed?

 

Yes I am using version 1.55. I might not have installed the CPU-Z 1.44 "library" on some of the rigs though (I don't really remember).

 

At first I thought the systems "only" where unstable, but two weeks ago I began experimenting with underclocking for a contest a Xtremesystems. At one point I was running wPrime on three systems simultaneously and wPrime detected that "I had cheated" on all of them more or less at the same time.

All the systems where underclocked and had relaxed timings for memory/cache/system busses.

That convinced me that this must be an issue with wPrime and not with my software/hardware.

[Christian Ney]

In fact it's not after 24 hours, it's at 0:00:00 am. Midnight

I had it several times with my Pentium MMX 166.

I don't know how to fix.

Maybe killing windows clock, but I don't know how to do

[knopflerbruce]

change the clock during the run, perhaps?

[Christian Ney]

Duing 50 days ? , I will try changing the clock to see if it s reconized as a cheat.

[Dead Things]

I know I'm bumping a really old thread here, but I was just wondering if you guys managed to figure this one out?

[moi_kot_lybit_moloko]

sorry for necrobumping.

cyrix/ibm 6x86l pr166+ (66*2 stock) @ OC 165mhz (83*2) benching wprime 1024m, and after 82% (~12hours benching) write me "cheat detected". wtf?!

 

[moi_kot_lybit_moloko]

omg, anyone help me?

[_mat_]

If I remember this correctly from work on integrating wPrime in BenchMate, it uses the WIN32 API functions GetTickCount() and GetLocalTime() to measure time. The resulting timestamps are compared and if they differ too much, you'll get this error message.

Both functions rely on the RTC to return the current time. The difference is that GetLocalTime() does depend on some synchronization to avoid time drifting, so the clock in the task bar always shows the correct time. If the PC is connected to the internet, the synchronization might come from a remote time server. If that's the case, cut if off from the web.

But there are is another anti-drifting measurement available in Windows since forever. It's called "System Time Adjustment" and it can be disabled by code. A quick search showed up the following tool, although I have no clue if the executable works on XP (the technique itself does of course):

https://github.com/jschicht/SystemTimeAdjustment