timerres boot.ini option possible speedup

[leeperry]

The quick brown fox jumps over the lazy dog

[Inventive Software]

What's the performance difference between that and the default?

[leeperry]

The quick brown fox jumps over the lazy dog

[iron2000]

The boot.ini option reference can be found here too:
http://technet.microsoft.com/en-us/sysinternals/bb963892.aspx

Feel like trying it, but I don't really understand it.
Is it like overclocking?

What is this 0.98 ms?
Some kind of CPU rest time?

[leeperry]

The quick brown fox jumps over the lazy dog

[Liisachan]

*If* the timer resolution itself is the problem (it's a kinda big 'if' though), anyone can change it programatically by calling timeBeginPeriod(1) without changing the boot settings etc; changing is meaningless if the timer res. is already 1 ms (that is the case for me), but true, it's not 1 ms by default, so it *might* actually help some users under some situations.

[Dark Shikari]

it's the latency basically.

the smaller it is, the more cycles are processed every second

no it's not overclocking, it's merely optimizing :DI'm pretty sure the only performance-related thing the timer resolution could affect is to increase the number of context switches or kernel calls, which would mean lower performance.

[leeperry]

The quick brown fox jumps over the lazy dog

[cyberbeing]

What CPU do you have leeperry?

[leeperry]

The quick brown fox jumps over the lazy dog

[foxyshadis]

So..... do you have timecodec results to back it up, or just anecdotes? ('The plural of anecdote is not data') If the tweak isn't meant to result in timecodec changes, do you have any evidence that any lower cpu usage you see actually translates into better performance and not just changing the cpu usage accounting?

[leeperry]

The quick brown fox jumps over the lazy dog

[Shinigami-Sama]

its the same thing as using ATM rather than ethernet I think...

[Px]

/timeres decreases the system timer resolution from 7.8ms to 0.98 :eek:
Use /usepmtimer switch...

[leeperry]

The quick brown fox jumps over the lazy dog

[Px]

this seems to be an AMD-only fix.
No.
In Microsoft Windows Server 2003 and in Microsoft Windows XP, a program that uses the QueryPerformanceCounter function to query system time may perform poorly. For example, if you run the ping command at the command prompt, you may receive low or incorrect latency values.

Note This problem occurs on computers that are running an x64-based version of Windows or an x86-based (32-bit) version of Windows.
Also, problem occurs on all milticore cpu's...

[check]

and timecodec is not very accurate on my system, I can run it 5 times on the same file.......each time it will give a different result ?!So you have no proof? Telling everyone about a weird change like this is just bad manners unless you back it up with proof. Too many newbs will just try it and risk screwing up their system. Post some timecodec results. Run timecodec three times in each configuration and post all six of your results please.

[leeperry]

The quick brown fox jumps over the lazy dog

[Inventive Software]

That's not what he asked. 3 times on a "standard" config, 3 times with this new switch. It's not hard. ;)

[check]

so we're talking a more nervous load balance and a slight performance improvement.
I did my own tests, since you didn't. Here are the results:
without /timeres=9800:
#1:
User: 13s, kernel: 1s, total: 14s, real: 109s, fps: 2450.0, dfps: 330.5
CPU Time (from process explorer): 2:35
#2:
User: 10s, kernel: 0s, total: 11s, real: 108s, fps: 3150.9, dfps: 332.1
CPU Time (from process explorer): 2:37

with /timeres=9800:
#1:
User: 13s, kernel: 0s, total: 14s, real: 118s, fps: 2511.1, dfps: 306.0
CPU Time (from process explorer): 2:46
#2:
User: 13s, kernel: 3s, total: 16s, real: 122s, fps: 2159.4, dfps: 294.8
CPU Time (from process explorer): 2:58
Hopefully this should be proof enough for you to stop recommending this placebo (although since its harmful you can't really even call it that), but feel free to prove me wrong with your own tests.

the guys on audioasylum are basically HTPC nazis, if they advise to use this thing.....they have a very good reason I doubt it. I am another fan of the previously mentioned quote: "The plural of anecdote is not data".

[leeperry]

The quick brown fox jumps over the lazy dog

[check]

but if you had read carefully, I personally added :
I don't believe the difference between a timer resolution of 0.9766 and 0.98msec would cause a difference in my results and your anecdote.
and I didn't "recommend" it, I said you might wanna give it a shot....do you understand the difference ?
Your first post on this topic mentioned the tweak and said you found it helped a lot with your decoding. If this doesn't imply a recommendation, I'm not sure what you feel does in an online forum.



You originally asked "let me know if I'm crazy". I'm telling you that your belief here is incorrect, and unless you or someone else can show my results are wrong - or at least provide results to the contrary by making some up! - I'm going to stand by that statement.

[leeperry]

The quick brown fox jumps over the lazy dog

[Sharktooth]

leepery: /timeres is a placebo. period.
it's not (as you said) an optimization or a "kind of magic"...
unless you need low latencies for some special purpouses (like realtime midi instrument sampling), it's practically useless or can even harm the system performance...
also high precision timers exist since NT days... it's nothing new while HPET is another story... and has nothing in common with the /timeres option.

[leeperry]

The quick brown fox jumps over the lazy dog

[clsid]

Please stop polluting this topic and continue this discussion elsewhere.

[leeperry]

The quick brown fox jumps over the lazy dog

[Inventive Software]

I'd ask a mod to split these relevant posts to a separate thread, since they don't really exclusively belong here. ;)

