user47400: The point here is to syncronise a DS3231 module (on an Arduino) via serial port with NTP time by computer.
The problem here is that I'd like to know how much time is taken by the serial and I2C transmission, because if the PC sends the time at a time t1 and transmit it to the Arduino, the Arduino decodes it and sends it to the DS3231, the time t1 is received at a time t2 greater than t1.
PC (t1) => Serial(t1+x) => Arduino(t1+x+y) => I2C(t1+x+y+z) => DS3231(t2=t1+x+y+z)


t1 -> NTP time recorded by PC
x  -> Time taken by serial transmission
y  -> Time taken by arduino buffering/processing
z  -> Time taken by I2C transmission at 100kHz
t2 -> Time when message is received by DS3231

Is it negligible for a precision at millisecond?
I found a table on Wikipedia that displays time per bit per baudrate. I am planning to use a baudrate of 57600.
I tested offset using a simple echo program available here at 300 baud:
String buff="";

void setup() {
  // put your setup code here, to run once:
Serial.begin(300);
}

void loop() {
  if(Serial.available())
  {
    while(Serial.available())
    {
      buff += char(Serial.read());
    }
    Serial.print(buff);
    buff = "";
  }
}


user13327: Transmission time will certainly not be negligible. To estimate it, you could use the roundtrip delay calculation, which is (roughly) how the NTP protocol is implemented in the first place.

at PC time T1, PC sends current time T1 to Arduino via UART
Arduino sets the time T1 in DS3231 via I2C
Arduino reads the time T2 from DS3231 via I2C
Arduino sends the time T2 to PC via UART. This happens at time T3 from PC's point of view.

Now the PC can estimate the half-roundtrip delay R as (T3-T2)/2. See the following chart which denotes current time form POW of PC and RTC
        |--UART--|--I2C--|--------|--I2C--|--UART--|
PC      T1              T1+R     T2+R           T3=T2+2R
DS3231  -                T1       T2              T2+R

Next, at time T4, the PC sends the value (T4+R) via UART. This will result in  DS3231 to be set to (T4+R), which happens exactly R time after T4, so that both clocks are now set to the same value.
Estimation of R can be repeated several times. In this case you can calculate the standard deviation which tells you how much "jitter" your clocks have.

user7508: I second the general idea of Dmitry Grigoryev’s answer: your best option
is to measure a round-trip time and use half of that as an estimate of
the one-way time. Otherwise you will have too many unknowns. For
example, you don't know how long your OS takes to process the outgoing
message and send it through USB to the USB/serial bridge inside the
Arduino. As an optimization, I would send the time information and the
synchronization strobe as two separate messages, with the latter being a
single byte. This way the latency of the synchronization strobe (the
only latency that matters) is minimized.
Latency of serial communication
I did some research to try to nail this one down. At 57600 bits/s,
the theoretical time per bit is about 17.4 µs, as stated in the
Wikipedia article you linked to. In practice, the actual time can be
rounded more or less depending on the UART capabilities and the clock
speed. You did not specify what Arduino you are using. In the following,
I will assume an AVR-based Arduino clocked at 16 MHz, which is
presumably the most common.
The UART in the AVR constrains the bit time to be a multiple of
8 CPU cycles, i.e. 0.5 µs when running at 16 MHz. The
closest you can get to the ideal timing is therefore 17.5 µs.
However, the Arduino core library has a hard coded compatibility
exception which, in this very specific case, sets the bit
duration to 17 µs instead. Since you are presumably configuring the
port at /8N1, which is the default, the time per byte is then
170 µs (1 start bit, 8 data bits and 1 stop bit).
Actually, when transmitting a single byte, the transmission time is
slightly less than that. The UART can report the byte as received as
soon as it is done taking the required three samples of the stop bit,
which happens slightly after the middle of that stop bit. The
theoretical time it takes to transmit a single byte is then about
9.56 times the single-bit duration, or about 162.56 µs at
57600/8N1.
I did a simple loopback test with the TX and the RX of my Uno shorted
together. I used a timer to time the execution of the following code:
Serial.write('.');
while (!Serial.available()) continue;

