>It's been pointed out to me that this discussion was taking place, and
>I suppose I should say something about it, given that people are
>talking about messing with code that I'm responsible for, and now that
>I've effectively been slagged regarding `low level performance'.

Where that come from?  Nobody is slagging Charles or anyone else.

I did say that FreeBSD pays more attention to low-level performance
than NetBSD does.  I happen to think that's true. It shows up in all
sorts of ways, like looking at the assembler output by gcc and
tweaking their source code to match; paying more attention to tuning
of critical code fragments like kernel bcopy() and copyin(), interrupt
dispatch code, and similar hackery.  NetBSD doesn't do that.  That's
much easier to do if you only have one CPU architecture to tune for.

obody in this discussion is slagging you or anyone else working on
NetBSD.  No slagging was meant or implied or even (within reason)
inferrable. Anyone who thinks otherwise is mistaken.

>It's true that FreeBSD has somewhat lower quoted `interrupt latency'
>for serial interrupts.  

But my earlier statements were not about `fast' vs `slow'
interrupts. (though `fast' definitely could make the netbsd com driver
faster yet.)  Even comparing `heavyweight' interrupt against
`heavyweight' interrupt, FreeBSD still does better.  That's orthogonal
to serial handling and to lightwegith interrupts . I do understand how
such a misunderstanding might arise in this context, though.

Boggle. Charles claims an innocent statement of a fact (which flamed
nobody, Charles or otherwise) is a "slagging".  Yet at the same time,
Charles confirms the very same fact.  Is it me, or is that Kafka-eque?


>Worse than that, however, is that reducing jitter is actually
>fundamentally incompatible with one of the things you wanted to do --
>namely, call the line discipline input routine directly from the
>interrupt handler.

First, It's Ken Hornstein's idea, and Dennis Ferguson's, not mine.

Second, Dennis Ferguson *wrote* the ntp v2 code base. He also rewrote
NetBSD's i386 clock code.  Saying he's making a decision
``fundamentally incompatible'' with the goals of good NTP timekeeping
beggars belief.

I'd like to stick to the technical issues, but (as Charles does to
other people who dare point out his egregious mistakes) he discards
all email from me unread.

I propose that _in general_, we ignore Charles' obections, despite
being a Core Group member, since 

a) he clearly doesnt know what he's talking about here
b) he hasn't bothered following the thread (where Dennis Ferguson
    explained how  CHU timecodes work and how they should be handled,
     in a way that shows this "fundamentally incompatible" claim
    is incorrect,

c)  he hasn't even bothered to read the relevant line disciplines.
    ttyclk, at least, is comprehensible as it stands, tho' with
    CHU i didn't really get it without knowing how the CHU signal works.


>If you're going to do this with a serial line, I suggest that you just
>write a completely separate special-case driver that does what you
>need.

*Sigh*. First, I've said repeatedly that I'd prefer to support PPS on
a parallel port.  that's emphasised in *several* messages.  Both here,
in private email to Ken and Dennis and Bill Studenmund, and to the
developers list.  Charles, do you have a reading disability too?

I've also said that I'm not sure there are enough users (or potential
users) of the ttyclk discpline to warrant pulling this into the NetBSD
tree.  It seems, maybe there are, especially in the UK and Europe. But
I've alrady got three emails from people who've got machines they'd
*like* to run NetBSD on, but cant, due to lack of good NTP support.


Second: from a maintenance viewpoint, writing special-case drivers for
every serial line in the NetBSD tree, is *not* a viable option.
Italso should not be necessary.  Other serial drivers (zs) can
accomodate this just fine.  Other freely-distributable Unixes have
drivers for 8250-family UARTs can accomodate this just fine.  
If the NetBSD com driver can't, thats clearly a sign of poor, or at
least over-specialized, design in the com driver.

Third, *every* other freely-distributable Unix offers reasonable NTP
service using the standard serial driver.  But Charles Hannum says the
NetBSD/i386 serial driver just can't do it.  

Charles, are you *trying* to send a message telling people to use
FreeBSD or Linux instead of NetBSD/i386?