[Sharktooth]

agreed. please split.
however just FYI the windows task manager does not represent very well what's happening, every coder knows it...

[leeperry]

The quick brown fox jumps over the lazy dog

[foxyshadis]

Don't delete the thread unless you have the moderator's or admin's approval, just because you aren't happy with the discussion.

[leeperry]

Don't delete the thread unless you have the moderator's or admin's approval, just because you aren't happy with the discussion.
well I gave this tip on a friendly basis.
but there's too many haters on this forum........I don't mean to be friendly with brainless flamers.

I am allowed to delete my own threads if I want to, yes ?!
what is this ? China ? Russia ? :D

[Inventive Software]

Editing posts to mock the thread is baiting for a strike. ;)

[leeperry]

yeah ban me, I'll create a new account

I can delete my own posts if I want to, I am the sole holder of the intellectual property on my own posts.

[GrofLuigi]

Can this utility (http://technet.microsoft.com/en-us/sysinternals/bb897568.aspx) help in measuring/verifying this? The tweak doesn't do anything for me, I have two uniprocessor pc's.

GL

[check]

I'm still interested in this topic, seeing as the only two tests performed are in direct opposition to each other. Can anyone else provide some timecodec results?

[leeperry]

if you had a bit more brain, you would understand why timecodec can't beneficiate from this load balancing tweak :rolleyes:

but you all are too damn smart for me :eek: , I leave you alone now :D

[Sharktooth]

once again... a fast timer only matters for real time applications (http://en.wikipedia.org/wiki/Real-time)...

[Liisachan]

You catch more flies with honey than with vinegar :) You might actually find something interesting so let's stick to the subject.

I'm not sure if the timer in question is the Multimedia Timer, but I don't think it is the high-resolution performance counter of CPU, so for now I assume it's the MM timer, and here's this small tool for testing on that assumption.
http://ffdshow.faireal.net/tmp/test.7z
It's just a hello world thing VC automatically generated PLUS timeBeginPeriod (http://msdn.microsoft.com/en-us/library/ms713413(VS.85).aspx)(1) on WM_CREATE and timeEndPeriod(1) on WM_DESTROY.

When you start test.exe, the global Windows setting will change and the timer res will become 1ms (if it is not already). When you close test.exe, the old setting is restored.

So, if the timer in question is this one, and if it is really helpful, then things will work better while test.exe is running, and things will work slightly worse after you close test.exe. Hypothetically, that is. This way you can do many tests without rebooting with different boot settings. At least that's what I intended.

I'm not sure about ffdshow, but timeBeginPeriod(1) is actually helpful in some situation. For example see the following page:

Results of some quick research on timing in Win32
http://www.geisswerks.com/ryan/FAQS/timing.html

[Sharktooth]

@liisachan:
/TIMERES=
Sets the resolution of the system timer on the standard x86 multiprocessor HAL (Halmps.dll). The argument is a number interpreted in hundreds of nanoseconds, but the rate is set to the closest resolution the HAL supports that isn't larger than the one requested. The HAL supports the following resolutions: Hundreds of nanoseconds Milliseconds (ms) 9766 0.98 19532 2.00 39063 3.90 78125 7.80 The default resolution is 7.8 ms. The system timer resolution affects the resolution of waitable timers. Example: /TIMERES=21000 would set the timer to a resolution of 2.0 ms.

[Liisachan]

@Sharktooth Thank you~ So it's related to semaphore timeout for instance? Hmm, in my limited knowledge the only situation I can think of where such a high-res timer may help is, like WaitForSingleObject would give up quickly as soon as it should give up after time-out, thanks to fine time granules, so in all things might work slightly faster than with lo-res timers... but i don't think the difference is significant. Plus, hi-res timers are cpu-intensive themselves too. The screen shots provided as an alleged evidence only show the 2% CPU load difference, not really significant either, unless it's an average value over many trials...

Since Windows is somewhat "mysterious" OS (aka a black box), something weird might actually happen. and I'm not going to say it's impossible just because it's unlikely. Of course I need some evidence to believe what is said, but I also need some evidence to disprove it. But well, something tells me I shouldn't waste time for this^^;

[leeperry]

Sharktooth has now been successfully added to your ignore list.

ok that's a good start :D

thanks for the constructive info Li, I might consider running a hidden window with your test app :)

