bsdphk / ntimed Goto Github PK

View Code? Open in Web Editor NEW

387.0 387.0 28.0 532 KB

Network time synchronization software, NTPD replacement.

C 96.73% Python 3.27%

ntimed's People

Contributors

Stargazers

Watchers

ntimed's Issues

Peers returning IPV6 addresses fail

Failure: Tx peer 2.au.pool.ntp.org 2403:4200:403:2::ff:1 got -1

Project Status: future plans & applicability to data-center use today

Hi,

I really apprechiated this project as it was announced at FOSDEM some years back and followed up on it semi-regularly. Pretty much all FOSS NTP/PTP projects suck by themselves and this seemed to provide a solid alternative: modular, written by someone that is familiar with precise time keeping and an established kernel developer. What struck me was the design included different parts just like some commercial PTP products would: grandmaster, time clients, distributors etc. - loved it as a fellow time nut.

But i see the project has been idle for a while with the last commits some 9 years ago. Some parts that were planned seemed to have never been implemented. While recently searching for the optimal software to run as a data-center stratum 1-2 server I thought about ntimed, but am not so sure about it's usability as is.

Are you considering it a "finished product" and as such isn't being worked on anymore? Is there no more funding or private interest? The Open Compute Project has recently taken up a sub programme to develop data-center time keeping tools, from time-cards that go into OCP servers to grandmaster clocks with GNSS and rubidium clocks as holdover for Sat. outages or jamming as well as complicated distribution proposals for sub-microsecond timing like white-rabbit. There even seem to be already commercially available implementations apart from what cloud providers have built and use. But coincidentally that programme seemed to mainly attract physicists to off-load their individual obsessions and part-time projects. while some have really good universal applicability, some are rather obscure and will probably never find use, even in telco scenarios outside physics labs. The other group of participants seems to be vendors already invested in the market: producing chips containing reference time sources like rubidium clocks for aerospace, satellite or military use in the past - now as OCP contributors or new optical clocks (this was really interesting and new to me [1]).

To get to the point (finally, I know, I digress): I was thinking of using their open-time server or open time card at some point. ntimed still seems like a valid choice for multiple applications around a data-center. Can you provide any insight into the project status or what I should consider as an alternative if you feel ntimed isn't the way to go?

Thanks in advance, and I'm sorry if an issue like this had been opened already, I searched in the github issues of this project but couldn't find one that fit.

all the best,
Aaron / azet

[1] https://www.youtube.com/watch?v=pFEFyJGqHlc&list=PLAG-eekRQBSgFYdbkVVmSbOxCX9acFh3g&index=5

What is the supported precision?

Does this sync to millisecond, microsecond, or better? (Linux kernel 4.x)
Are there platform differences with the ports?
Are what kind of precision is can be expected in real-life?

Build problems with default flags on NetBSD

When building on NetBSD-7.99.3/amd64 (gcc 4.8.4) with BSD make, I need to add
MAN=
to the Makefile generated by configure (patch available on request).

Then, the build fails because of the default c compiler flags, with

--- main_sim_client.o ---
main_sim_client.c: In function 'simfile_readline':
main_sim_client.c:138:17: error: conversion to 'unsigned int' from '__uint64_t' may alter its value [-Werror=conversion]
     sf->t0 = u1 - t0.sec;
                 ^
cc1: all warnings being treated as errors
*** [main_sim_client.o] Error code 1

make: stopped in /scratch/wip/ntimed-git/work/Ntimed
--- ntp_packet.o ---
In file included from ntp_packet.c:64:0:
ntimed_endian.h: In function 'Be16dec':
ntimed_endian.h:42:22: error: conversion to '__uint16_t' from 'int' may alter its value [-Werror=conversion]
  return ((p[0] << 8) | p[1]);
                      ^
ntimed_endian.h: In function 'Be32dec':
ntimed_endian.h:50:41: error: conversion to 'unsigned int' from 'int' may change the sign of the result [-Werror=sign-conversion]
  return (((unsigned)p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3]);
                                         ^
ntimed_endian.h:50:56: error: conversion to 'unsigned int' from 'int' may change the sign of the result [-Werror=sign-conversion]
  return (((unsigned)p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3]);
                                                        ^
ntimed_endian.h: In function 'Be16enc':
ntimed_endian.h:58:18: error: conversion to '__uint8_t' from 'int' may alter its value [-Werror=conversion]
  p[0] = (u >> 8) & 0xff;
                  ^
ntimed_endian.h:59:11: error: conversion to '__uint8_t' from 'int' may alter its value [-Werror=conversion]
  p[1] = u & 0xff;
           ^
ntimed_endian.h: In function 'Be32enc':
ntimed_endian.h:67:19: error: conversion to '__uint8_t' from '__uint32_t' may alter its value [-Werror=conversion]
  p[0] = (u >> 24) & 0xff;
                   ^
