On 2008-03-31, David Woolley
wrote:

> Steve Kostecke wrote:
>
>> On 2008-03-31, David Woolley wrote:
>>
>>> Bill Unruh wrote:
>>>
>>>> On Sun, 30 Mar 2008, starlight@binnacle.cx wrote:
>>>
>>> You appear to be quoting an off list reply with no indication of
>>> permission, although it is just possible that the email gateway
>>> forwarded it to email subscribers without forwarding it to the
>>> usenet group proper.
>>
>> What you are suggesting is not possible.
>>
>> The Usenet news-group is just another subscriber to the questions
>> list.
>
> It's certainly very possible that the missing article was private
> email only, although possibly by mistake.

Private e-mail can not be a "missing article".

>The mailing list doesn't seem to be a simple subscriber,

There is only _one_ type of list subscriber: those who receive mail from
the list.

>as an example quoted before showed no sign of attachments in the usenet
>version, but the mail archive version that I was pointed to mentioned
>that attachments (a PGP signature) had been suppressed.

Our mailing lists strip out all manner of MIME cruft. The gateway is a
bit more stringent to protect those of us who use real (i.e. console)
news readers.

> I assume you mean the usenet gateway is a subscriber, as usenet
> groups can't subscribe to mailing lists on their own. In that case,
> it is at least theoretically possible that the gateway suppresses the
> message on the usenet side, but if it is an ordinary subscriber on the
> mailing list side, the message will still go to other mailing list
> subscribers. One obvious case in which this would happen is if there
> was a duplicate message ID.

Both the mailing-list and the gateway use the original message ID to
prevent duplicate posts/articles.

Every post/article is propagated exactly _once_.

There is no supression. There is no Cabal.

--
Steve Kostecke
NTP Public Services Project - http://support.ntp.org/

On Mar 30, 8:05*pm, starli...@binnacle.cx wrote:

> Might try them later, but I can't belive a high-quality
> SMC switch is causing multi-millisecond delays. *Just not

Do you have access to a different (Cisco, Extreme, Foundry, or HP)
switch for testing? If not, try a crossover cable between the NTP
server and one of the systems. If the problem disappears, you'll know
the switch was the culprit.

We've seen lots of strange issues with less expensive switches
(NetGear, similar to SMC) that just don't happen with the more
expensive brands. You often get what you pay for.

David Woolley schrieb:
> Heiko Gerstung wrote:
>
>> time has passed without the signal coming back. This results in the
>> time server replying with stratum 12 (for example) after a while and
>> ensures that everybody has the same time, although it might be wrong.
>> If a user does not want that, they can simply set the local clock
>> stratum to 15 and the server will not be accepted anymore.
>>
>> Can you please let me know why you consider this a "bad implementation"?
>
> Because the protocol fails to signal the loss of the time source
> properly when one has a local clock configured. As such, I believe that
> enabling a local clock should always be an opt in choice. Basically,
> when it falls back to the local clock, root dispersion goes to zero,
> when the true situation is that root dispersion is growing without bound.

The signal is the higher stratum level, at least for a lot of SNTP
implementations. Almost noone is looking at the root dispersion value when it
comes to SNTP ...

In our web interface you can disable the use of the local clock reference
completely. I always recommend to keep it active but set its stratum to 15,
which should result in being rejected by any standards compliant client.

Running without the local clock ref means the server signals itself as being
synchronized by a stratum 0 source (e.g. GPS) and only the root dispersion value
is increasing. As I said, most embedded/SNTP-only software checks for the SYNC
status and (sometimes) stratum level.

> Things can go seriously wrong if there is more than one local clock
> source on a network, as it becomes possible for them to outvote the real
> time.

Yes, but I would not go that far to say that offering the end user the choice to
enable the local clock driver in his NTP appliance is a "bad implementation". I
however can fully agree that there are a number of things that could go wrong
when you use it (something that applies to a number of configuration options
like tinker or restrict ...).

Cheers,
Heiko