The result was 182.38 µs, or about 10.73 bit durations. A
fraction of this time is taken by the execution of Serial.write() and
Serial.available(). In order to get closer to a bare hardware latency,
I also timed a low-level version of the two lines above:
UDR0 = '.';
while (!bit_is_set(UCSR0A, RXC0)) continue;

This has to be run with interrupts disabled. The execution time was now
between 164.19 and 164.81 µs, i.e. 9.66 to 9.69 bits
durations.
Alternative approach
As a final note, I would recommend you consider buying a GPS module with
a 1PPS output. This 1PPS is a 1 Hz logic signal with the rising
edges tightly aligned to the start of the UTC seconds. You typically get
an accuracy in the tens of nanoseconds. Since this is just a logic
signal that you can easily compare with the 1 Hz output of your RTC
module, you get rid of all the latency issues that come with computers
(your NTP client), or data links (USB, serial, I2C).

47400: <p>The point here is to syncronise a DS3231 module (on an Arduino) via serial port with NTP time by computer.</p>

<p>The problem here is that I'd like to know how much time is taken by the serial and I<sup>2</sup>C transmission, because if the PC sends the time at a time <code>t1</code> and transmit it to the Arduino, the Arduino decodes it and sends it to the DS3231, the time <code>t1</code> is received at a time <code>t2</code> greater than <code>t1</code>.</p>

<pre><code>PC (t1) =&gt; Serial(t1+x) =&gt; Arduino(t1+x+y) =&gt; I2C(t1+x+y+z) =&gt; DS3231(t2=t1+x+y+z)
</code></pre>

<ul>
<li><code>t1</code> -> NTP time recorded by PC</li>
<li><code>x</code>  -> Time taken by serial transmission</li>
<li><code>y</code>  -> Time taken by arduino buffering/processing</li>
<li><code>z</code>  -> Time taken by I2C transmission at 100kHz</li>
<li><code>t2</code> -> Time when message is received by DS3231</li>
</ul>

<p>Is it negligible for a precision at millisecond?</p>

<p>I found a table on Wikipedia that displays <a href="https://en.wikipedia.org/wiki/Serial_port#Settings" rel="nofollow noreferrer">time per bit per baudrate</a>. I am planning to use a baudrate of 57600.</p>

<p>I tested offset using a simple echo program available <a href="https://pastebin.com/ZEhpBkLW" rel="nofollow noreferrer">here</a> at 300 baud:</p>

<pre><code>String buff="";

void setup() {
  // put your setup code here, to run once:
Serial.begin(300);
}

void loop() {
  if(Serial.available())
  {
    while(Serial.available())
    {
      buff += char(Serial.read());
    }
    Serial.print(buff);
    buff = "";
  }
}
</code></pre>
 13327: <p>Transmission time will certainly not be negligible. To estimate it, you could use the roundtrip delay calculation, which is (roughly) how the NTP protocol is <a href="https://en.wikipedia.org/wiki/Network_Time_Protocol#Clock_synchronization_algorithm" rel="nofollow noreferrer">implemented</a> in the first place.</p>

<ul>
<li>at PC time T1, PC sends current time T1 to Arduino via UART</li>
<li>Arduino sets the time T1 in DS3231 via I2C</li>
<li>Arduino reads the time T2 from DS3231 via I2C</li>
<li>Arduino sends the time T2 to PC via UART. This happens at time T3 from PC's point of view.</li>
</ul>

<p>Now the PC can estimate the half-roundtrip delay R as (T3-T2)/2. See the following chart which denotes current time form POW of PC and RTC</p>

<pre><code>        |--UART--|--I2C--|--------|--I2C--|--UART--|
PC      T1              T1+R     T2+R           T3=T2+2R
DS3231  -                T1       T2              T2+R
</code></pre>