ntp_packet.c: In function 'ts_2ntp32':
ntp_packet.c:139:17: error: conversion to '__uint16_t' from '__uint64_t' may alter its value [-Werror=conversion]
  Be16enc(dst, ts->sec);
                 ^
ntp_packet.c:140:28: error: conversion to '__uint16_t' from '__uint64_t' may alter its value [-Werror=conversion]
  Be16enc(dst + 2, ts->frac >> 48ULL);
                            ^
ntp_packet.c: In function 'ts_2ntp64':
ntp_packet.c:148:23: error: conversion to '__uint32_t' from 'long unsigned int' may alter its value [-Werror=conversion]
  Be32enc(dst, ts->sec + NTP_UNIX);
                       ^
ntp_packet.c:149:28: error: conversion to '__uint32_t' from '__uint64_t' may alter its value [-Werror=conversion]
  Be32enc(dst + 4, ts->frac >> 32ULL);
                            ^
ntp_packet.c: In function 'NTP_Packet_Pack':
ntp_packet.c:163:34: error: conversion to '__uint8_t' from 'int' may alter its value [-Werror=conversion]
  pbuf[0] = (uint8_t)np->ntp_leap << 6;
                                  ^
ntp_packet.c:164:10: error: conversion to '__uint8_t' from 'int' may alter its value [-Werror=conversion]
  pbuf[0] |= np->ntp_version << 3;
          ^
cc1: all warnings being treated as errors
*** [ntp_packet.o] Error code 1

make: stopped in /scratch/wip/ntimed-git/work/Ntimed
--- combine_delta.o ---
combine_delta.c: In function 'cd_find_peak':
combine_delta.c:163:21: error: conversion to 'size_t' from 'long int' may change the sign of the result [-Werror=sign-conversion]
  qsort(st, cd->nsrc * 3L, sizeof st[0], stat_cmp);
                     ^
cc1: all warnings being treated as errors
*** [combine_delta.o] Error code 1

