mIRC Home    About    Download    Register    News    Help

Topic Options
#10221 - 08/02/03 08:49 AM $uptime errors after 7 weeks+ of uptime
BBug Offline
Self-satisified door

Registered: 08/02/03
Posts: 3
frown View the screenshot. It's happened on 3 other occasions as well.

View the image:
uptime screenshot

Top
#10222 - 08/02/03 09:42 AM Re: $uptime errors after 7 weeks+ of uptime
Skip Offline
Fjord artisan

Registered: 09/12/02
Posts: 349
Loc: Darwin, Australia
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-


Edited by Skip (08/02/03 09:44 AM)

Top
#10223 - 08/02/03 12:38 PM Re: $uptime errors after 7 weeks+ of uptime
Oliver Offline
Nutrimatic drinks dispenser

Registered: 07/02/03
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

Top
#10224 - 09/02/03 07:18 AM Thanks guys
BBug Offline
Self-satisified door

Registered: 08/02/03
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

Top
#10225 - 11/02/03 06:23 AM Re: Thanks guys
GregMo Offline
Ameglian cow

Registered: 11/02/03
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


Top
#10226 - 11/02/03 06:46 AM Re: Thanks guys
LtGuide Offline
Babel fish

Registered: 26/12/02
Posts: 46
Loc: Jacksonville, NC, US
$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

Top
#10227 - 11/02/03 06:51 AM Re: Thanks guys
GregMo Offline
Ameglian cow

Registered: 11/02/03
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

Top
#10228 - 11/02/03 09:24 AM Re: $uptime errors after 7 weeks+ of uptime
Algorithms Offline
Ameglian cow

Registered: 11/02/03
Posts: 30
Loc: Portland, OR
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

Top
#10229 - 11/02/03 10:53 AM Re: $uptime errors after 7 weeks+ of uptime
Algorithms Offline
Ameglian cow

Registered: 11/02/03
Posts: 30
Loc: Portland, OR
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

Top
#10230 - 12/02/03 01:33 PM Re: $uptime errors after 7 weeks+ of uptime
Oliver Offline
Nutrimatic drinks dispenser

Registered: 07/02/03
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

Top
#10231 - 12/02/03 09:57 PM Re: $uptime errors after 7 weeks+ of uptime
Algorithms Offline
Ameglian cow

Registered: 11/02/03
Posts: 30
Loc: Portland, OR
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

Top
#10232 - 13/02/03 02:17 PM Re: $uptime errors after 7 weeks+ of uptime
Oliver Offline
Nutrimatic drinks dispenser

Registered: 07/02/03
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)

Top
#10233 - 13/02/03 07:39 PM Re: $uptime errors after 7 weeks+ of uptime
Algorithms Offline
Ameglian cow

Registered: 11/02/03
Posts: 30
Loc: Portland, OR
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

Top
#10234 - 16/02/03 01:23 AM Re: $uptime errors after 7 weeks+ of uptime
Oliver Offline
Nutrimatic drinks dispenser

Registered: 07/02/03
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

Top