[nos-bbs] Potential Timer Issue in JNOS

fish810 fish810 at yahoo.com
Sun Aug 1 23:15:22 EDT 2010

Looking more at msclock() in the NO_GETTOD section.  Even though NO_GETTOD is 
normally not defined, if it is defined:

struct timeb.millitm is defined as an unsigned short int (16 bits).

I'm pretty sure it's not a good idea to multiply it by 1000 and then add 100000 


#ifdef NO_GETTOD
    static struct timeb t;

    t.millitm *= 1000;
    if (t.millitm < Starttime.tv_usec)
    t.millitm += 1000000;
    return (t.time - Starttime.tv_sec) * 1000 +
    (t.millitm - Starttime.tv_usec) / 1000;

From: fish810 <fish810 at yahoo.com>
To: Maiko Langelaar (ve4klm) <maiko at pcs.mb.ca>
Cc: TAPR xNOS Mailing List <nos-bbs at tapr.org>
Sent: Sun, August 1, 2010 5:20:21 PM
Subject: Re: [nos-bbs] Potential Timer Issue in JNOS

Hi Maiko,
I just happened to notice that msclock(), defined in unix.c returns an 
'int32'.  msclock() computes the number of milliseconds since JNOS was started, 
right?    When that value rolls over, after ~24 days- could that cause what we 
are seeing??
Sure hope it turns out to be that simple :-)

 From: Maiko Langelaar <maiko at pcs.mb.ca>
To: TAPR xNOS Mailing List <nos-bbs at tapr.org>
Sent: Sat, July 31, 2010 4:23:15 PM
Subject: Re: [nos-bbs] Potential Timer Issue in JNOS

Evening to all,

I'm working on it. I want it fixed too ...

Unfortunately it's not just a matter of setting the linux
clock ahead by 24 days and voila - problem surfaces. It's
a bit more complicated than that.


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/20100801/b21a9983/attachment.html>

More information about the nos-bbs mailing list