Re: [chrony-users] Getting time synchronization offset from chronyd

[Guy Morand <g.morand@xxxxxxxx>]

Hallo everyone!

Thanks for the clarification and suggestions!

> If network traffic is important, have you considered dropping chrony and
> piggypacking whatever you need for time on other traffic?

In a previous project, we used ntpdate. It seems outdated and less and
less people are using it. I wanted to learn something new and give
chrony a go, it looks like a nice project and you are showing me that
it also has a nice community, that is a good reason for me to stick
with it. I'm conscient that for my use case, using chrony is probably
killing a mouse with a bazooka. I'm trying to do things "right" but I
don't need to be more Christian than the pope.

> The downside is that you have to become a time/NTP expert.  You are half way
> there already.

Hey, it's not because I dig a little into one implementation that I
know the protocol in detail! But I appreciate the compliment though
:D!

> Do you actually need time on the IoT device?  Can you use the time on the
> server?  That is, rather than sending a message that says "X happened at T0",
> send a message that says "X just happened" and let the server fill in the
> time.  Or "X happened Y seconds ago" if you want to batch several events.

This makes absolute sense but it could happen that the connection gets
lost because our device is moving (wheelchair), in that case we store
events (with a valid timestamp) on the device until the connection is
established again. BTW I know I should also use the "offline"
parameter but I'm not yet so far ;-)

> Call it 20 bytes for a convenient round number.  That's 25% of your 80 byte
> number so it would save 75% of the NTP part of your network bill.

I guess you are right but if we really want to spare bytes on the
network, we should first optimize our "events" channel that is 99.9%
of the communication. I need something quickly that simply works, you
are smarter than me and if I do it myself, I will for sure not do it
right the first time :D!

Keep the hard work and long life to chrony!

Guy


On Thu, Jul 16, 2020 at 10:06 PM Hal Murray <hmurray@xxxxxxxxxxxxxxx> wrote:
>
>
> unruh@xxxxxxxxxxxxxx said:
> > I believe ntp protocol uses TCP.
>
> UDP
>
> > That of course does not change the size of the packets sent/received. And
> > usually traffic is charged per byte, not per connection.
>
> > Fortunately ntp packets are not that big (something like 80 bytes).
>
> 48 bytes for basic NTP.  8 bytes for a UDP header.  20 bytes for an IPv4
> header, 40 bytes for IPv6.
>
> 16 bytes for an Ethernet header plus 4 for the CRC.  I don't know what, if
> any, GSM uses for a header or how they count bytes for billing.
>
> If you can piggyback on another packet pair that you are already sending, all
> you need for time is 2 time stamps (8 bytes each) and an ID (4 or 8 bytes).
> [You could save a few more by changing the second time stamp to a delta from
> the first.]
>
> Call it 20 bytes for a convenient round number.  That's 25% of your 80 byte
> number so it would save 75% of the NTP part of your network bill.
>
> I don't know if that would be worth the effort but it seemed worth tossing the
> idea out.
>
> But it's more complicated than that.  You only save that if you are already
> sending traffic to a server that will give you time.  You probably don't send
> anything else to NTP servers.  So in order to save anything, you have to stop
> using NTP and get the time from the server(s) you are already talking to.  If
> you trust them enough to process your data, you can probably trust their time.
>
> Alternatively, drop keeping the IoT device synchronized to UCT and use
> time-since-boot.  That requires changing the protocol which may not be
> possible.  But if the protocol is something like "X happend at T0" you can
> change that to "X happened now" or X happened T seconds ago".  That saves the
> total NTP network budget.
>
>
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>
> --
> To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
> with "unsubscribe" in the subject.
> For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
> with "help" in the subject.
> Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.
>

-- 
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.