mIRC Home    About    Download    Register    News    Help

Print Thread
$uptime errors after 7 weeks+ of uptime #10221 08/02/03 08:49 AM
Joined: Feb 2003
Posts: 3
B
BBug Offline OP
Self-satisified door
OP Offline
Self-satisified door
B
Joined: Feb 2003
Posts: 3
frown View the screenshot. It's happened on 3 other occasions as well.

View the image:
uptime screenshot

Re: $uptime errors after 7 weeks+ of uptime #10222 08/02/03 09:42 AM
Joined: Dec 2002
Posts: 349
S
Skip Offline
Fjord artisan
Offline
Fjord artisan
S
Joined: Dec 2002
Posts: 349
yep, apparantly this is an issue with windows tracking uptime in milliseconds, and the variable it uses to track only being a type int, meaning it will set back to 0 at roughly 49 days. heres a paragraph I grabbed from an online c++ tutorial which explains it better:

"We just saw that a data type whose size is 1 byte can store 256 distinct values. Data types of size 2 bytes can store 28*2 = 216 = 65536 different values. Using the same formula, we determine that data types of size 4 bytes can store 28*4 = 232 = 4,294,967,296."

//echo -a $duration($calc(4294967296 / 1000))

Obviously there _is_ a second variable that increments when this value is reached (which allows windows itself to stay correct), but mIRC isn't using it. Its anyones guess when this will be fixed.

Hope that helps. smile


edit: another explanation is that the variable mIRC itself uses to track uptime is of insufficient byte size, not windows. The result would likely be the same. -shrugs-

Last edited by Skip; 08/02/03 09:44 AM.
Re: $uptime errors after 7 weeks+ of uptime #10223 08/02/03 12:38 PM
Joined: Feb 2003
Posts: 8
O
Oliver Offline
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
O
Joined: Feb 2003
Posts: 8
i second Skip's explanation, the problem is that $ticks is an unsigned long (or unsigned int) value, i just wanted to add that the maths of what he pasted got a bit messed up while pasting:
2^(8*2) = 2^16 = 65536 for 2 bytes (16-bit)
2^(8*4) = 2^32 = 4,294,967,296 for 4 bytes (32-bit)

hope, that makes a bit more sense to those who tried to type it into their calculator smile

Thanks guys #10224 09/02/03 07:18 AM
Joined: Feb 2003
Posts: 3
B
BBug Offline OP
Self-satisified door
OP Offline
Self-satisified door
B
Joined: Feb 2003
Posts: 3
Thanks for the mathematical explanations. I was never good at math and never got that deep into programming.

Hopefully a later version of mIRC will resolve this issue grin

Re: Thanks guys #10225 11/02/03 06:23 AM
Joined: Feb 2003
Posts: 42
G
GregMo Offline
Ameglian cow
Offline
Ameglian cow
G
Joined: Feb 2003
Posts: 42
I thought the topic here was mIRC's $uptime. I've not ever known it to work...

//echo -e $duration($uptime)

returns: 4days 8hrs 16mins 1sec

While: //echo -e $duration($uptime(system))

returns: 5672wks 4days 6hrs 9mins 3secs

and yet: //echo -e $duration($calc($ticks / 1000))

correctly returns: 5wks 4days 17hrs 14secs

Cheers,
GregMo


Re: Thanks guys #10226 11/02/03 06:46 AM
Joined: Dec 2002
Posts: 46
L
LtGuide Offline
Ameglian cow
Offline
Ameglian cow
L
Joined: Dec 2002
Posts: 46
$duration($uptime(system,3))
without the 3 (check /help $uptime) it returns in milliseconds, when $duration takes seconds


evil is in the eye of the beholder
Re: Thanks guys #10227 11/02/03 06:51 AM
Joined: Feb 2003
Posts: 42
G
GregMo Offline
Ameglian cow
Offline
Ameglian cow
G
Joined: Feb 2003
Posts: 42
Yeah, silly me I suppose. I assumed it would be seconds like other uptime systems. If it's going to return milliseconds don't much see the point in it what with $ticks

Cheers,
GregMo

Re: $uptime errors after 7 weeks+ of uptime #10228 11/02/03 09:24 AM
Joined: Feb 2003
Posts: 30
A
Algorithms Offline
Ameglian cow
Offline
Ameglian cow
A
Joined: Feb 2003
Posts: 30
mIRC is using an unsigned long (4,294,967,295) to hold the information for $ticks, which amounts to 7wks 17hrs 2mins 48secs of uptime before it starts over at zero.

