[nos-bbs] Update - Timer issues in JNOS

fish810 fish810 at yahoo.com
Wed Aug 4 13:04:00 EDT 2010

Sounds reasonable to me.

Alternatively, if one millisecond resolution isn't required, what about changing 
msclock() so that it returns an unsigned int containing the number of elapsed 
TENTHs of a second?

Then we would have roughly 52 * 100 days before rollover.  That's over 14 years 


From: Maiko Langelaar <maiko at pcs.mb.ca>
To: TAPR xNOS Mailing List <nos-bbs at tapr.org>
Sent: Wed, August 4, 2010 9:51:11 AM
Subject: Re: [nos-bbs] Update - Timer issues in JNOS

I'm just posting this in case anyone is interested or sees
a flaw with the approach I'm using.

After thinking about this a bit more, I've concluded that perhaps
there is a much better, much easier way to do this, and one which
involves minimal code changes.

Changing to unsigned only fixes the problem for another 25 days, after
a period of 52 days or so, the negative timer problem will resurface,
since going from signed to unsigned only doubles the maximum value.

Moving to a long will fix this on x86_64 systems, but not on  i386 systems,
since long and int are same size on those systems. I could really minimize
the code changes by instead keeping the original code, and just resetting the
NOS start time every 20 days, and create a '20 day counter' that will get
bumped up every 20 days. Minimal code changes, and it will work as long as the 
20 day counter never overflows (which it won't). The counter in
conjunction with the start time can easily tell us the 'uptime'.

I've already checked and if I start changing stuff from signed to unsigned
or whatever, there is more code changes than I really care to make.

Any comments ?


nos-bbs mailing list
nos-bbs at tapr.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20100804/ae7d7faf/attachment.html>

More information about the nos-bbs mailing list