|
Joined: Oct 2009
Posts: 11
Pikka bird
|
OP
Pikka bird
Joined: Oct 2009
Posts: 11 |
Hmm. Weirdness that sort of annoyes me.. Check this out..
On my primary computer "//echo $uptime(system,1)" returns the (exact) same uptime as "/run cmd /k systeminfo | find "Up Time" " (I've checked, by executing 'em lines like simultaneously ^^).
However, when I try the same thing on my old Thinkpad laptop (1.2GHz รก P3), the $uptime appears slightly higher(!) than what systeminfo gives me (no big diff; but still a marginal ~30 secs!). Really odd, don't you think?
Now, my question, is there any logical explanation to this that any of you guys (who may know what 'em lines really fetches for 'behind the curtains') know of..?
This is one of those things that could nah me for days, weeks... mad wondering etc.. ;^
Regards~
Last edited by Gewisch; 04/11/09 04:40 PM.
|
|
|
|
Joined: Aug 2004
Posts: 7,252
Hoopy frood
|
Hoopy frood
Joined: Aug 2004
Posts: 7,252 |
What speed and processor do you have in your "primary" computer?
If it is faster than a 1.2, then that might be part of the reason for the difference. However, since you state the variance is about ~30 sec., to my knowledge, your "primary" computer would have to be running at (or above) 12.0
A speed that, for a home system, I have never seen (or heard of) in nearly 30 years of working with computers.
While I don't know the details as to where/how mIRC gets it's information, my own tests show less than a one second variance between various machines ranging from a 2.0 (at the high end) to a 266 (at the low end)
|
|
|
|
Joined: Oct 2009
Posts: 11
Pikka bird
|
OP
Pikka bird
Joined: Oct 2009
Posts: 11 |
@RusselB, First, ty alot for your answer. By just reading your first line, I (all excited / wind up) must say I guess your post is prolly going to cover one "hyphothesis" that I've been working with inside my head.
Anyways, before I continue, let me post what I got when I stated this issue in a random #mirc channel on some network.
[18:46:10] <Zinob> oxicarus`: they probably meassure time in different ways. The most likely reason is that one get the system time when the system was started and subtract that from teh curent time. [18:46:40] <Zinob> While the other one calculates the up time by adding the cumulative time of all processes. [18:47:37] <Zinob> OR that both of them use the first mentioned method but one querys the BIOS clock (not overly likely) while the other one querys the system clock. [18:47:53] <Zinob> Windows time keeping is not very presize...
..which was in fact interesting, but I still cannot get the "consistency" from it, given the fact that I (as I described) get different offsets with different computers.
NOW(!) Back to my idea. It's like this. With THIS machine, my primary (dash stationary) 2.4GHz E2220 with 4GB RAM, I get the - satisfying - figures of "0 sec mismatch", eg. exactly the same uptime with systeminfo.exe as with mIRC's $uptime. Not roughly, but exactly!
Then, when I tried it on my girlfriend's computer, a couple of years old laptop (Centrino 2GHz w/ 1GB RAM), I got a shift on well around 10 seconds. mIRC's $uptime gave the slightly "better" uptime.
On my own - ancient - laptop, a Thinkpad X30 (Intel P3, 1.2GHz / 512MB RAM), I got a shift on around 40 secs. Also here, mIRC's $uptime showed a slightly longer uptime.
So by looking on results on these three computers, I came to wonder; was this a coincidence, or could it actually have something to do with the hardware per se..? I'm still in a quest though, a few more "labrats" that could come up with results would be nice. What do you think, overall?
Last edited by Gewisch; 04/11/09 06:32 PM.
|
|
|
|
Joined: Oct 2009
Posts: 11
Pikka bird
|
OP
Pikka bird
Joined: Oct 2009
Posts: 11 |
Interesting, indeed. The mysterious #mirc helper comes at me again: [19:39:17] <Zinob> oxicarus`: indeed the most common reason for this is due to the fact that the hardware generates Timer Interupts at regular intervals. And if windows is to buzzy it will dissregard these as it wel.. dont have time for them. [19:39:53] <Zinob> hence the clock of slower computers has a tendancy to drift backwards slowly [19:40:18] <Zinob> And the time accounting of running processes get kinda FUBARedWould be awsome if we could just "sum it up" to that it's like that, but still, would be awsome if Khaled could bump in here and explain his $uptime(system) function so we got clue ![wink wink](/images/graemlins/mirc/wink.gif)
|
|
|
|
Joined: Aug 2004
Posts: 7,252
Hoopy frood
|
Hoopy frood
Joined: Aug 2004
Posts: 7,252 |
Khaled has, on more than one occasion, made a direct comment in regards to the operations of mIRC, and I would not be a bit surprise if he did make a comment on this topic, but all we can do is wait and hope.
|
|
|
|
Joined: Dec 2002
Posts: 5,473
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,473 |
Well spotted :-) The reason for the discrepancy is that mIRC is using GetTickCount() to measure system uptime which may or may not return the actual uptime since it uses a relatively low timer resolution ie. the measured time will drift the longer the system is up. It also wraps around to zero every 49.7 days just to keep you on your toes. There are a number of other methods that mIRC could use to measure the real system uptime but they all have their own issues, such as being far slower than GetTickCount() which is used heavily throughout mIRC, or only working on some versions of Windows, or requiring administrator access, and so on. While I could have written a complicated routine that attempts to use several methods of retrieving the real system time, it seemed overkill. Ah the sweet, blissful simplicity of GetTickCount() ;-)
Last edited by Khaled; 05/11/09 10:50 PM.
|
|
|
|
|