[ntp:questions] Source address in response always the same as target address in request?
Are there any clear requirements in NTP/SNTP RFC docs about the UDP source address in all responses the same as the UDP target address in the original requests? I doubt it would be a UDP requirement because this is domain of upper protocols. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Any samples for NTP/SNTP client code?
On Dec 3, 3:34 am, [EMAIL PROTECTED] (David Woolley) wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: QueryPerformanceCounter() directly off the hardware. Windows scheduling has no impact here, the drawbacks of tick counts do not Windows scheduling will cause uncertainty in the time you get from your SNTP requests which you use to calibrate the performance counters. (It will also cause uncertainties in the time of whatever real world event is associated with the times being recorded by your software.) Windows scheduling will NOT cause any bigger uncertainty than many other factors including network delays or scheduling on my Linksys router (probably Unix-like OS) that relays all my incoming/outgoing IP traffic. The most important thing is that my code will be able to measure fairly consistently the time between sending a request and receiving a reply for ***all*** servers in microseconds. I will use at least five servers. It would not be possible with TICKS but it is possible with high frequency counters because they operate on different principle as stated. This is the key difference!!! Consequently, it will be possible to estimate the drift of the PC counter and come up with servers' polling frequencies that satisfy my reqs for accuracy. So do not make it more complicated than it is. The rest belongs to the algorithims I will use and you do not know them, and I am not ready to discusss them. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Any samples for NTP/SNTP client code?
On Dec 3, 2:18 pm, Jan Ceuleers [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Just look at the NTP/SNTP request format and for ***every*** field explain why would a client send it to a server. Do not pick just one field like MODE, explain for ***all*** fields. I believe that the principal reason for having the same format for the received and the transmitted packet is so that the server can reply simply by modifying the received packet and transmitting the result. There is no need to reuse storage from a received request to create a response. Even during early 80's when NTP protocol was conceived this kind of explanation would not fly. Even if you really wanted to reuse you would simply define all the request-specifc fields at the beginning of the packet and the server would overlay the received request at the beginnging of the response, and all the rest would be the same. A client would send only request-specific fields and the server would send them all the fields. This means that there is no need to allocate memory for constructing the reply packet, no need to copy data from received to transmitted packet, etc. As explained above, the same could be acomplished with a simple overlay. Besides, it is funny to talk about allocating memory of 48 bytes by a server designed around a single task of sending 48 bytes. It is like talking about UPS service renting a truck every time when it has to ship a single package. Even it does not make sense for a client. Definitely, you do not allocate ***dynamically*** memory that is used all the time. This could conceivably be done very close to (or indeed in) the hardware, but even if it is done in user space (as is the case in ntpd) this saves precious time, which is important in a timing application. I guarantee you that all the software servers incl. ntpd have so much cpu and memory waste in them that talking about optimizing/copying 48 bytes is like cleaning up the streets of a major city with a single toothbrush, even during the 80s. Optimising the packet format for conveying just enough information (i.e. optimising for bandwidth) is of secondary importance (particularly given the overhead that IP already represents), and is in fact counterproductive in the light of the above argument. Sending an empty response packet inside a request is like ordering a product by sending an empty box first. Such a bandwidth waste would not be tolerated during the 80s. Apparently, this went unnoticed during the 80s because the IP traffic was relatively small, and the IP traffic with time requests (NTP or otherwise) was even smaller. So nobody cared. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Any samples for NTP/SNTP client code?
On Dec 2, 7:03 am, [EMAIL PROTECTED] (David Woolley) wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] writes: Does anybody know of any *practical* samples on how to implement NTP/SNTP client?. The goal is to provide accurate From your description, NTP is not an option, as implementing NTP requires implementing most of the relevant (draft) RFC. What you are discussing is only SNTP. Existing packages set the PC system/CMOS clock, and my application would have to read it which is not very reliable approach. If Vista still doesn't interpolate between clock ticks, it is unlikely that your application is going to have precise enough scheduling delays for things to really matter. The real problem is you've chose an HCI platform for use in a timing critical application. On a platform that does interpolate clock ticks, you should expect a one to two orders of magnitude better time by reading the system clock, synchronised by NTP, as compared with doing a one off SNTP exchange. If the clock ticks aren't interpolated, you need a very good understanding of the scheduling and interrupt latencies in your system, which will probably make extracting the SNTP packet details from the NTP or, better, SNTP specifications, trivial. I don't think Vista has been around long enough for such information to become available, and most IT managers seem to be avoiding Vista like the plague, so it may be some time before someone interested in accurate time makes the measurements. You seem to assume the ticks used by the PC system time, e.g. you get them with GetTickCount(). Most if not all new PC's have an extra hardware chip called high-performance counter (probably located in the processor itself, maybe even use the cycle rate of the processor clock). You read such a counter with QueryPerformanceCounter() directly off the hardware. Windows scheduling has no impact here, the drawbacks of tick counts do not apply here. The high-performance counter has frequency 5-20MHz depending on the PC model, i.e. you get resolution of less than 1 microsec/count, directly off the hardware. The issue here is what is the drift of this counter. Once I code my SNTP client I will check it, ans also I will compare to PC ticks. WinZip, which most power users of Windows seem to have, can handle this. Also, to the best of my recollection, gzip compiles easily on Windows and there ought to be Windows builds of it around on the net. The problem with any free utilities for Windows is that I have to spend the time to decide which one of them is safe enough to install on my PC. Nowadays, most of them are infested with viruses and crapware. I plan to use my very old PC, now packed in a box. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Any samples for NTP/SNTP client code?
Does anybody know of any *practical* samples on how to implement NTP/SNTP client?. The goal is to provide accurate time for a program/client running on Windows Vista. Specifically, what values to include in the the request message, how to process the reply message, etc. I am NOT asking how to send/receive UDP datagrams, or where to find comprehensive descriptions like RFC documents, or how to build or design user interfaces. Only a narrow description focused on NTP/SNTP request/reply datagrams for a simple PC client, preferably in C/C++ source code. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Any samples for NTP/SNTP client code?
On Dec 1, 3:07 pm, Joseph Gwinn [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Does anybody know of any *practical* samples on how to implement NTP/SNTP client?. The goal is to provide accurate time for a program/client running on Windows Vista. Specifically, what values to include in the the request message, how to process the reply message, etc. I am NOT asking how to send/receive UDP datagrams, or where to find comprehensive descriptions like RFC documents, or how to build or design user interfaces. Only a narrow description focused on NTP/SNTP request/reply datagrams for a simple PC client, preferably in C/C++ source code. I've done this in an embedded realtime system. (No, the source code is not available.) In Appendix A of RFC-1305 you will find the format of the NTPv3 request/response packet. Send this packet to port 123 of the NTP server, and read the reply packet. It's pretty easy. I saw this format. From data comm point of view it is very unusual to have the same format for request and reply. Sending/receiving the packet to port 123 is the first thing I tried. This is not an issue. The issue is to use all the values in request and reply correctly and reliably. And the quickest way is to get as many ***samples*** as possible, the RFC doc ***alone*** is the slowest way. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Any samples for NTP/SNTP client code?
On Dec 1, 3:40 pm, [EMAIL PROTECTED] (Hal Murray) wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] writes: Does anybody know of any *practical* samples on how to implement NTP/SNTP client?. The goal is to provide accurate time for a program/client running on Windows Vista. Just curious. Why do you want to roll your own as compared to run one of the existing packages? Existing packages set the PC system/CMOS clock, and my application would have to read it which is not very reliable approach. My app needs direct access to periodic (5-60mins) accurate ***direct* timestamps and it will use high frequency counter provided by PC between. Only a narrow description focused on NTP/SNTP request/reply datagrams for a simple PC client, preferably in C/C++ source code. I don't know of any good code you can copy. I does not have to be a source code but a description/algorithm by somebody who actually coded reliably. I'd start at: http://support.ntp.org/bin/view/Main/SoftwareDownloads and look in the sntp directory. I did find it. However, the packages use gz formats used by Unix. My PC does not have any utility to uncompress them. There are two issues. (maybe more) One is getting the time right. The other is not screwing up the rest of the network or putting an unreasonable load on the servers. Please be sure to read: NTP server misuse and abuse http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
