Re: [ntp:questions] Issues with ACCORD Reference Clock Driver
1. Accord GPS Clock spits out NMEA at 9600 baudrate The NMEA specs call for 4800. Is there some way to set the Accord box to run at 4800? That seems only sensible if they are in the NMEA market. 2. It has custom NMEA format for GPS (and the driver is intended to use this ) What sort of custom format is this? Why is it better than the normal NMEA formats? Is it enoug better to be worth all the trouble of fixing a driver? 3. It also spits out time and status messages in a proprietary binary format (not yet tested...but wll do ) Lots of NMEA devices also have a binary mode. Who cares if the NMEA mode works well enough. What does the binary mode tell you that the NMEA mode doesn't? -- 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
Re: [ntp:questions] Issues with ACCORD Reference Clock Driver
I I don't know; it seems to me better for the refclock driver to specify a default set of comm parameters that will work for the standard device that refclock supports, but have a universal mechanism that would allow overriding those params from the config file and would work for any driver. We are probably having a violent agreement. I'd like to be able to say Z3801A rather than whatever line settings it actually uses. I'd also like to be able to specify the raw line details in case I find a box that is close enough but uses some strange line settings. (The Z3801A is a good example. That was the only change it took.) -- 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
Re: [ntp:questions] Issues with ACCORD Reference Clock Driver
Over the years and with some effort several drivers now support more than one device. All TrueTime models are supported by one driver; all Spectracom models by another and all telephone modem services by a third. With few exceptions, a NMEA radio is a NMEA radio and I strongly suspect many of those drivers could be combined in one driver. The NMEA driver already handles many more types of gizmos than most other drivers. I have 4 or 5 (and 2 more untested) within arms reach. You don't appreciate how tedious the support process is when some important thing or other requires a minute change in the common interface (nanoseconds unstead of microseconds) and modifications to 46 files. The urge for utmost KISS and fewest driver files in the public distribution is very strong. The problem is that the distribution build process is so intricate that few refclock builders, including me, can figure out how to incorporate a new driver in a private distribution other than as a cuckoo of a current one. It would be neat to solve this mess. I'm not sure I have any great suggestions. Maybe there should be two classes of drivers. Class 1 drivers come with the official distribution. Class 2 get supported by some other mechanism. That might make sense if somebody was willing to keep track of driver numbers, or somebody figures out a way to do the linking without driver numbers. (The changes to clockstats and peerstats would be interesting. Maybe replace the IP address with name.index or something like that. Or maybe the boundary could be fuzzy. You fixup the drivers you like and the rest of them are disabled until somebody fixes them up too. I'd be willing to do that for any driver I'm interested in. If you want to make a big change, you just shoot all the drivers you don't like. They are no-go until somebody rescues them. That way the distribution mechanism carries the best copy of a driver even if it doesn't compile/build right now. -- 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
[ntp:questions] Using mode byte for Accord GPS Clock
Hi all, The 'mode' field a.k.a 'ttl' for NMEA reference driver is used to select the NMEA sentence. I cannot use the unused fudge flags 'flag1' and 'flag4' as they are unavailable before the serial port is opened. Somehow I have to select both the baudrate and the NMEA sentence from the 'mode' field itself. Currently 'mode' field with values 0,1,2,4 are used in NMEA reference driver with default baudrate of 4800. Can I use the 'mode' field with value 8 and the rest of the three bits to select NMEA sentence. 1. Mode value 8 = 9600, GPXXX 2. Mode value 9 = 9600, GPRMC 3. Mode value 10 = 9600, GPGGA 4. Mode value 11 = 9600, GPGLL 5. Mode value 12 = 9600, GPZDG (Accord custom NMEA sentence) 6. Mode value 13 = 9600, GPZDA So the 4th bit of the 'mode' field is used to check if baudrate needs to be changed, while the rest of the 3 bits denote the NMEA sentence to be selected. Comments plz... Venu. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Issues with ACCORD Reference Clock Driver
Hal Murray wrote: I I don't know; it seems to me better for the refclock driver to specify a default set of comm parameters that will work for the standard device that refclock supports, but have a universal mechanism that would allow overriding those params from the config file and would work for any driver. We are probably having a violent agreement. I'd like to be able to say Z3801A rather than whatever line settings it actually uses. I'd also like to be able to specify the raw line details in case I find a box that is close enough but uses some strange line settings. (The Z3801A is a good example. That was the only change it took.) Yup, we're on the same page. John ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Any samples for NTP/SNTP client code?
Martin Burnicki wrote: AFAIK the code in the SNTP subdirectory has not yet been ported to Windows ... Martin We probably wron't try since that code is supposed to be rewritten. The effort doesn't justify the cost. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Using mode byte for Accord GPS Clock
Hi all, I am sorry, the mode field and corresponding configuration should be as follows to preserve the existing NMEA sentences in the driver. Mode value 8 = 9600, GPXXX Mode value 9 = 9600, GPRMC Mode value 10 = 9600, GPGGA Mode value 11 = 9600, GPZDG (Accord custom NMEA sentence) Mode value 12 = 9600, GPGLL Mode value 13 = 9600, GPZDA Venu. On 12/4/07, venu gopal [EMAIL PROTECTED] wrote: Hi all, The 'mode' field a.k.a 'ttl' for NMEA reference driver is used to select the NMEA sentence. I cannot use the unused fudge flags 'flag1' and 'flag4' as they are unavailable before the serial port is opened. Somehow I have to select both the baudrate and the NMEA sentence from the 'mode' field itself. Currently 'mode' field with values 0,1,2,4 are used in NMEA reference driver with default baudrate of 4800. Can I use the 'mode' field with value 8 and the rest of the three bits to select NMEA sentence. 1. Mode value 8 = 9600, GPXXX 2. Mode value 9 = 9600, GPRMC 3. Mode value 10 = 9600, GPGGA 4. Mode value 11 = 9600, GPGLL 5. Mode value 12 = 9600, GPZDG (Accord custom NMEA sentence) 6. Mode value 13 = 9600, GPZDA So the 4th bit of the 'mode' field is used to check if baudrate needs to be changed, while the rest of the 3 bits denote the NMEA sentence to be selected. Comments plz... Venu. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Dual-core systems - AMD - Windows Vista
David, David J Taylor wrote: Martin Burnicki wrote: [] I've just set up a new test under Vista, so let's see. What I can say right now is that the default tick adjustment value is 156001 instead of 156250 which it used to be on earlier Windows versions. Also the granularity of the system clock has changed from 15.625 ms to 1 ms. Maybe the timer tick interpolation code is not quite appropriate for these settings. Martin Martin, thanks for that interesting information. I'd love to know if you see similar offsets to me, or if it's just a quirk of the system here. It's a test system and not a production one, so if you need anything tested just shout. As you may have seen, I have been trying to get ntpd to compile here, but with little joy so far. I had made a fresh installation of Vista and forgot to disable automatic sleep mode, so my overnight test failed and I had to run it once more over the last hours. The test machine is a Intel Pentium D 3 GHz (dual core) with Windows Vista x64. Data of the time synchronization performance was collected by the time adjustment service which comes with the Meinberg driver package for Windows. That service computes the difference between the Windows system time and a built-in GPS170PCI card and normally disiplines the system time. However, in order to test the accuracy of NTP the Meinberg time service was configured just to collect data and not to apply any correnctions to the system time. I have run both the current NTP stable version ntp-4.2.4p4, and the current ntp-dev version ntp-dev-4.2.5p104, configured to get the time from a GPS controlled NTP server on the local network, which provides magnitues more accuracy than we can see here. Both versions of NTP showed similar dissatisfying results. The offset varies from about 20 to more than 50 milliseconds, so there's a bias of about 30 to 40 milliseconds. See the following graph: http://www.meinberg.de/download/ntp/graphs/ntp-dev-4.2.5p104-windows-vista-x64.pdf In order to show that it's possible to yield better results even on a 64 bit platform I have disabled the NTP service and enabled our time adjustment service start to discipline the system time. The results can be seen at the end of the graph. In order to make the results better visible I've also generated another graph with different scaling of the time offset: http://www.meinberg.de/download/ntp/graphs/ntp-dev-4.2.5p104-windows-vista-x64-details.pdf Please note both NTP and our time adjustment service are simple 32 bit apps compiled with VC6, so as a conclusion we can say that there is neither a general problem with the 64 bit OS nor with the 64 bit hardware architecture. As already mentioned earlier I _assume_ there is a glitch in the NTP code which doesn't convert or interpolate the Windows time stamps properly under Vista. I'll try to find out more. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Dual-core systems - AMD - Windows Vista
Martin Burnicki wrote: David, [] I had made a fresh installation of Vista and forgot to disable automatic sleep mode, so my overnight test failed and I had to run it once more over the last hours. Been there, done that! The test machine is a Intel Pentium D 3 GHz (dual core) with Windows Vista x64. Data of the time synchronization performance was collected by the time adjustment service which comes with the Meinberg driver package for Windows. That service computes the difference between the Windows system time and a built-in GPS170PCI card and normally disiplines the system time. However, in order to test the accuracy of NTP the Meinberg time service was configured just to collect data and not to apply any correnctions to the system time. Understood. I have run both the current NTP stable version ntp-4.2.4p4, and the current ntp-dev version ntp-dev-4.2.5p104, configured to get the time from a GPS controlled NTP server on the local network, which provides magnitues more accuracy than we can see here. Both versions of NTP showed similar dissatisfying results. The offset varies from about 20 to more than 50 milliseconds, so there's a bias of about 30 to 40 milliseconds. See the following graph: http://www.meinberg.de/download/ntp/graphs/ntp-dev-4.2.5p104-windows-vista-x64.pdf In order to show that it's possible to yield better results even on a 64 bit platform I have disabled the NTP service and enabled our time adjustment service start to discipline the system time. The results can be seen at the end of the graph. OK, I see both versions. In order to make the results better visible I've also generated another graph with different scaling of the time offset: http://www.meinberg.de/download/ntp/graphs/ntp-dev-4.2.5p104-windows-vista-x64-details.pdf Please note both NTP and our time adjustment service are simple 32 bit apps compiled with VC6, so as a conclusion we can say that there is neither a general problem with the 64 bit OS nor with the 64 bit hardware architecture. As already mentioned earlier I _assume_ there is a glitch in the NTP code which doesn't convert or interpolate the Windows time stamps properly under Vista. I'll try to find out more. Martin I find it difficult to judge the results in comparison with mine as the timescales cover a rather different range, but the message is clear - under Vista (your 64-bit or my 32-bit) timekeeping with NTP is orders of magnitude worse than it should be. It might be interesting to try disabling the interpolation, and see if that improves things. I'd try that here is only I could get NTP to compile with Visual Studio 2005! If you have a version you want me to test on Vista 32-bits here, just let me know. I do appreciate your efforts with this. Cheers, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Issues with ACCORD Reference Clock Driver
Perhaps the best way is to add a completely new command refclock and load it up with all kinds of options, including those now done by the fudge command. The command would not need the dotted quad, which could be replaced by the driver name already in a table. The syntax could in principle be different for each name, as determined by the parser. That could be a nice summer project. I like the idea of a refclock command. Here is a possibly crazy way to implement something like that... In addition to the procedures that are currently supplied in the linkage block from each refclock to the system, add a string that is the tokens that this driver knows about. The parser handles the merge of all possible options, collecting the info in a struct that gets passed to open. It also complains about options that this driver doesn't support. Open copies what it wants out of that struct, ignoring the fields it doesn't support. You might need a way to distinguish between 0 and unspecified. -1 for unspecified probably works. Use 0 and 1 for booleans. The open code would have to check for the unspecified case rather than just checking for non-zero. It might be possible to use the same mechanism for ntpdc. I don't know if the same set of options makes sense. If not, it just takes a second string to specify what is OK for ntpdc. -- 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
Re: [ntp:questions] Using mode byte for Accord GPS Clock (venu gopal)
Hi all, After going through the NMEA ref.clock driver, it seems that the original author has choosen values 0(GPXXX), 1(GPRMC), 2(GPGGA) and 4(GPGLL) for mode field so that multiple sentences can be selected. As posted earlier reg. using the mode byte/field to support Accord GPS Clock, fourth bit cannot be used to denote the baudrate. Fourth bit can denote GPZDG(8) (custom NMEA format) while the fifth bit can be used for baudrate 0(4800) and 1(9600). But in this case multiple sentences may be allowed only if the value of last four bits is less than 8, because GPZDG gives GPS time and not UTC like rest of them. So if GPZDG is selected, others sentences should not be selected. Venu ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Guys, In both the NTPv4 specification and reference implementation the destination address used by the client when mobilizeing the association and sending the request must match the source address when receiving the response. This is a property of all RPC protocols known to me that use addresses to match requests with responses. This is so obvious a requirement that maybe the specification doesn't make it clear enough. Dave Brian Utterback wrote: [EMAIL PROTECTED] wrote: 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. Yes and no. The basic protocol does not require it. The reference implementation does require it. The Autokey crypto authentication scheme currently requires it, but there has been some discussion recently about the nature of that requirement and whether it could be relaxed, but I don't see that discussion going anywhere in this regard. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Dual-core systems - AMD - Windows Vista
David J Taylor wrote: Danny Mayer wrote: [] With VS 2005, just open the dsw file and tell it to convert all the project files. I recently add the necessary macros to the dsp files so that I don't have to add a bunch of macros every time I pull in a new tarball. I'm only building on VS 2005 these days. Building on VS 6 I reserve for releasing builds. We don't ship the OpenSSL sources due to possible export regulations. You can download that yourself from the openssl.org site. Just follow the build instructions for Windows. I use the nt suboption. Thanks, Danny. I have now downloaded the OpenSSL sources, however, the file openssl/evp.h which ntp needs is not in a directory called openssl, but in a directory called crypto. Confusingly, in the project options you have a directory setting of: $(OPENSSL)\inc32, and I see no inc32 directory in the OpenSSL tree. I also seem to have trouble finding the build instructions you mentioned. You need to run the OpenSSL build first to create that directory. Just follow the instructions. Danny Cheers, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Issues with ACCORD Reference Clock Driver
Harlan, This has come up several times over the years (I give you the parse clocks as one approach). Here has been my reply on these occastions. Almost all reference clock derivers can be designed as a state machine which has largely been implemented in the reference clock interface. There is a state machine for received messages and another for transmitted messages. For most drivers this is rather simple with only silly details of polling and timeout remaining to be resolved. That took a good deal of development over several versions with a serious goal to keep it simple. What you might have in mind is the timecode interpretation. Once upon a time this was done in vastly different ways with lots of icky code. The reason for this was Dennis Fergusson's desire to use the code in an embedded system with no Unix library. Now the Unix library is in a wristwatch computer. Believing in Occam's Razon, I submit the ASCII timecode state machine of choice is the scanf() routine. The state machine program is simply the format string. Simple, fast and not too intrusive. I've never found an ASCII timecode that couldn't be easily parsed and error-checked this way. With the interface and these routines there isn't much else and what else would be hard to handle with a common state machine. Most drivers I have written use the read line/chunk routines in the interface, check line length, call scanf(), tease out the quality and leap bits and pass the data structure to the interface. Drivers are written so that several machines can share the received data while one of them polls the clock. For these reasons and long experience in crafting the interface and writing drivers, I don't think more is better. Dave Dave Harlan Stenn wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Hal Murray) writes: Hal I'd like to be able to say Z3801A rather than whatever line settings Hal it actually uses. I agree and suggest: http://support.ntp.org/bin/view/Dev/NewNtpConfFormat as I did in a previous reply on the parent thread. Hal I'd also like to be able to specify the raw line details in case I find Hal a box that is close enough but uses some strange line settings. (The Hal Z3801A is a good example. That was the only change it took.) I've wanted this for a long time too: http://support.ntp.org/bin/view/Dev/LoadableRefclockDrivers where I talk about a lightweight refclock processing language. H ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Dual-core systems - AMD - Windows Vista
Martin Burnicki wrote: Hm, the process CPU affinity is not restricted to a single CPU. Ntpd has 4 active threads, and only the CPU affinity of the clock interpolation thread is restricted to the first CPU since this is the only thread which calls QueryPerformanceCounter() and thus potentially reads the TSC of the CPU it is running on. The other threads may still run on either CPU. I'm not aware of a tool which displays the CPU affinity of a single thread, so I don't know right now how you can verify this, except by looking at the source code. I have a vague recollection of seeing one, but I don't remember where. I'll try and see what I can dig up. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Dual-core systems - AMD - Windows Vista
Danny Mayer wrote: [] You need to run the OpenSSL build first to create that directory. Just follow the instructions. Danny Danny, I'm afraid the build didn't work for me, so I tried creating a directory openssl in the ntp tree, and copied 33 header files from the OpenSSL tree. Having done that, I got hundreds of compiler warnings about a variety of topics (but not missing files), however, a .LIB file was missing presumably because of the failed buld. I find this in so many C/C++ projects - warnings which the author says to ignore those. But the missing Lib file is a fatal error. I really would prefer not to write this off, so can you please: - tell me how the environment should be defined so that there is no need to create the openssl directory and copy the headers there (I had expected an entry in the ntp project definition). What is $(OPENSSL) on your system? Perhaps I can match it on mine? - send the missing LIB file? It's \out32dll\libeay32.lib I'd love to help on this, but I am struggling! Cheers, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
