06 setembro, 2007
CNTP - the Civil Network Time Protocol
Some time ago I have started to study the clock drifts on VMware based guests (published on this article, in portuguese).
I have tried different approaches to make some (VMware) guests to synch their time correctly, but the clock behaviour was too erratic -- both hwclock command and system date were showing deviations, though in some guests the hwclock was a little more reliable.
I tried to use consecutive calls to ntpdate, the ntpd standard daemon, but nothing worked properly. ntpd protocol is too rigid and pedantic, after some time the ntpd just quitted.
CNTP first motivation is simplicity, second is to synch time. By this order.
CNTP stands for "Civil Network Time Protocol", a simple TCP service that has two basic entities: the server and the clients. It does not contain any stratums, authentication nor encryption, and by default is forkless -- this implies the server has no forks. Therefore clients may have to wait some time if the server is too busy attending requests, but the answer is relatively short and quick.
CNTP allows clock alignment with a second granularity: again, second goal is to synch time.
CNTP is a simple protocol that allows servers the optional knowledge for the local time, which depend on politics or logic behind DST (Daylight Saving Time).
Some specific protocol behaviour are derived from this protocol, the one covered in this article is VNTP. VNTP stands for "Virtual Network Time Protocol" -- suited especially for VMware guests, or machines with an unreliable clock.
The basic additional principle for VNTP is to have intelligent clients -- to minimize the charge of used VNTP servers. Nevertheless, on VMware guests it is expected to have lots of queries to the servers; the worse is the calculated clock drift the bigger is the number of queries.
VNTP clients have an additional important state called boundary. It varies typically between 1 and 9: one indicates a high drift (queries made on short periods), whilst 9 indicates a low drift (queries made on long periods, aligned to a minute boundary); the special value zero is used when the client does not use the minute boundary for alignment, but has no much of an interest.
The idea to avoid the minute boundary is to minimize the cases where the time adjustment (of HH:MM:SS + t seconds) makes SS seconds plus the calculated drift to change the system minute abruptly.
VNTP clients use always 'Ax' CNTP commands, usually x='b', so just 'Ab' CNTP commands; the length of commands sent is always 128 bytes.
Servers are identified as polite and non-polite; polite servers respond exactly as per CNTP protocol, whilst non-polite servers are those who refuse to connect, or provide long or short answers. Both are accepted by the client, as long as the response can be parsed.
VNTP clients never update the clock when the server is in the same second.
VNTP clients update the clock forward, or backwards; in the latter case they do it much slower -- motivation is to avoid an abrupt move of time back to the past. Usually VMware guests are delayed, their drift is rarely positive.
I have tried different approaches to make some (VMware) guests to synch their time correctly, but the clock behaviour was too erratic -- both hwclock command and system date were showing deviations, though in some guests the hwclock was a little more reliable.
I tried to use consecutive calls to ntpdate, the ntpd standard daemon, but nothing worked properly. ntpd protocol is too rigid and pedantic, after some time the ntpd just quitted.
CNTP first motivation is simplicity, second is to synch time. By this order.
CNTP stands for "Civil Network Time Protocol", a simple TCP service that has two basic entities: the server and the clients. It does not contain any stratums, authentication nor encryption, and by default is forkless -- this implies the server has no forks. Therefore clients may have to wait some time if the server is too busy attending requests, but the answer is relatively short and quick.
CNTP allows clock alignment with a second granularity: again, second goal is to synch time.
CNTP is a simple protocol that allows servers the optional knowledge for the local time, which depend on politics or logic behind DST (Daylight Saving Time).
Some specific protocol behaviour are derived from this protocol, the one covered in this article is VNTP. VNTP stands for "Virtual Network Time Protocol" -- suited especially for VMware guests, or machines with an unreliable clock.
The basic additional principle for VNTP is to have intelligent clients -- to minimize the charge of used VNTP servers. Nevertheless, on VMware guests it is expected to have lots of queries to the servers; the worse is the calculated clock drift the bigger is the number of queries.
VNTP clients have an additional important state called boundary. It varies typically between 1 and 9: one indicates a high drift (queries made on short periods), whilst 9 indicates a low drift (queries made on long periods, aligned to a minute boundary); the special value zero is used when the client does not use the minute boundary for alignment, but has no much of an interest.
The idea to avoid the minute boundary is to minimize the cases where the time adjustment (of HH:MM:SS + t seconds) makes SS seconds plus the calculated drift to change the system minute abruptly.
VNTP clients use always 'Ax' CNTP commands, usually x='b', so just 'Ab' CNTP commands; the length of commands sent is always 128 bytes.
Servers are identified as polite and non-polite; polite servers respond exactly as per CNTP protocol, whilst non-polite servers are those who refuse to connect, or provide long or short answers. Both are accepted by the client, as long as the response can be parsed.
VNTP clients never update the clock when the server is in the same second.
VNTP clients update the clock forward, or backwards; in the latter case they do it much slower -- motivation is to avoid an abrupt move of time back to the past. Usually VMware guests are delayed, their drift is rarely positive.
