Re: [Ntp] Antw: [EXT] Re: Symmetric mode

[Harlan Stenn <[e-mail]>]

On 9/25/2022 11:26 PM, Ulrich Windl wrote:
> Hi!
> 
> I'd wish those who are so heavily defending symmetric mode would have invested
> the same energy to include it in NTS.

Shenanigans.

The original NTS implementation supported all modes.

Daniel proposed a replacement to the original NTS that only worked for 
client/server, and *as I recall*, after being repeatedly pressed said 
several other modes would not be difficult to add.  Several of us pushed 
for that to happen sooner rather than later.  We were overruled.  I, for 
one, did not believe that it would be easy to do this - if it would have 
been easy, it would have already been done.

And to be very clear, I am holding WAY back on my response to you.

> Maybe now people are arguing that symmetric mode should be dropped as it won't
> be supported with NTS anyway.

If that is true, I have a much better solution.

H
--
> Regards,
> Ulrich
> 
>>>> Danny Mayer <[e-mail]> schrieb am 25.09.2022 um 00:01 in
> Nachricht <[e-mail]>:
> 
>> On 9/21/22 4:31 AM, Miroslav Lichvar wrote:
>>> On Tue, Sep 20, 2022 at 09:41:38AM ‑0400, Danny Mayer wrote:
>>>> On 9/19/22 5:01 AM, Miroslav Lichvar wrote:
>>>>> It's not very useful. I think the most interesting thing about it is
>>>>> that sources using the symmetric mode are marked differently in tools
>>>>> like ntpq, so it's more obvious to the admin that synchronization can
>>>>> work in both directions.
>>>> It's extremely useful, particularly when you end up in orphan mode or
> just
>>>> need to make sure that all systems in the local network are synchronized.
>>> You said that before. If there is doubt, you need to provide some
>>> evidence. This is not a debate on TV where repeating something over in
>>> an authoritative voice would change someone's mind.
>> This is not a TV show. Please stop.
>>>
>>> You claim that something exists, that there is something special about
>>> symmetric mode with respect to orphan mode or source selection in
>>> general. That's easy for you to prove that. You just need to point to
>>> an exact location in the source code or RFC and we can easily confirm
>>> if that is true.
>>
>> I have pointed you to papers and documents by Dave Mills. You have
>> access to the source code and you can run it in a debugger and examine
>> the logs. If you say that the source code is opaque, I won't disagree
>> with you, at times it takes me a while to understand what it's doing.
>>
>> Symmetric Mode has it's uses and while that use is most useful on a LAN
>> you can use it on the wider WAN. I know of someone using symmetric peer
>> mode in exactly this way across the internet. I cannot provide a name as
>> I am not authorized to do so, not that it is important here.
>>
>> I have provided you with examples of why it's useful. You can agree or
>> disagree with it and say why but the NTP Reference implementation code
>> has been running that mode for over 20 years.
>>
>> Someone made a claim that it uses more packets than client/server modes,
>> but that's not true either, something that can be easily verified by
>> running the code and looking at the packet traffic.
>>
>>>
>>> I claim that there is no such thing, that there is no difference
>>> between selection of sources using the client/server mode and
>>> symmetric mode.
>> Right because it's just one more component of the data being analyzed by
>> the algorithms. If another server provides better data than the
>> symmetric mode then that's what becomes the chosen server. Symmetric
>> mode doesn't replace client/server modes, it's just another mode and all
>> modes are considered in the selection algorithms, including broadcast
>> and multicast.
>>> It's much more difficult for me to prove that
>>> something doesn't exist. I can point to the source code where I'd
>>> expect it to be, like this location in the clock_select() function
>>>
>>>
>>
> https://fossies.org/linux/misc/ntp‑4.2.8p15.tar.gz/ntp‑4.2.8p15/ntpd/ntp_proto.
>> c#l_3531
>>>
>>> where I don't see anything checking the mode (MODE_SERVER vs
>>> MODE_ACTIVE/MODE_PASSIVE), but that doesn't mean this distinction
>>> couldn't be hidden somewhere else.
>>>
>>> It's up to you to prove that it exists.
>>>
>> No, I've already done that. See the running code. I have no idea what
>> you mean by exists since it's in the reference implementation code.
>>
>> Danny
>>
>> _______________________________________________
>> ntp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ntp
> 
> 
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!