On Tuesday 27 July 2004 08:24 am, Derrick Brashear wrote:
> Sebastian Biallas <sb <at> biallas.net> writes:
> > The problem I see is:
> > The dec exceptions is often fired /before/ the dec register has become
> > negative (if you enable the debug prints in readDEC you'll see). Maybe
> > this is confusing the client. We should:
> What's the granularity on the timer functions we're using? I suppose it
> can be determined.
It depends on the O.S. it's running under and how it was compiled. A few cases
don't really have good enough resolution for truly accurate timing, but it'll
be close. Windows is a millisecond I think. Most linux machines should have
either 1 nanosecond or 10 millisecond resolution.
> > b) Wait/Reset the timer if readDEC would return a positive value in
> > readDEC
> That seems sort of poor; The real CPU wouldn't wait.
Well, the real CPU wouldn't be using a timer - it'd be counting down, so it'd
always have a negative when the exception fires. :)
If the timer fires early, it'd depend on how early it fires. I don't think
that restarting the timer is a good idea - our clocks will start running at
half speed most of the time, since many unix machines barely have the
resolution to handle the original request. The better solution would probably
be something on the order of in the callback handler for the timer firing,
trigger the exception, and mark a flag. Then in the readDEC, if that flag is
true, guarantee that the returned value is negative. Maybe even if that flag
is true, set the value to -1.
> If it's really an overrun, can't we just assume it wrapped and give them
> the difference between the 2 numbers assuming that it wrapped only once?
> Or am I barking up the wrong tree? I will confess to being somewhat
> confused at what I'm looking at.
It might not be an overrun, and might be a miscalculation in the readDEC. The
interesting thing about all this is that it seems to happen whenever we've
made a system call (i.e. File I/O, network read/write). Both of which might
be blocking signals during the duration of the call. Which then seems to
trigger it. So maybe the signal was blocked long enough that some computation
goes haywire, and the value is actually too negative or something...
I'll play around with a couple of things this evening and see if I can figure
it out as well.