systemd NEWSファイルでのsystemd-timesyncdの発表は、Chronyやそのようなツールと比較してこのツールの違いを説明するのに役立ちます。（エンファシス鉱山）：
ネットワーク全体でシステムクロックを同期するための新しい「systemd-timesyncd」デーモンが追加されました。SNTPクライアントを実装します。以下のようなNTPの実装とは対照的にchronyまたはNTP参照サーバこれはクライアント側だけを実装し、そして、完全なNTPの複雑さを気にしない1つのリモートサーバーからの時間を照会し、それにローカルクロックを同期のみに着目します。ネットワーク接続されたクライアントにNTPを提供する予定がない場合、またはローカルハードウェアクロックに接続する場合を除き、この単純なNTPクライアントはほとんどのインストールに適しています。[...]
このセットアップは、サーバー群のほとんどのホストの一般的なユースケースです。通常、ローカルNTPサーバーから同期されます。ローカルNTPサーバー自体は、ハードウェアを含む複数のソースから同期されます。systemd-timesyncdは、その一般的なユースケースに使いやすいソリューションを提供しようとします。
特定の質問に対処しようとしています：
精度の点で2つの現実の違いは何ですか？
複数のソースから同期データを取得することでより高い精度を得ることができると思いますが、これは特にsystemd-timesyncdのサポートされているユースケースではありません。しかし、信頼できる内部ネットワークに接続された中央のNTPサーバーから同期データを取得するためにそれを使用している場合、複数のソースを使用することはそれほど重要ではなく、単一のソースから十分な精度が得られます。
ローカルネットワークと同じデータセンターにある信頼できるサーバーからサーバーを同期する場合、NTPとSNTPの精度の違いは事実上存在しません。NTPはRTTを考慮してタイムミアリングを行うことができますが、RTTが非常に小さい場合（高速ローカルネットワークと近くのマシンの場合）はそれほど有益ではありません。また、使用しているソースを信頼できる場合、複数のソースは必要ありません。
効率の違いは何ですか？
単一のソースから同期を取得する方が、複数のソースから同期を取得するよりもはるかに簡単です。どのソースが他のソースよりも優れているかを判断したり、複数のソースからの情報を組み合わせたりする必要がないためです。アルゴリズムははるかに単純であり、単純な場合にはCPUの負荷が少なくて済みます。
「単純ではない」時刻同期には、NTPクライアントとしてのchronyの別名であるユースケースが必要ですか？
それは上記の引用で対処されていますが、いずれにしても、これらはsystemd-timesyncdによってカバーされないChronyのユースケースです：
- NTPサーバーの実行（他のホストがこのホストを同期のソースとして使用できるようにするため）;
- 複数のソースからNTP同期情報を取得します（ホストがインターネット上の公開サーバーからその情報を取得するために重要です）。そして
- ローカルクロックから同期情報を取得します。これには通常、衛星から正確な時間情報を取得できるGPSデバイスなどの専用ハードウェアが含まれます。
これらのユースケースには、Chronyまたはntpdなどが必要です。