make: stopped in /scratch/wip/ntimed-git/work/Ntimed
--- ntp_peer.o ---
ntp_peer.c:136:17: error: conversion to 'int' from 'ssize_t' may alter its value [-Werror=conversion]
   i = UdpTimedRx(ocx, usc, np->sa->sa_family, &rss, &rssl, &t2,
                 ^
cc1: all warnings being treated as errors
*** [ntp_peer.o] Error code 1

plotgen.py doesn't run

NetBSD build issue

The build with BSD make on NetBSD-7.99.3/amd64 fails with

make: make: don't know how to make ntimed-client.1. Stop

Using GNU make it fails with:

In file included from ntp_packet.c:64:0:
ntimed_endian.h:54:1: error: redefinition of 'be16enc'
 be16enc(void *pp, uint16_t u)
 ^
In file included from /usr/include/amd64/endian.h:3:0,
                 from /usr/include/sys/types.h:98,
                 from /usr/include/stdlib.h:41,
                 from ntp_packet.c:59:
/usr/include/sys/endian.h:203:1: note: previous definition of 'be16enc' was here
 __GEN_ENDIAN_ENC(16, be)
 ^
In file included from ntp_packet.c:64:0:
ntimed_endian.h:63:1: error: redefinition of 'be32enc'
 be32enc(void *pp, uint32_t u)
 ^
In file included from /usr/include/amd64/endian.h:3:0,
                 from /usr/include/sys/types.h:98,
                 from /usr/include/stdlib.h:41,
                 from ntp_packet.c:59:
/usr/include/sys/endian.h:204:1: note: previous definition of 'be32enc' was here
 __GEN_ENDIAN_ENC(32, be)
 ^

error when not running as root

./ntimed-client -t /tmp/somefile pool.ntp.org

ntimed-client: time_unix.c:94: kt_setfreq: Assertion `i >= 0' failed.
Aborted

Does not compile on Mac OS X 10.10.1

Another, perhaps trivial, compile/make error:

$ make
cc -Wall -Werror   -c -o time_stuff.o time_stuff.c
time_stuff.c:67:19: error: conflicting types for 'TS_Nanosec'
struct timestamp *TS_Nanosec(struct timestamp *storage, intmax_t sec, intmax_t nsec)
                  ^
./ntimed.h:124:19: note: previous declaration is here
struct timestamp *TS_Nanosec(struct timestamp *storage,
                  ^
time_stuff.c:153:41: error: format specifies type 'intmax_t' (aka 'long') but the argument has type
      'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]
        assert(snprintf(buf, len, "%jd.%09jd", x, y) < len);
                                   ~~~         ^
                                   %llu
/usr/include/secure/_stdio.h:57:62: note: expanded from macro 'snprintf'
  __builtin___snprintf_chk (str, len, 0, __darwin_obsz(str), __VA_ARGS__)
                                                             ^
/usr/include/assert.h:93:25: note: expanded from macro 'assert'
    (__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __FILE__, __LINE__, #e) : (void)0)
                        ^
time_stuff.c:153:44: error: format specifies type 'intmax_t' (aka 'long') but the argument has type
      'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]
        assert(snprintf(buf, len, "%jd.%09jd", x, y) < len);
                                       ~~~~~      ^
                                       %09llu
/usr/include/secure/_stdio.h:57:62: note: expanded from macro 'snprintf'
  __builtin___snprintf_chk (str, len, 0, __darwin_obsz(str), __VA_ARGS__)
                                                             ^
/usr/include/assert.h:93:25: note: expanded from macro 'assert'
    (__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __FILE__, __LINE__, #e) : (void)0)
                        ^
3 errors generated.
make: *** [time_stuff.o] Error 1

Default compiler used:

$ cc -v
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

Return friendly (instead of assert failure) error for non-root invocation

% ntimed-client 0.au.pool.ntp.org
Assertion failed: (i >= 0), function kt_setfreq, file time_unix.c, line 94.

Configuration file suggestion

I know this project is still in preview mode and it appears the client is configured by command line switches and arguments. When the time comes to design the configuration files, I would like to make the following suggestion:

Allow the configuration to be handled via a single configuration file or folder structure.

My reasons are as follows: the single file will be for deployments where 4096 bytes of storage matters (like a router or some small capacity device) and the folder structure for servers/desktops/etc.

The folder structure would look something like::
/etc/ntimed/
|-servers
|-parameters
|-etc

The servers file should contain::
0.pool.ntp.org
1.pool.ntp.org
...

The parameters file should contain::
something=value
foo=bar
...

The reasoning behind the folder structure is for ease of viewing for inexperienced administrators and less typing/searching for variables/servers. (side note: the filenames should be hard coded as a *.conf would allow an attacker to skew your time.)

I know the way of the future is configuration management systems (like puppet) and skilled admins who can manipulate a search configuration files using "cat conf | grep server", but home users might find it easier to install and use Ntimed rather than ntpd if they edited a 4 line servers file compared to being overwhelmed by ntpd.conf.

Thanks for doing this!

Just wanted to say that.

Delaware is just aweful, the only alternative being the almost-nowhere deployed OpenNTPd.

Sincerely,
Aaron

assertation `i >= 0` failed when user is not root

Can you make check on privileges?

./ntimed-client -t /tmp/ntimed ntp2.stratum2.ru ntp3.stratum2.ru 
ntimed-client: time_unix.c:94: kt_setfreq: Assertion `i >= 0' failed.
zsh: abort (core dumped)  ./ntimed-client -t /tmp/ntimed ntp2.stratum2.ru ntp3.stratum2.ru

Requires CFLAGS='-std=gnu99' to compile on at least CentOS 5.11

Don't know if you want these trivial issues. However, Ntimed requires CFLAGS='-std=gnu99' to compile on CentOS 5.11 with gcc 4.11. Otherwise it complains about missing NAN:

$ make
cc -Wall -Werror   -c -o combine_delta.o combine_delta.c
combine_delta.c: In function ‘CD_AddSource’:
combine_delta.c:204: error: ‘NAN’ undeclared (first use in this function)
combine_delta.c:204: error: (Each undeclared identifier is reported only once
combine_delta.c:204: error: for each function it appears in.)
make: *** [combine_delta.o] Error 1

suspicious re-assignment before old value has been read

tx.modes is reassigned without the old value has been read:

Ntimed/time_unix.c

Line 92 in db0abbb

tx.modes = MOD_FREQUENCY;

detected by cppcheck

Does not compile on Debian kFreebsd

Debian kFreeBSD is an oddball, in that it has GNU make as /usr/bin/make, but your configure script detects bsd-style make.

$ sh configure
Found bsd.prog.mk, will use it.
Makefile generated, remeber to run 'make depend'
$ make
Makefile:24: *** missing separator.  Stop.

Unfortunately, while my system has freebsd-make, that's broken too :(

$ freebsd-make depend
rm -f .depend
mkdep -f .depend -a     combine_delta.c ...
mkdep: No such file or directory
*** Error code 1

(mkdep is installed as freebsd-mkdep but the .mk files haven't been modified to reflect this. doh)

I would be happy to produce a patch to fix this, but I'm not sure what you would like in your philosophy of configure and build system.

The first idea that comes to mind is to check whether "make" (the one on $PATH) is a gnu-style make (the simplest test probably being make -v | grep -q GNU) rather than for the presence of bsd.mk in a standard location.

Another idea would be to generate both BSDMakefile as a BSD-format Makefile and GNUMakefile as a GNU-format Makefile (the debian manpage for freebsd-make says BSDMakefile is read in preference to Makefile/makefile, though I didn't do any checking for the universality of this)

If you let me know what approach you'd like to resolve this problem, I'll be happy to code and test it and prepare a pull request.

bsdphk / ntimed Goto Github PK

ntimed's People

Contributors

Stargazers

Watchers

Forkers

ntimed's Issues

Recommend Projects

Recommend Topics

Recommend Org