• OS and version used: Fedora 35
• Library version used: 0.2

Description of the issue:

Library returns invalid offset/roundtrip values

Code sample exhibiting the issue:

N/A

Console log of the issue:

N/A

Thanks for a really helpful library! Though I ran into an issue trying to parse NtpResult.seconds_fraction (resp. NtpResult.sec_fraction()):

1. This states that the value is in microseconds: https://github.com/vpetrigo/sntpc/blob/master/src/lib.rs#L280
2. This states nanoseconds: https://github.com/vpetrigo/sntpc/blob/master/src/lib.rs#L292
3. In the example it's in units of 1/u32::MAX of a second (if my reading is right) - i.e. about a quarter of a nanosecond: https://github.com/vpetrigo/sntpc/blob/master/examples/simple_request.rs#L87

I gather that (1) is definitely not the case (since the values are too large), and I suspect that (3) is the real answer, but it would be good to have this clear in the docs. Or perhaps convert the result to micro or nanoseconds, since 1/u32::MAX is a bit awkward to deal with.

Also - and this is minor - but I think in the example using time.sec_fraction() as u64 * 1_000_000 / u32::MAX as u64 to get the decimal points will show the wrong value if the result has fewer than 6 digits. E.g. it would show 1.23 instead of 1.000023. Might be better to just convert to float, e.g.

println!("Got time: {}", time.sec() as f64 + time.sec_fraction() as f64 / u32::MAX as f64);

• Allow std/no_std builds

Consider adding a method with the following signature:

pub fn request(ntp_server: &net::SocketAddr, port: u32) -> io::Result<u32>

That allows an user to manually supply the addresses of interest as sometimes DNS resolution may supply "dead"/"irresponsive" server's IP address in a row. So it might be a good idea to traverse other addresses and try to use them instead.

In order to improve precision of synchronization timestamp add calculation of a NTP request "fly" time

See build output below:

warning: use of deprecated associated function `std::error::Error::description`: use the Display impl or to_string()
  --> src\bin\timesync.rs:44:21
   |
44 |                 err.description()
   |                     ^^^^^^^^^^^
   |
   = note: `#[warn(deprecated)]` on by default

warning: 1 warning emitted

Hi.

I have been using SNTPC in a small library I'm developing and noticed the following logs related to sntpc-0.1.1:

[C:\Users\duall\.cargo\registry\src\github.com-1ecc6299db9ec823\sntpc-0.1.1\src\lib.rs:179] pool = "pool.ntp.org"
[C:\Users\duall\.cargo\registry\src\github.com-1ecc6299db9ec823\sntpc-0.1.1\src\lib.rs:191] &addr = V4(
    212.69.166.153:123,
)
[C:\Users\duall\.cargo\registry\src\github.com-1ecc6299db9ec823\sntpc-0.1.1\src\lib.rs:216] response.0 = 48

My library was compiled using RUSTFLAGS="-C link-arg=-s" cargo build --release, but those logs still showing in the terminal.

So, is there any configuration to remove/disable those logs?

Thank you!

I ran the example you gave:

use sntpc;

let result = sntpc::request("pool.ntp.org", 123);
if let Ok(sntpc::NtpResult {
    sec, nsec, roundtrip, offset
}) = result {
    println!("NTP server time: {}.{}", sec, nsec);
    println!("Roundtrip time: {}, offset: {}", roundtrip, offset);
}

and in the outputs , |offset|(absolute value of offset) always equal to roundtrip/2.
In my impression, offset generally refers to the difference in time between an external timing reference and time on a local machine. Is this what your offset mean, or does it have another meaning?
Thanks!

• OS and version used: Windows 10 1809
• Library version used: 0.1.1

Description of the issue:

In the debug output it might be noticed that the origin timestamp reported by a NTP server is incorrect (see logs below)

Console log of the issue:

[src\lib.rs:179] pool = "pool.ntp.org"
[src\lib.rs:191] &addr = V4(
    80.240.216.155:123
)
[src\lib.rs:216] response.0 = 48
====================================================
| Mode:		4
| Version:	4
| Leap:		0
| Poll:		3
| Precision:		-24
| Root delay:		297
| Root dispersion:	1226
| Reference ID:		
| Reference timestamp:	16149940269256115971
| Origin timestamp:		9487534654782240553 // <--- !!!
| Receive timestamp:	16149941105786494829
| Transmit timestamp:	16149941105786612562
====================================================
Got time: 1551212382