[nos-bbs] Update - Timer issues in JNOS

[George [ham] VerDuin]

Hi Maiko.
We have no history of arguing, but I offer the following argument:


On 08/03/2010 01:45 PM, Maiko Langelaar wrote:
> Good day,
>
> >>SNIP<<
> To be honest with you, I'm not so sure I like the way the whole clock
> thing is done to begin with - seems like alot of work just so that we
> can keep track of when JNOS was first started ? Might change this ...
It's worth changing...:-)

None of the timers set in the 10+day range require millisecond accuracy.
The uptime calculation doesn't either.
As long as the new algorithm works invisibly you can refresh as often as 
practical.
And a multiplicity of clocks [ms, sec, hr, ...] might be a reasonable 
solution.
Working is the operative word.
Any timer set across the refresh boundary may be at jeopardy.
I might resist any documentation that says: "timer may not exceed the 
next refresh interval.".
But then fixing the timers for the refresh activity looks a lot like 
fixing it for the overflow.
I'm actually OK with being slightly confused...:-)

Going back to the DOS architecture, I seem to recall a 15ms timer was 
the norm.
A zero-crossing 60hz event [50hz in the EU?].
Because nos has quite a few timers, one free-running clock [msclock()] 
as the basis for timers makes sense.
Rather than a zero start time, an algorithm using "now" start time and 
"ring the alarm" at now + set-time could consume the fewest CPU cycles 
overall on CPUs with little horsepower.
Except for handling overflow, the master clock is pretty straight 
forward and used by jnos [only my read].

Todays C permits lot's of timer calls each starting from "now" as zero.  
Right?
But these don't back-fit nicely into the DOS platform?
So I don't envy your job at satisfying the broad multi-platform objective.

Perhaps the most unsettling thing about this event is related to my 
sense of "lack of data".
This thread seems to be dominated by Linux platform for jnos/tnos.
At least it seems to me that DOS users have not chimed in with "me too" 
comment [my weakness?].
It is quite a few years of operation to not notice...
In any case, only looking locally on the MI-DRG subnet of AMPRnet I see 
quite a few up-times greater than 25days.
So IF the issue is found way back at jnos2.0a and earlier then we of the 
user community have lots of decisions about upgrade to make.

As for myself, the upgrade decision is real easy since I remain fairly 
close to development.
And now that we recognize the issue, coping with older neighboring nodes 
becomes perhaps more difficult, but more certain.

>
> Anyways, it's clear what is going on here. I'll have a fix out shortly.
Happily that IS the case.
My ramblings may be much smoke without fire, and demand no response.
But timer glitch does give another layer of issue to look out for on 
AMPRnet nos nodes.

>
> Maiko Langelaar / VE4KLM
Regards
Skip