<p>Next, at time T4, the PC sends the value (T4+R) via UART. This will result in  DS3231 to be set to (T4+R), which happens exactly R time after T4, so that both clocks are now set to the same value.</p>

<p>Estimation of R can be repeated several times. In this case you can calculate the standard deviation which tells you how much "jitter" your clocks have.</p>
 7508: <p>I second the general idea of Dmitry Grigoryev’s answer: your best option
is to measure a round-trip time and use half of that as an estimate of
the one-way time. Otherwise you will have too many unknowns. For
example, you don't know how long your OS takes to process the outgoing
message and send it through USB to the USB/serial bridge inside the
Arduino. As an optimization, I would send the time information and the
synchronization strobe as two separate messages, with the latter being a
single byte. This way the latency of the synchronization strobe (the
only latency that matters) is minimized.</p>

<h2>Latency of serial communication</h2>

<p>I did some research to try to nail this one down. At 57600&nbsp;bits/s,
the theoretical time per bit is about 17.4&nbsp;µs, as stated in the
Wikipedia article you linked to. In practice, the actual time can be
rounded more or less depending on the UART capabilities and the clock
speed. You did not specify what Arduino you are using. In the following,
I will assume an AVR-based Arduino clocked at 16&nbsp;MHz, which is
presumably the most common.</p>

<p>The UART in the AVR constrains the bit time to be a multiple of
8&nbsp;CPU cycles, i.e. 0.5&nbsp;µs when running at 16&nbsp;MHz. The
closest you can get to the ideal timing is therefore 17.5&nbsp;µs.
However, the Arduino core library has a <a href="https://github.com/arduino/Arduino/blob/1.8.5/hardware/arduino/avr/cores/arduino/HardwareSerial.cpp#L109-L118" rel="nofollow noreferrer">hard coded compatibility
exception</a> which, in this very specific case, sets the bit
duration to 17&nbsp;µs instead. Since you are presumably configuring the
port at /8N1, which is the default, the time per byte is then
170&nbsp;µs (1&nbsp;start bit, 8&nbsp;data bits and 1&nbsp;stop bit).</p>

<p>Actually, when transmitting a single byte, the transmission time is
slightly less than that. The UART can report the byte as received as
soon as it is done taking the required three samples of the stop bit,
which happens slightly after the <em>middle</em> of that stop bit. The
theoretical time it takes to transmit a single byte is then about
9.56&nbsp;times the single-bit duration, or about 162.56&nbsp;µs at
57600/8N1.</p>

<p>I did a simple loopback test with the TX and the RX of my Uno shorted
together. I used a timer to time the execution of the following code:</p>



<pre class="lang-c++ prettyprint-override"><code>Serial.write('.');
while (!Serial.available()) continue;
</code></pre>

<p>The result was 182.38&nbsp;µs, or about 10.73&nbsp;bit durations. A
fraction of this time is taken by the execution of <code>Serial.write()</code> and
<code>Serial.available()</code>. In order to get closer to a bare hardware latency,
I also timed a low-level version of the two lines above:</p>

<pre class="lang-c++ prettyprint-override"><code>UDR0 = '.';
while (!bit_is_set(UCSR0A, RXC0)) continue;
</code></pre>

<p>This has to be run with interrupts disabled. The execution time was now
between 164.19 and 164.81&nbsp;µs, i.e. 9.66 to 9.69&nbsp;bits
durations.</p>

<h2>Alternative approach</h2>

<p>As a final note, I would recommend you consider buying a GPS module with
a 1PPS output. This 1PPS is a 1&nbsp;Hz logic signal with the rising
edges tightly aligned to the start of the UTC seconds. You typically get
an accuracy in the tens of <em>nanoseconds</em>. Since this is just a logic
signal that you can easily compare with the 1&nbsp;Hz output of your RTC
module, you get rid of all the latency issues that come with computers
(your NTP client), or data links (USB, serial, I2C).</p>
