Yup I feel like I am in a world where no one understands wtf is going on.Originally Posted by kingpotnoodle
As for people saying the BCLK isn't reliable enough for timing.... I think they don't understand how inaccurate the ticks used for timing are, and how fast BCLK is. The RTC is for something else all together (mostly when the machine ISN'T running).
throw new ArgumentException (String, String, Exception)
Pretty arrogant, condescending stance TBH. As I already said, I understand what's causing the issue. Have you never heard of normal clock drift? The RTC is *designed*, like other timekeeping hardware, to remain accurate enough for its purpose when taking into account possible environmental variables like temperature, supply voltage, etc. Last time I checked, no such claims are made about CPU base clock.
In theory, it should remain accurate, in the same way a cheap crystal oscillator should remain accurate enough for GPS positioning. In the real world though, that drift is enough to throw the lock off significantly, so time is added to the simultaneous equations used to calculate position, hence why an extra satellite is needed vs what you'd need if you had perfectly synced time with the satellites. I've done a fair amount of work with oscillators, in applications where tiny amounts of drift can break stuff significantly, and that's why we have more expensive crystal ovens and atomic frequency sources.
Back to the OP subject though, like I said, I've seen no claims that base clock is designed to be stable enough to keep RTC-accuracy time. I'm talking *regardless* of software overclocking.
@Kingpotnoodle: If it's not possible, how is it being done?
RTC, HPET, call it what you want. I'm talking about the hardware 'clock'.
Precision !=accuracy.
*sigh* its arrogant because people really have no idea what they are talking about. Ever programmed something that was time sensitive on NT? It isn't designed for it. The most 'accurate' timer you can get is 10 miliseconds. Or 100hz. My BCLK on this box is 200Mhz. Let's spell that out, 2 000 000 times faster, it is being divided down, I don't care how much jitter this might have, hell it could be a simple RC circuit. If the system isn't keeping that accurate enough, do you know how much hell there will be talking to PCIExpress peripherals? USB? NICs? None of them will work if you are out by just a little tiny margin of variance. The system measures the speed of this against the RTC, then assumes this will not change. If it does change, you will probably get a BSOD as bits that are asynchronous have massive differences of opinion.
Now as for the system running days on end? If you need any accuracy on the time, you've got big a problem. This is why people have real time kernels which do their scheduling in a different way. However these have drawbacks and this is why people use GPS receivers to sync their server farms.
Also RTCs are not brilliant. Many are simple RC circuits so have terrible drift overtime, hell how many people have found that changing the battery stopped their PC from BSOD'ing back in the 90s? The problem there is still relevant.
http://answers.microsoft.com/en-us/w...c-49011c788f68
I am actually angry because I am sad how people can't comprehend how such a simple thing works.
throw new ArgumentException (String, String, Exception)
Why get angry this is a simple discussion, I've been building, modding, programming and overclocking computers since 1974 even to the extent of hand soldering clock crystals into motherboards and why should people comprehend how an RTC works I haven't a clue about brain surgery but I hope that wouldn't piss of the surgeon if I needed an op.
Because people should actually read something about how these things work, before fetching their flaming pitchforks and starting a mob.
NT kernel not accurate at keeping time when it has something it doesn't expect done to it. That is it.
Using the RTC in the older manner is a legacy throwback, it doesn't make sense to do so, doing that will use power and waste CPU time, the RTC isn't fast at talking to you normally either!
People also have this idea that the RTC is accurate. It isn't on any that I've ever seen, played with, or had servers advertised to me.
Now the people who write the benchmark tools have a couple of options for resolving this at their disposal. They can code their benchmark differently!
For example the method described here:
http://cplus.about.com/od/howtodothingsi2/a/timing.htm
Simply won't work. But you could probably use the SMB and get reliable timings, it is just such API query will be slow.
The question is, does this API suffer from the defect?
GetSystemTimePreciseAsFileTime
throw new ArgumentException (String, String, Exception)
You're talking about precision, again, precision !=accuracy. A 1PPS output from an atomic frequency standard isn't terribly precise, but very accurate, vs basic oscillators at least. Some poor high-speed RC oscillator might run at say 10MHz, so far more precise, but if that's +/- 5% it's not terribly accurate. My point is that the hardware clock is designed to be accurate enough for purpose, and all I'm saying is I've not read that BCLK is designed similarly. Also, the hardware clock is sensibly decoupled from system clocks to avoid such drift problems.
That seems to be the point though, it seems it's not comparing against RTC/HPET very frequently on Win 8. And component communication isn't expected to keep time to that accuracy over minutes etc - the protocols are designed to compensate for clock drift, often with one side negotiated as the clock source, and using things like scrambling protocols to allow for clock recovery, amongst other uses. Synchronous communication requires very closely synced atomic clocks at either end.
It's nothing like that, and I acknowledged from the start it's likely a problem of very limited scope, but still potentially concerning in some circumstances nonetheless.
I.e. a bug which, like any other, wasn't foreseen by the developers.
HPET then.
Are we talking about the problem of Clock Drift during a PC that's running for a week, or a benchmark that is running for seconds?
The APIs you use are different.
The issue here is it sounds like they are using an older API which is more susceptible to the improvements in timing that have been made in win8/s2012.
MS have overhauled this area, and it is much better now (still way behind others). They are using an old API, changing a clock frequency and their timings are invalid. Well unless the API documents cover such things, I am amazed they didn't have this problem before!
The timing APIs have changed in the past, on a single core system they just used one of the CPU counter registers, that doesn't work well on multi obviously.
They have changed it again and brought in a much more accurate API, yet rather than update their code to use it on Win8, they have just gone for some publicity. It is a complete non story. There are damned fine reasons why you don't talk to these things (it's expensive, bottlenecking too!).
If you want accurate timings, you need to really understand what you mean, because such thing is impossible. You are in a pre-emptive OS.
throw new ArgumentException (String, String, Exception)
It is caused by some kernel driver, changing the timings.
Time not been kept by 3rd party thing changing timings isn't a bug. There is no guarantee in Ring 0 land of anything when you've got a 3rd party doing stuff. This is why I like the concept of microkernels, as they wouldn't allow this to happen. The overclocker simply couldn't change such frequencies.
It most certainly is not a bug.
throw new ArgumentException (String, String, Exception)
There are actually 2 RTC clocks one is hardware and battery backed and if the clock crystal is good quality is quite accurate, once the Machine boots the software clock takes over and reads the time from the hardware RTC but unfortunately is not very accurate it can only read to the nearest second and over a period of 24hrs it can be out by several minutes.
Two RTC's - I thought that there was just one? And I've always been told that the RTC in a PC/server was also affected by drift in the power supplied to it. Which, along with it's tendency to wander around meant that you couldn't rely on it unassisted for precise measurement. Certainly all the systems that I've seen that had to have consistent timings have been sync'd to a local (radio?) known-good timesource.
By the way guys, fascinating discussion.
Interesting to hear that the consensus of my betters (i.e. people who know more about the subject than I do) is that BIOS overclocking ISN'T going to screw up results. However, if I'm reading the erudite discourse above correctly, using one of those vendor supplied desktop OC tools - e.g. Asus AI Suite/Turbo V; Intel DCC, definitely DOES have the prospect of causing numerical, ahem, ... issues.
In which case the bottom line is that if you are going to OC, then do it "old style" (BIOS tweak) rather than by being lazy and pushing that "Overclock my system" button - at least on the newer Intel kit anyway.
Career status: still enjoying my new career in DevOps, but it's keeping me busy...
By the second clock do you mean RDTSC?
Part of the problem of time, is making the API fast to call. They want something that will happily run on a 1.2ghz ARM instruction set, as it would on a 3ghz super expensive xeon.
AFAIK the current implementation reads a memory mapped value, which is part of the kernel time ticking interrupt, which isn't really defined as anything other than the whole 15ms thing.
It really sounds to me like they just need to update their timing tool to use the new API at the very least!
throw new ArgumentException (String, String, Exception)
When I configure servers, Windows and Linux, I never leave NTP unconfigured and have them all sync to the same local time source. No commodity OS/hardware combo I've encountered manages to keep good time over more than a few days without such assistance, I track NTP adjustments with monitoring and the variance is often in the ms, left over days or weeks those ms become seconds and minutes. I've had some that would drift several minutes a day without NTP.
However over the short period of a benchmark run that variance *should* be insignificant... but when after OS start a fundamental clock in the PC is adjusted in a way that Intel say is no longer necessary, unsupported and probably unwise (thus it is reasonable in a normal PC to expect BLCK to be constant) then it's not really that surprising to me that this would cause problems.
Windows 8 sucks, and intel is an evil company, bloodsucking.... AMD and windows 8 ok, AMD and windows 7 OK Ok ok
That's very unfair. Windows 8 doesn't "suck", it's just the dumb way they implemented that does - I've got high hopes for 8.1 and, as I've said before, perhaps 9 will be something special.
Intel isn't "evil", they're just very, very large. End of the day they've got some pretty decent products and at least they are still catering for the enthusiast market.
Only truly evil IT company I can think of at the moment (excluding all those patent trolls) is Oracle. But that's just MHO.
Career status: still enjoying my new career in DevOps, but it's keeping me busy...
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
LinkBack URL
About LinkBacks
Reply With Quote