[Sharktooth]

@Everyone: DO NOT alter /timerres it may SLOW DOWN the system since a higher rate timer will require more CPU cycles and may even harm the normal operations. also encoding is not a real time application and wont benefit at all from the higher resolution timer.

[leeperry]

actually there's already a command line version :
http://www.solariz.de/aoc/20-aoc/83-aoc-fps-boost-english-description

some additional info on timers :
http://www.codeproject.com/KB/system/timers_intro.aspx

Waitable timers were introduced with Windows 98 and Windows NT 4.0 (which means that we need to define _WIN32_WINNT >= 0x0400, or _WIN32_WINDOWS > 0x0400 before we include windows.h, to work with them), and their main purpose is thread synchronization.

oh my....maybe I was right after all, you pathetic pricks :D

I'm just not sure where Vista's HPET fits in all this, though...

[Sharktooth]

he still do not understand the meaning of SYSTEM TIMER and what /timerres does.

[blutach]

Both Sharktooth and leeperry.

Please remember rule 4. If you disagree with something a member has said, just post your correction. No need to call people morons or pricks.

If I see this again, there will be R4 (double) strikes, which would be unfortunate for 2 long-standing members.

Regards

[Sharktooth]

i already explained the reasons for not doing that "tweak" but still he's suggesting and insisting on the fact it is "better" and "he was right" while setting the system timer so low may only harm the performance and lead to possible system instabilities (expecially for some kind of drivers).
also "we dont understand... blah blah"... he also removed his post where he said that setting was a sort of "kind of magic" and a "load balancing" option... he said it will even lower the CPU temp... go figure...
so maybe ppl reading his posts may be tempted by his suggestions to add the /timeres option and may end up with an unbootable or unstable system (as i said, some drivers may not be happy with a faster timer...) that may even lead to data loss.
this thread was also splitted by a mod from the ffdshow thread since he was polluting it with an offtopic and questionable discussion:
the guys on audioasylum are basically HTPC nazis, if they advise to use this thing.....they have a very good reason
that's quite silly expecially coz a member of this forum already proved with some tests (using timecodec) that timer option does nothing good while he (leepery) attached a task manager screenshot that proves exactly nothing (we all know the task manager is not good for certain things... it wasnt showing big differencies anyways).
that's all.

[leeperry]

Both Sharktooth and leeperry.

Please remember rule 4. If you disagree with something a member has said, just post your correction. No need to call people morons or pricks.

If I see this again, there will be R4 (double) strikes, which would be unfortunate for 2 long-standing members.

Regards

good thing some op woke up, those very smart people have been calling me names for quite a while now :D

I gave a system tweak as a friendly advice, and check and sharkbooth started calling me names.......strangely enough, you didn't say anything at this time ? :D

I wanted to delete this thread, but foxyshadis undeleted it...

[foxyshadis]

oh my....maybe I was right after all, you pathetic pricks :D

Too far over the line, struck for rule 4. I really see no reason for your childish behavior ever since the tweak was questioned, others were relatively more respectful until you became downright hostile about it.

Sharktooth: Drop it, as blutach warned.

To all: There are all kinds of ways the tweak can be meaningful. (Sharktooth mentions one of the harmful possibilities.) It may well not show up on timecodec. It may well skew task manager into reporting incorrectly. The only absolute way to check is to dig deep into the system and count cycles spent waiting on waitable timers, which I don't know of a tool to do, or more coarsely, test your system's temperature in a very controlled manner (if it shows any meaningful difference within the bounds of statistical error). I would thoroughly benchmark the system in a controlled manner, especially your favorite games, x264, etc, if you try it, and make sure all of your devices are compatible.

[Liisachan]

Another interesting thought experiment would be a series of double-blind tests, where you'd have to guess if the boot settings are tweaked or not. If you claim you can feel the performance improvement and if the claim is true, then you should be able to pass the test with a significantly high probability.