A simple change to double would give you:
1.7e+308 or 1.7 * 10^308

This amounts to a VERY large holder for $ticks able to handle any uptime you will EVER have, ever, ever :tongue:


Bluesock - Better than a redhat.
http://www.bluesock.com
Re: $uptime errors after 7 weeks+ of uptime #10229 11/02/03 10:53 AM
Joined: Feb 2003
Posts: 30
A
Algorithms Offline
Ameglian cow
Offline
Ameglian cow
A
Joined: Feb 2003
Posts: 30
Note: if the grab of the current tick count since boot is being done via .NET API the longest I know of to attain would be 24.9 days before a reset ( Using System.Environment.TickCount which uses a 32bit signed integer in Managed C++ ) and 49.7 days before a reset with the Platform SDK ( Using timeGetTime() )

My post about using a double assumed using an ASM call to rdtsc which grabs a 64bit value of the cycles since system boot and saves it in EDX:EAX. then grabing that value and storing it in a double. This would allow for proper tick value of systems with extended uptimes. (seconds = cycles / frequency) This seems well worth it to me, no? :tongue:

* Added API calls per Hammers request.


Bluesock - Better than a redhat.
http://www.bluesock.com
Re: $uptime errors after 7 weeks+ of uptime #10230 12/02/03 01:33 PM
Joined: Feb 2003
Posts: 8
O
Oliver Offline
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
O
Joined: Feb 2003
Posts: 8
aye, aye...

just wanted to add that $uptime returning milliseconds kinda does have a point if you want to know the ms mIRC is or a server connection is up... that it also returns them for system then doesnt hurt smile so things are not "pointless" just because theres more than one way to do them (addressing GregMo here wink)
as for Algorithms.. true, true.. but... nobody uses double for integer values smile thats floating point and no operating system stores its ticks or any counter in floating point values :P however.. theres 64-bit integer values.. in64 or hyper.. whatever they are called in whatever compiler =P
and the 18,446,744,073,709,551,616 milliseconds it could hold would equal about 584,942,417 years, 129 days, 14 hours, 25 mins and 51secs, an uptime frequently reached by windows, as we all know

Re: $uptime errors after 7 weeks+ of uptime #10231 12/02/03 09:57 PM
Joined: Feb 2003
Posts: 30
A
Algorithms Offline
Ameglian cow
Offline
Ameglian cow
A
Joined: Feb 2003
Posts: 30
Agreed, __int64 would be a more correct type (but double can play a subsitute for a an unsigned long value even when not needing floating point accuracy depending on implementation)

I remember when I hit 584,942,417 years, 129 days, 14 hours, 25 mins and 51secs of uptime, aww memories. :P


Bluesock - Better than a redhat.
http://www.bluesock.com
Re: $uptime errors after 7 weeks+ of uptime #10232 13/02/03 02:17 PM
Joined: Feb 2003
Posts: 8
O
Oliver Offline
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
O
Joined: Feb 2003
Posts: 8
hmmm, even tho this is way off the topic it started with... :tongue: double cant be a substitute, because it has a smaller integer range than int64, double has 1 sign bit and 11 exponent bits, left are 52 fraction bits that could be used for integers, but 52bit is not enough to replace 64bit integer maths... you COULD produce much bigger numbers with double, of course.. but then would have huge jumps between the integers.. and not all of them in consecutive order :P (i just love talking about numbers.. is all.. ;P)

Re: $uptime errors after 7 weeks+ of uptime #10233 13/02/03 07:39 PM
Joined: Feb 2003
Posts: 30
A
Algorithms Offline
Ameglian cow
Offline
Ameglian cow
A
Joined: Feb 2003
Posts: 30
I never said you could subsitute a double for an int64 type, I said an unsigned long type wink.


Bluesock - Better than a redhat.
http://www.bluesock.com
Re: $uptime errors after 7 weeks+ of uptime #10234 16/02/03 01:23 AM
Joined: Feb 2003
Posts: 8
O
Oliver Offline
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
O
Joined: Feb 2003
Posts: 8
ah right

good point, well made :P however.. initially you were suggesting to store the ticks in a 64bit value.. which double simply cant hold ;P

but you said unsigned long, yes.. yes.. that would do.. i hereby take my last bitching back ;P