>Jonathan, I haven't been ignoring you because you disagree with me.
>I've been ignoring you because I'm SICK AND TIRED of you flaming the
>Hell out of me about things that you are clearly wrong about.

The feeling is mutual.

>Let's look at some easily verifiable facts, shall we?

Yes, lets. Charles, despite the title of your message, this idea
*NOT* about PPS.

It's precisely for when you *DONT HAVE A PPS SIGNAL*.

I dont know why you keep making this but as long as you do, your
conclusions, based on this erroneous assumption, are wrong.


>1) It is a fact that any interrupt handler which calls wakeup() *must*
>   be blocked by splclock().

So what?  Do the timestamp asap, and defer the wakeup to softint
postprocessing. Since this isnt a PPS, no problem.  Just use the same
technqiues the com driver does.  Its no worse than having to wait to
ship the data to userspace.

The point here is to get rid of the impact of the variable delay of
the softclock, by it from between reading the char and doing the
timestamp, to after doing both.

[snip]

 There simply isn't any
>   room for disagreement here.

About the facts? No.  About their impact on timekeeping perfomance for
oldfashioned clocks, and the possiblity of reducing that impact?
There most certainly is.

>  And I'll note that FreeBSD doesn't do this either.

Of course not.  Dennis Ferguson and Ken Hornstein only
just suggested it.


>Now, anyone with even a shred of clue can see that having the serial
>interrupt (and therefore the DCD timestamping) blocked by splclockc()
>would substantially increase jitter.  It is therefore very bad for PPS
>signals, which is exactly what you want to implement.  

Again, factually incorrect. these are *NOT* PPS signals.
That is NOT what wwe are trying to implement ehre.

The whole object of this paricular sidebar exercise is, for about the
seventh time, to handle clocks which DO NOT HAVE PPS signals.

Charles, if you dont grok that, after looking at the drivers, you have
no grasp at all of the basic essential principles of NTP.


>I conclude from
>this that your suggestions were poorly thought out, based on an
>obvious lack of understanding of (Net)BSD interrupt handling, and at
>least this one should not be implemented.

       a) Again, not my suggestions.  
       b) wrong about lack of understanding of BSD interrupts
       c) wrong again.

>2) You state you were taking measurements with NetBSD 1.2E and
>  1.3_ALPHA.  In fact, there is a known bug in those versions that
>   affects interrupt latency when other I/O is happening.  This bug
>   was fixed before the 1.3 release.  I believe, therefore, that your
>   alleged measurements are actually irrelevant.


The interrupt latency measurements i was taking were measured with a
NIC, not with a serial interface. They were carefully taken on a
machine doing nothing else, wiht no other I/O taking place, on an IRQ
that was not shared, with careful instrumetantion of how often
interrupts were blocked or held.  This was done carefully and
painstakingly over a period of several months.  Personally, I havent
noticed any changes to the icu code that would substantially change
those numbers.  I am slowly getting motivated to go and look.

Even if there is, it still doesnt' invalidate those number as being
true at the time they were taken.

If you want to argue that things have changed since, provide
numbers that make your case.

>Frankly, I find it both amusing and outright disgusting that you
>challenge me on such an issue, given the number of times you've said
>that you `just don't understand' interrupt priorities.

No, I said I didnt understand the NetBSD usage.  That was due to a
combination of a mistake in the manpage and of md usage of "splraise"
and "spllower" which collided with the documentation bug.  The way
NetBSD spls  really do work is exactly how I thought they should be
working all along.