Re: [ntp:questions] Can NTP sync within 1ms
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: For Rob, I would suggest that each TX have a GPS/PPS reference with sky view, and that each PC was identical (e.g. all Raspberry Pi cards), and then getting them synced to with 12 microseconds should be easy. I Of course that is what we have. E.g. on a prototype here at home: ntpq -p remote refid st t when poll reach delay offset jitter == oPPS(0) .PPS.0 l2 16 3770.0000.000 0.000 xSHM(0) .GPS.0 l1 16 3770.0007.682 0.152 *SHM(1) .PPS.0 l 16 16 3770.0000.008 0.001 PPS(0) is a PPS input from a professional GPSDO connected to a COM port, SHM(1) is another GPS receiver interfaced via gpsd. Just to see how close they get and remain. Not Raspberry Pi (yet) but normal PC systems, but I know it is possible to get the system time within the desired 12 microseconds. Unfortunately that is not the same as performing some task like outputting audio at an accuracy of 12us, but that is the next challenge :-) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 29/04/2014 09:41, Rob wrote: [] Of course that is what we have. E.g. on a prototype here at home: ntpq -p remote refid st t when poll reach delay offset jitter == oPPS(0) .PPS.0 l2 16 3770.0000.000 0.000 xSHM(0) .GPS.0 l1 16 3770.0007.682 0.152 *SHM(1) .PPS.0 l 16 16 3770.0000.008 0.001 PPS(0) is a PPS input from a professional GPSDO connected to a COM port, SHM(1) is another GPS receiver interfaced via gpsd. Just to see how close they get and remain. Not Raspberry Pi (yet) but normal PC systems, but I know it is possible to get the system time within the desired 12 microseconds. Unfortunately that is not the same as performing some task like outputting audio at an accuracy of 12us, but that is the next challenge :-) Indeed, and you will likely want to look at very matched systems (PCs and transmitters - the whole chain), and having the minimum latency in the OS. I'm not familiar enough with Linux to know which variant to recommend, or whether FreeBSD or some other OS might be better. When comparing, be aware that there can be significant delays in things like RS-232 level converters etc., especially if they have rise-time limiting. Not to mention any delays in the COM port control lines! It sounds an interesting project. -- 73, David GM8ARV Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: Unfortunately that is not the same as performing some task like outputting audio at an accuracy of 12us, but that is the next challenge :-) Indeed, and you will likely want to look at very matched systems (PCs and transmitters - the whole chain), and having the minimum latency in the OS. I'm not familiar enough with Linux to know which variant to recommend, or whether FreeBSD or some other OS might be better. I already learned how this can be achieved in Alsa and it looks good. When comparing, be aware that there can be significant delays in things like RS-232 level converters etc., especially if they have rise-time limiting. Not to mention any delays in the COM port control lines! I first was afraid of that, and I wondered if the 10-30us pulse typically output by a GPSDO could be interfaced using an RS232 line. I considered it better to use a parallel port for this. However, parallel ports are not present on modern systems, USB replacements are no good for this purpose, and adding a parallel port requires a slot, also something usually on short supply. However, I now realize that 10us is equivalent to 100.000 bps, and all serial ports operate to 115.200 bps some even to 921.600 bps. So this probably will not be an issue after all. It sounds an interesting project. Yes, we sometimes need to try something new (at least to us) or else ham radio becomes boring pretty quickly. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 2014-04-29, Rob nom...@example.com wrote: David Taylor david-tay...@blueyonder.co.uk.invalid wrote: Unfortunately that is not the same as performing some task like outputting audio at an accuracy of 12us, but that is the next challenge :-) Indeed, and you will likely want to look at very matched systems (PCs and transmitters - the whole chain), and having the minimum latency in the OS. I'm not familiar enough with Linux to know which variant to recommend, or whether FreeBSD or some other OS might be better. I already learned how this can be achieved in Alsa and it looks good. When comparing, be aware that there can be significant delays in things like RS-232 level converters etc., especially if they have rise-time limiting. Not to mention any delays in the COM port control lines! I first was afraid of that, and I wondered if the 10-30us pulse typically output by a GPSDO could be interfaced using an RS232 line. I considered it better to use a parallel port for this. However, parallel ports are not present on modern systems, USB replacements are no good for this purpose, and adding a parallel port requires a slot, also something usually on short supply. However, I now realize that 10us is equivalent to 100.000 bps, and all serial ports operate to 115.200 bps some even to 921.600 bps. And many serial ports will handle TTL level just fine, without any serial level converters. (On RPi, there is a limit of something line 3V on the input pins, so putting out the 5-20V of a serial level converter could be very unhealthy.) So this probably will not be an issue after all. The problem is not the electronics, it is the response of the system to the interrupt. That interrupt processing time is in the usec range. It sounds an interesting project. Yes, we sometimes need to try something new (at least to us) or else ham radio becomes boring pretty quickly. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
William Unruh un...@invalid.ca wrote: The problem is not the electronics, it is the response of the system to the interrupt. That interrupt processing time is in the usec range. This does not really matter when it is constant. And my experience is that the jitter on the PPS refclock is usually 0, 1 or 2us when I check it. On a newer server that has just been configured for this task it is the same: remote refid st t when poll reach delay offset jitter == oPPS(0) .PPS.0 l 16 16 3770.000 -0.001 0.001 (the GPSDO is still synchronizing, things may be even better after that) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
William Unruh un...@invalid.ca wrote: On 2014-04-29, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: The problem is not the electronics, it is the response of the system to the interrupt. That interrupt processing time is in the usec range. This does not really matter when it is constant. And my experience is that the jitter on the PPS refclock is usually 0, 1 or 2us when I check it. That sounds like 100% variability. And the serial port level converter time delay is much more constant. Also look at the jitter when the system is heavily loaded with disk input/output or network load. This is included in the above figure. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 27/04/14 19:20, j...@specsol.spam.sux.com wrote: The goal is not to have 12us difference in arrival time, but to be within 12us for transmission time. But it is the difference in arrival time that will affect the quality of the audio that is heard, so it is that which you would need to control. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
William Unruh un...@invalid.ca wrote: On 2014-04-27, Rob nom...@example.com wrote: j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. Unless I fat fingered the calculator, that means the difference in distance between transmitters relative to the receiver can be no more than 3.6 km. 300 meters per microsecond; it is the law... The goal is not to have 12us difference in arrival time, but to be within 12us for transmission time. Why not within 12 psec? Ie, what is the reason for this requirement? And I thought this thread started with 1ms. I have hijacked this thread that was started by someone else who asked if Can NTP sync within 1ms. As usual on usenet, after some postings the topic drifted away. The 12us figure has been mentioned by two independent persons that are experts in the field of co-channel diversity networks and have implemented such networks in the past for professional purposes. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
David Woolley david@ex.djwhome.demon.invalid wrote: On 27/04/14 19:20, j...@specsol.spam.sux.com wrote: The goal is not to have 12us difference in arrival time, but to be within 12us for transmission time. But it is the difference in arrival time that will affect the quality of the audio that is heard, so it is that which you would need to control. But not necessarily within 12us. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 2014-04-28, Rob nom...@example.com wrote: Jochen Bern jochen.b...@linworks.de wrote: However, that *does* leave me wondering where the 12 us figure comes into play. With the typical distances between 2m and even 70cm repeaters, the mobile transceivers will see shifts *far* beyond that between different repeaters' signals. The figure comes from two different experts in the field. They have built such systems for the emergency services (police, fire brigade, ambulance) that have been operating in the country for a few decades and have been replaced by a digital (TETRA) system in the meantime. But their knowledge and experience remains valid. In those days we could not afford such an experiment, they used fixed analog leased lines to transfer audio with a fixed and known delay, but today we have internet and GPS and we can achieve the same thing much easier. FWIW, will you have the audio cards output AM (that will then get modulated onto an otherwise unsynchronized HF), or do you plan to have the card generate HF directly into the PA? The existing system mentioned above uses SDR techniques to synthesize the FM signal directly from the digital samples, but we like to use existing repeater hardware that already has FM modulation, so we want to use soundcards to produce analog audio that is fed into the repeaters. The HF is not unsynchronized, it is locked to a GPSDO. But I agree that it would be much more predictable to do it the digital way. Now we have extra variables like the exact deviation setting and the characteristics of the modulator. Fortunately all repeaters run the same hardware (Tait TB8100). I am still investigating how to output digital samples to a soundcard in Linux at exactly determined time (versus just writing sample blocks to the soundcard driver at a predermined moment. they will still be buffered after that) All in all it is funny to read all the that cannot be done-like comments by several persons on a ntp newsgroup while systems like this have been in use since the seventies, and in fact have already been build by amateurs and are in operation today. So I prefer to go by the experience of the people who built those networks, rather than the armchair experts. Not, it cannnot be done, but it is silly to try. I simply have a really really hard time figuring out why you want to do that. For voice, the max frequency is something like 4KHz (eg telephone quality) which is 250us (125us sampling) . It is really really hard for me to figure out what bad things would happen if that were the resolution you used instead of that 12us. It just seems wildly over-specified. And then you make statements like it is the transmission time that needs to be 12us not the reception time, which also do not make sense. And a phase jump even of 120usec I doubt would be audible, maybe 12 ms would be. (are you sure you did not misunderstand your experts?) If it really is 12us I would be really interested in knowing why. I might even learn something. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 28/04/14 16:19, William Unruh wrote: For voice, the max frequency is something like 4KHz (eg telephone quality) which is 250us (125us sampling) . Telephone quality is 3.1 kHz bandwidth from 300Hz to 3.4kHz, which allows for channel filters/realisable anti-aliasing filters. I believe that proper NBFM signals should have a 2.8kHz cut off. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
William Unruh un...@invalid.ca wrote: All in all it is funny to read all the that cannot be done-like comments by several persons on a ntp newsgroup while systems like this have been in use since the seventies, and in fact have already been build by amateurs and are in operation today. So I prefer to go by the experience of the people who built those networks, rather than the armchair experts. Not, it cannnot be done, but it is silly to try. I simply have a really really hard time figuring out why you want to do that. You apparently are not familiar with the radio amateur hobby. Most people have a hard time figuring out why you would want to construct a repeater to talk to someone else driving around in a car, when you could simply dial his number on the mobile phone. If it really is 12us I would be really interested in knowing why. I might even learn something. I already said that I was suprised about this as well, but I have heard it from two different persons who had not been working together and it was explicitly asked if if would not be 12ms instead of 12us. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 2014-04-28, David Woolley david@ex.djwhome.demon.invalid wrote: On 28/04/14 16:19, William Unruh wrote: For voice, the max frequency is something like 4KHz (eg telephone quality) which is 250us (125us sampling) . Telephone quality is 3.1 kHz bandwidth from 300Hz to 3.4kHz, which allows for channel filters/realisable anti-aliasing filters. Not sure why they would need a lower cutoff, except that it would allow the ancient telephone receivers to comply. Certainly one can make cheap receivers now that go a lot lower than 300Hz. I believe that proper NBFM signals should have a 2.8kHz cut off. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On Mon, Apr 28, 2014 at 10:14 AM, William Unruh un...@invalid.ca wrote: Not sure why they would need a lower cutoff, except that it would allow the ancient telephone receivers to comply. Certainly one can make cheap receivers now that go a lot lower than 300Hz. Because 3.1 kHz of bandwidth is cheaper for the telcos to trunk than 3.4 kHz. Henry ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 04/28/2014 07:37 PM, Henry Hallam wrote: On Mon, Apr 28, 2014 at 10:14 AM, William Unruh un...@invalid.ca wrote: Not sure why they would need a lower cutoff, except that it would allow the ancient telephone receivers to comply. Certainly one can make cheap receivers now that go a lot lower than 300Hz. Because 3.1 kHz of bandwidth is cheaper for the telcos to trunk than 3.4 kHz. Not really. The reason is that DC is used for signalling (e.g. on/off-hook, hookflash, pulse dialing). Way OT tho. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 28/04/14 18:14, William Unruh wrote: Not sure why they would need a lower cutoff, except that it would allow the ancient telephone receivers to comply. To give good carrier suppression on analogue carrier systems! I believe that there is also a lot of energy below 300Hz that doesn't contribute to intelligibility. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 2014-04-28, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: All in all it is funny to read all the that cannot be done-like comments by several persons on a ntp newsgroup while systems like this have been in use since the seventies, and in fact have already been build by amateurs and are in operation today. So I prefer to go by the experience of the people who built those networks, rather than the armchair experts. Not, it cannnot be done, but it is silly to try. I simply have a really really hard time figuring out why you want to do that. You apparently are not familiar with the radio amateur hobby. Most people have a hard time figuring out why you would want to construct a repeater to talk to someone else driving around in a car, when you could simply dial his number on the mobile phone. That was not what I had trouble figuring out. If it really is 12us I would be really interested in knowing why. I might even learn something. I already said that I was suprised about this as well, but I have heard it from two different persons who had not been working together and it was explicitly asked if if would not be 12ms instead of 12us. And they did not explain themselves!? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
For Rob, I would suggest that each TX have a GPS/PPS reference with sky view, and that each PC was identical (e.g. all Raspberry Pi cards), and then getting them synced to with 12 microseconds should be easy. I achieve this even with indoor GPS puck antennas: http://www.satsignal.eu/mrtg/performance_ntp.php on six RPis, with only the occasional glitch caused by signal drop-out. A better located antenna would prevent that. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
Paul tik-...@bodosom.net wrote: I don't know what terribly accurate might be to you but in the real world sufficient accuracy depends on the circumstance. Someone should conduct an experiment. I am in a group that works on a project that needs synchronous audio on geographically distributed PCs. Of course there are several hurdles. First, we sync all machines to locally connected GPS receivers with PPS output. We use ntpd and kernel PPS. This is wellknown territory. In the ntpq -p stats this appears to bring the systems within 10us, often within 2us, of the PPS signal. We still have to find out if this is reality or just output of a program. The next problem is to send output to a soundcard and making it send a sample at the sampling clock edge closest to a specified time. (48kHz sampling rate corresponds to a sampling clock period of 20.8us) When that has been achieved, it of course is easy to wire up two of those systems, place them closely together, and check on a scope. It could be further improved when we can somehow lock the sampling clock to the PPS signal, so another +/- 10uS uncertainty/jitter is removed. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
I use Windows 8.1 and regularly see offsets of less than 1 ms. Right now the offset is -0.105 and the jitter is 0.028. Twas not always thus; several factors contributed to these results: 1. Use of Gigabyte Ethernet on the LAN, and the LAN is lightly loaded. 2. A high speed Internet connection; either 15 Mbps or about 28 Mbps will improve accuracy because the delays between your LAN timer server and the Internet time servers are more consistent and more than halved WRT to a 1-3 Mbps connection. 3. The NTP client and LAN server is on a computer that runs FreeNAS, which is lightly loaded. FreeNAS runs on FreeBSD. Anecdotally, NTPD serves more accurate time on FreeBSD. 4. The ISP router to which you are connected really matters. If that router is congested so that delays through it vary by time of day, or increase greatly every time a neighbor downloads a movie or other long file, then you will serve widely varying time to the LAN. 5. The Internet Stratum 2 or 1 time servers you choose should be close-by (50-75 miles) and lightly loaded. If your LAN time server accesses time from a heavily loaded network and/or server, or the servers are more than 50-75 miles away, there is little hope of serving time with low jitter. You can find a list of U.S. Government time servers and their status by searching for NIST time servers, and of course there is a complete list of servers on www.ntp.org. Charles Elliott ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
First, we sync all machines to locally connected GPS receivers with PPS output. We use ntpd and kernel PPS. This is wellknown territory. In the ntpq -p stats this appears to bring the systems within 10us, often within 2us, of the PPS signal. We still have to find out if this is reality or just output of a program. You need to look up the specs of your GPS units to see what the PPS performance is spec'ed for. That uncertainty needs to be factored into your final figure. Likewise, are you inputting surveyed antenna coordinates at each location or just letting the receiver auto-survey? If the assumed position is off that is another source of time error. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 2014-04-27, Rob nom...@example.com wrote: Paul tik-...@bodosom.net wrote: I don't know what terribly accurate might be to you but in the real world sufficient accuracy depends on the circumstance. Someone should conduct an experiment. I am in a group that works on a project that needs synchronous audio on geographically distributed PCs. Of course there are several hurdles. First, we sync all machines to locally connected GPS receivers with PPS output. We use ntpd and kernel PPS. This is wellknown territory. In the ntpq -p stats this appears to bring the systems within 10us, often within 2us, of the PPS signal. We still have to find out if this is reality or just output of a program. reality. You can test the interrupt latencies on the machines (a few us) The next problem is to send output to a soundcard and making it send a sample at the sampling clock edge closest to a specified time. (48kHz sampling rate corresponds to a sampling clock period of 20.8us) It will certainly depend on the sound card. AFAIK most have their own internal oscillators, that are not adjustable. I suspect you will have to build your ownsoundcard to accomplish this. When that has been achieved, it of course is easy to wire up two of those systems, place them closely together, and check on a scope. It could be further improved when we can somehow lock the sampling clock to the PPS signal, so another +/- 10uS uncertainty/jitter is removed. 48KHz is 20us. Why are you worried about a few us? What are you trying to do? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
In article ljf8q0$mt2$3...@dont-email.me, William Unruh un...@invalid.ca wrote: On 2014-04-26, Joe Gwinn joegw...@comcast.net wrote: In article 8188ba2b01fb534a99c03d79c62ce1d80982f...@uusnwe3a.global.utcmail.com, Montgomery, Peter BIS peter.montgom...@fs.utc.com wrote: I am new to NTP. But I have a quick question that I need to answer soon. I would like to know whether NTP can sync between a client and a server within 1ms if the client and server are Linux applications on a simple local network ( less than 10 nodes). Not reliably, for a million reasons. A better rule is 10 milliseconds, and even that requires work and care. Well, since I have 8 machines that reliably sync from one GPS PPS driven machine (all using chrony) and they get time reliability of about 10microseconds, your experience seems a bit different than mine. And how did you determine that you were only getting 10ms. As I said, you cannot conclude that by looking at the offsets reported by ntpd. I've managed 7 microseconds rms in a sterile lab setup, but I would hardly tell people that they will achieve anything like that in an unconstrained and complex network. We know next to nothing about the OP's network et al, so I quoted a worst case. With added data, we may be able to tighten the estimate. Or, widen it if there turns out to be something unfortunate in the design. The most reliable approach is an IRIG network. Or put a gps pps receiver onto each machine. Yes, but IRIG is simpler and cheaper, and the OP asked for synchronized time, and did not mention any need for accurate time. For all we know, the OP has no access to the sky. But you need to describe your problem and constraints before people can give better answers. Agreed. And this is the key. Joe Gwinn ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
William Unruh un...@invalid.ca wrote: The next problem is to send output to a soundcard and making it send a sample at the sampling clock edge closest to a specified time. (48kHz sampling rate corresponds to a sampling clock period of 20.8us) It will certainly depend on the sound card. AFAIK most have their own internal oscillators, that are not adjustable. I suspect you will have to build your ownsoundcard to accomplish this. There are soundcards for professional use that support locking of the sampling clock to an external source. There is also a circuit from a French guy that generates a S/PDIF signal from an external reference and he claims many soundcards with S/PDIF can lock to that. I need to further investigate that. When that has been achieved, it of course is easy to wire up two of those systems, place them closely together, and check on a scope. It could be further improved when we can somehow lock the sampling clock to the PPS signal, so another +/- 10uS uncertainty/jitter is removed. 48KHz is 20us. Why are you worried about a few us? What are you trying to do? We are setting up a co-channel diversity network. That means multiple FM transmitters that are transmitting the same signal on the same frequency on different sites, where the receive areas partly overlap. The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 27/04/14 17:28, Rob wrote: We are setting up a co-channel diversity network. That means multiple FM transmitters that are transmitting the same signal on the same frequency on different sites, where the receive areas partly overlap. This problem has already been solved using COFDM (aka DAB) and it is much more tolerant of fading that is inevitable with co-channel transmitters than your system. The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. Your transmitters will have to be contained within a circle of 3.6km, reduced by the timing errors in the modulation at 0.3km/microsecond. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On Apr 27, 2014 10:19 AM, David Woolley david@ex.djwhome.demon.invalid wrote: On 27/04/14 17:28, Rob wrote: We are setting up a co-channel diversity network. That means multiple FM transmitters that are transmitting the same signal on the same frequency on different sites, where the receive areas partly overlap. This problem has already been solved using COFDM (aka DAB) and it is much more tolerant of fading that is inevitable with co-channel transmitters than your system. DAB is a nice system but unfortunately there are parts of the world where DAB receivers are unheard-of. Your transmitters will have to be contained within a circle of 3.6km, reduced by the timing errors in the modulation at 0.3km/microsecond. Only the distance between the receiver and all transmitters strong enough for it to receive need be 4 km. The overall network can be bigger if each transmitter is weak enough not to be heard too far away. Of course there will still be multipath issues with destructive interference at the carrier frequency even at much shorter distances. Henry ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
[Resend to list, rather than non-working(?) sender e-mail address] On -10.01.-28163 20:59, Rob wrote: We are setting up a co-channel diversity network. That means multiple FM transmitters that are transmitting the same signal on the same frequency on different sites, where the receive areas partly overlap. The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. I'm afraid I don't get it yet. You're trying to sync waveforms on the HF side (~100 MHz?) instead of switching between two transmitters on the AF side (couple kHz, with that much more leeway for the sync), a la perfectly normal car radio with RDS AF and dual tuners, because ... ? https://en.wikipedia.org/wiki/Radio_Data_System#Content_and_implementation Anyway - if you'ld like to talk to people who apparently have experience with syncing the HF side, at least to *some* degree, you might want to contact the companies operating the (toll) highways in France. They also operate radio stations with traffic announcements, and it's just *one* frequency (107.7 MHz) all across the country (since before the time they adopted RDS at all). I never noticed any transmitter hand-over within any single operator's coverage (while handover from one to another, with a completely different radio programme, is of course rather messy). http://www.autoroutes.fr/en/FM-107-7-radio.htm Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. Unless I fat fingered the calculator, that means the difference in distance between transmitters relative to the receiver can be no more than 3.6 km. 300 meters per microsecond; it is the law... The goal is not to have 12us difference in arrival time, but to be within 12us for transmission time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
David Woolley david@ex.djwhome.demon.invalid wrote: On 27/04/14 17:28, Rob wrote: We are setting up a co-channel diversity network. That means multiple FM transmitters that are transmitting the same signal on the same frequency on different sites, where the receive areas partly overlap. This problem has already been solved using COFDM (aka DAB) and it is much more tolerant of fading that is inevitable with co-channel transmitters than your system. It is not FM broadcast, it is (NB)FM communication. The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. Your transmitters will have to be contained within a circle of 3.6km, reduced by the timing errors in the modulation at 0.3km/microsecond. This turns out to be not the case. Networks like this have been operating for decades, only those were constructed using analog leased lines so there was no relation to ntp, soundcards etc. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
Jochen Bern jochen.b...@linworks.de wrote: [Resend to list, rather than non-working(?) sender e-mail address] On -10.01.-28163 20:59, Rob wrote: We are setting up a co-channel diversity network. That means multiple FM transmitters that are transmitting the same signal on the same frequency on different sites, where the receive areas partly overlap. The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. I'm afraid I don't get it yet. You're trying to sync waveforms on the HF side (~100 MHz?) instead of switching between two transmitters on the AF side (couple kHz, with that much more leeway for the sync), a la perfectly normal car radio with RDS AF and dual tuners, because ... ? It is not an FM broadcast system, it is an amateur radio repeater system with wide area coverage. Similar systems are in use, or at least have been in use, in repeater systems used by emergency services, taxi companies, etc. Of course it is possible to use different transmitters and find some way to switch the receivers. It is also possible to use a mobile phone to communicate. But amateur radio is about experimenting and self-education, and we just want to see if it can be done. In fact, it already has been done by another group using a different system setup, and we want to see if it can be done this way as well. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
Rob nom...@example.com wrote: j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. Unless I fat fingered the calculator, that means the difference in distance between transmitters relative to the receiver can be no more than 3.6 km. 300 meters per microsecond; it is the law... The goal is not to have 12us difference in arrival time, but to be within 12us for transmission time. What good does that do you? And regarding smooth reception while driving around, have you ever heard of multipath or the capture effect? -- Jim Pennino ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
Rob nom...@example.com wrote: David Woolley david@ex.djwhome.demon.invalid wrote: On 27/04/14 17:28, Rob wrote: We are setting up a co-channel diversity network. That means multiple FM transmitters that are transmitting the same signal on the same frequency on different sites, where the receive areas partly overlap. This problem has already been solved using COFDM (aka DAB) and it is much more tolerant of fading that is inevitable with co-channel transmitters than your system. It is not FM broadcast, it is (NB)FM communication. Which makes all of this even more irrelvant as communications circuits usually bandwidth limit to around 3.5 kHz. The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. Your transmitters will have to be contained within a circle of 3.6km, reduced by the timing errors in the modulation at 0.3km/microsecond. This turns out to be not the case. Networks like this have been operating for decades, only those were constructed using analog leased lines so there was no relation to ntp, soundcards etc. Just what part, given your original conditions, is not true about this? -- Jim Pennino ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: Your transmitters will have to be contained within a circle of 3.6km, reduced by the timing errors in the modulation at 0.3km/microsecond. This turns out to be not the case. Networks like this have been operating for decades, only those were constructed using analog leased lines so there was no relation to ntp, soundcards etc. Just what part, given your original conditions, is not true about this? It turns out to be working even though there are differences in path lengths, but for it to be working well one must not start off with a large difference in modulation timing. The goal is to be within 12us. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: Rob nom...@example.com wrote: j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. Unless I fat fingered the calculator, that means the difference in distance between transmitters relative to the receiver can be no more than 3.6 km. 300 meters per microsecond; it is the law... The goal is not to have 12us difference in arrival time, but to be within 12us for transmission time. What good does that do you? And regarding smooth reception while driving around, have you ever heard of multipath or the capture effect? Well, smooth reception must be explained as communication is possible, not with the HIFI quality expected from a broadcast station. What I mean is that you can drive around and receive the signal all over the place, even when you drive out of range of one transmitter into the range of the next. It works perfectly when the capture effect results in reception of one transmitter, and in the area where two transmitters are equal in strength it requires suitable synchronization to still have good communication. I did not come up with the 12us figure, I would have guessed it a bit higher. The figure comes from different experts in the field. The people that designed and deployed such systems in the world of emergency services etc. We can now try it in amateur radio because the advances in technology have made things like GPSDOs and fast network connections affordable. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
Rob nom...@example.com wrote: Jochen Bern jochen.b...@linworks.de wrote: [Resend to list, rather than non-working(?) sender e-mail address] On -10.01.-28163 20:59, Rob wrote: We are setting up a co-channel diversity network. That means multiple FM transmitters that are transmitting the same signal on the same frequency on different sites, where the receive areas partly overlap. The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. I'm afraid I don't get it yet. You're trying to sync waveforms on the HF side (~100 MHz?) instead of switching between two transmitters on the AF side (couple kHz, with that much more leeway for the sync), a la perfectly normal car radio with RDS AF and dual tuners, because ... ? It is not an FM broadcast system, it is an amateur radio repeater system with wide area coverage. Similar systems are in use, or at least have been in use, in repeater systems used by emergency services, taxi companies, etc. Of course it is possible to use different transmitters and find some way to switch the receivers. It is also possible to use a mobile phone to communicate. But amateur radio is about experimenting and self-education, and we just want to see if it can be done. In fact, it already has been done by another group using a different system setup, and we want to see if it can be done this way as well. It is all made irrelevant by a combination of channel bandwidth and the capture effect. http://en.wikipedia.org/wiki/Capture_effect Unless there is a huge difference in transmission times, no one is going to notice unless they are somewhere where the signal strength of multiple transmitters is roughly equal and then your major problem will be picket fencing, not audio synchronization. -- Jim Pennino ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
Rob nom...@example.com wrote: j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: Rob nom...@example.com wrote: j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. Unless I fat fingered the calculator, that means the difference in distance between transmitters relative to the receiver can be no more than 3.6 km. 300 meters per microsecond; it is the law... The goal is not to have 12us difference in arrival time, but to be within 12us for transmission time. What good does that do you? And regarding smooth reception while driving around, have you ever heard of multipath or the capture effect? Well, smooth reception must be explained as communication is possible, not with the HIFI quality expected from a broadcast station. What I mean is that you can drive around and receive the signal all over the place, even when you drive out of range of one transmitter into the range of the next. It works perfectly when the capture effect results in reception of one transmitter, and in the area where two transmitters are equal in strength it requires suitable synchronization to still have good communication. Picket fencing makes it irrelevant. I did not come up with the 12us figure, I would have guessed it a bit higher. The figure comes from different experts in the field. The people that designed and deployed such systems in the world of emergency services etc. Are you sure that figure is NOT for data communications? Most emergency services have voice and data these days. We can now try it in amateur radio because the advances in technology have made things like GPSDOs and fast network connections affordable. I don't see where that is relevant to anything here. -- Jim Pennino ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: Rob nom...@example.com wrote: j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: Rob nom...@example.com wrote: j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. Unless I fat fingered the calculator, that means the difference in distance between transmitters relative to the receiver can be no more than 3.6 km. 300 meters per microsecond; it is the law... The goal is not to have 12us difference in arrival time, but to be within 12us for transmission time. What good does that do you? And regarding smooth reception while driving around, have you ever heard of multipath or the capture effect? Well, smooth reception must be explained as communication is possible, not with the HIFI quality expected from a broadcast station. What I mean is that you can drive around and receive the signal all over the place, even when you drive out of range of one transmitter into the range of the next. It works perfectly when the capture effect results in reception of one transmitter, and in the area where two transmitters are equal in strength it requires suitable synchronization to still have good communication. Picket fencing makes it irrelevant. This precisely makes it a requirement to synchronize the audio. When this is not done, there will be extreme jitter in the audio which makes it unintelligible. What surprises me is that the audio has to be synchronized so well. But we are just going to do that, or approach it as closely as possible. I did not come up with the 12us figure, I would have guessed it a bit higher. The figure comes from different experts in the field. The people that designed and deployed such systems in the world of emergency services etc. Are you sure that figure is NOT for data communications? Most emergency services have voice and data these days. Emergency services don't use NBFM systems anymore. At least not here. The networks I am talking about were deployed between the seventies and nineties of last century. We can now try it in amateur radio because the advances in technology have made things like GPSDOs and fast network connections affordable. I don't see where that is relevant to anything here. I am ending this discussion, I only answered the question what are you trying to do and I don't need to account for our experiment to you or anyone else on this group. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
Rob nom...@example.com wrote: j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: Your transmitters will have to be contained within a circle of 3.6km, reduced by the timing errors in the modulation at 0.3km/microsecond. This turns out to be not the case. Networks like this have been operating for decades, only those were constructed using analog leased lines so there was no relation to ntp, soundcards etc. Just what part, given your original conditions, is not true about this? It turns out to be working even though there are differences in path lengths, but for it to be working well one must not start off with a large difference in modulation timing. The goal is to be within 12us. Why? What would you see as a timing difference given no correction? What is your definition of working well? How do you avoid picket fencing? -- Jim Pennino ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
Rob nom...@example.com wrote: j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: Rob nom...@example.com wrote: j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: Rob nom...@example.com wrote: j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. Unless I fat fingered the calculator, that means the difference in distance between transmitters relative to the receiver can be no more than 3.6 km. 300 meters per microsecond; it is the law... The goal is not to have 12us difference in arrival time, but to be within 12us for transmission time. What good does that do you? And regarding smooth reception while driving around, have you ever heard of multipath or the capture effect? Well, smooth reception must be explained as communication is possible, not with the HIFI quality expected from a broadcast station. What I mean is that you can drive around and receive the signal all over the place, even when you drive out of range of one transmitter into the range of the next. It works perfectly when the capture effect results in reception of one transmitter, and in the area where two transmitters are equal in strength it requires suitable synchronization to still have good communication. Picket fencing makes it irrelevant. This precisely makes it a requirement to synchronize the audio. When this is not done, there will be extreme jitter in the audio which makes it unintelligible. What surprises me is that the audio has to be synchronized so well. But we are just going to do that, or approach it as closely as possible. Nope, it is precisely what makes synchronized audio irrelevant. If you have picket fencing, you have no intelligible audio no matter what you do at the transmitters. I did not come up with the 12us figure, I would have guessed it a bit higher. The figure comes from different experts in the field. The people that designed and deployed such systems in the world of emergency services etc. Are you sure that figure is NOT for data communications? Most emergency services have voice and data these days. Emergency services don't use NBFM systems anymore. At least not here. The networks I am talking about were deployed between the seventies and nineties of last century. Then what the hell are you talking about? We can now try it in amateur radio because the advances in technology have made things like GPSDOs and fast network connections affordable. I don't see where that is relevant to anything here. I am ending this discussion, I only answered the question what are you trying to do and I don't need to account for our experiment to you or anyone else on this group. No, you don't. You can ignore any comments by people with over half a century of experience and go off and waste your time tilting at windmills. -- Jim Pennino ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On -10.01.-28163 20:59, Rob wrote: Jochen Bern jochen.b...@linworks.de wrote: I'm afraid I don't get it yet. You're trying to sync waveforms on the HF side (~100 MHz?) instead of switching between two transmitters on the AF side (couple kHz, with that much more leeway for the sync), a la perfectly normal car radio with RDS AF and dual tuners, because ... ? It is not an FM broadcast system, it is an amateur radio repeater system with wide area coverage. Alright, I think I'm closing in on some basic concepts now. :-} You have existing mobile FM transceivers and existing individual repeaters (including the non-equidistant rather far in-between sites they're installed at) and you want to add sort of a central control to the repeaters so that they act in unison, relaying one input to the *entire* coverage area, and in such a way that the mobile transceivers do not have to care (read: QSY) which single repeater they're currently covered by - RX as well as TX. First good news, you won't have much of a problem if a participant getting handed over from one repeater to another experiences a time jump (relative to the master audio stream) even of several tenths of a second. Second good news, the audio stream will likely experience pauses (everytime one OM hands the mic to another) more often than the mobile devices will need to switch over to a new repeater. With tight enough a squelch, your repeaters can actually drop output power during that pause, which might help the mobiles switch over even in the presence of capture effect etc. during the power-up phases. On the not-so-good side, once a random participant finally got the PTT squished, your repeaters will have to have a quorum decision which repeater's *input* to use for the master audio stream of the entire system. (And you might want to modulate the repective repeater's ID over it in CW, or else crocodile hunting will get pretty tedious. ;-) However, that *does* leave me wondering where the 12 us figure comes into play. With the typical distances between 2m and even 70cm repeaters, the mobile transceivers will see shifts *far* beyond that between different repeaters' signals. FWIW, will you have the audio cards output AM (that will then get modulated onto an otherwise unsynchronized HF), or do you plan to have the card generate HF directly into the PA? Regards, DD0KZ -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 2014-04-27, Rob nom...@example.com wrote: j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote: The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. Unless I fat fingered the calculator, that means the difference in distance between transmitters relative to the receiver can be no more than 3.6 km. 300 meters per microsecond; it is the law... The goal is not to have 12us difference in arrival time, but to be within 12us for transmission time. Why not within 12 psec? Ie, what is the reason for this requirement? And I thought this thread started with 1ms. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On Fri, Apr 25, 2014 at 11:22 PM, William Unruh un...@invalid.ca wrote: I have 8 machines that reliably sync from one GPS PPS driven machine (all using chrony) and they get time reliability of about 10microseconds How do you determine the 10 micosec. value? And why are you conflating NTP performance with Chrony performance? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 2014-04-26, Paul tik-...@bodosom.net wrote: On Fri, Apr 25, 2014 at 11:22 PM, William Unruh un...@invalid.ca wrote: I have 8 machines that reliably sync from one GPS PPS driven machine (all using chrony) and they get time reliability of about 10microseconds How do you determine the 10 micosec. value? Two ways. One is to simply use the offset scatter as an estimate of the time performace (It is at least some sort of upper bound, but as I have said, not terribly accurate) and secondly by hooking a GS PPS to the machine and looking at the offsets on that. And why are you conflating NTP performance with Chrony performance? BEcause they are comparable ( chrony is somthing like 2-3 times better than ntpd, but not 1000 times better). They both use ntp packet exchange to exchange time. ntpd uses a (slow) very simply feedback loop, chrony uses a linear regression, but again the two are comparable. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On Sat, Apr 26, 2014 at 8:30 PM, William Unruh un...@invalid.ca wrote: use the offset scatter as an estimate of the time performace (It is at least some sort of upper bound, but as I have said, not terribly accurate) I suspect you shouting CANNOT is probably overstating the issue. After all if offset was of no value how would NTP (or any other offset based time transfer system) work? To the previous point -- if someone says my offsets are always 10s of microseconds that is likely to be a refutation of the 'NTP can't do better than 10s of milliseconds position. I don't know what terribly accurate might be to you but in the real world sufficient accuracy depends on the circumstance. Someone should conduct an experiment. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 2014-04-27, Paul tik-...@bodosom.net wrote: On Sat, Apr 26, 2014 at 8:30 PM, William Unruh un...@invalid.ca wrote: use the offset scatter as an estimate of the time performace (It is at least some sort of upper bound, but as I have said, not terribly accurate) I suspect you shouting CANNOT is probably overstating the issue. After all if offset was of no value how would NTP (or any other offset based time transfer system) work? To get a good idea of the actual offset from UTC, you need another time source (or two) to compare with each other. The straight offsets do not give it to you. However, I will admit that they are probably an upper bound (although even that is not true-- the link could have assymetric offsets.) To the previous point -- if someone says my offsets are always 10s of microseconds that is likely to be a refutation of the 'NTP can't do better than 10s of milliseconds position. agreed. I don't know what terribly accurate might be to you but in the real world sufficient accuracy depends on the circumstance. Someone should conduct an experiment. I have. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 2014-04-24, Montgomery, Peter BIS peter.montgom...@fs.utc.com wrote: I am new to NTP. But I have a quick question that I need to answer soon. I would like to know whether NTP can sync between a client and a server within 1ms if the client and server are Linux applications on a simple local network ( less than 10 nodes). It can sync to 10 micro (not milli) seconds. Assuming Linux of BSD. For Windows apparently 1ms is more like it. Sincerely, Peter ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
Montgomery, Peter BIS writes: I am new to NTP. But I have a quick question that I need to answer soon. I would like to know whether NTP can sync between a client and a server within 1ms if the client and server are Linux applications on a simple local network ( less than 10 nodes). Yes, in my experience it is pretty easy to keep machines in a LAN sync'd to less than a millisecond. I'm talking about unix machines in general. There is a chance you *might* need to be aware of peculiarities with certain versions of linux kernels. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
Le 25 avr. 2014 à 08:34, William Unruh a écrit : On 2014-04-24, Montgomery, Peter BIS peter.montgom...@fs.utc.com wrote: I am new to NTP. But I have a quick question that I need to answer soon. I would like to know whether NTP can sync between a client and a server within 1ms if the client and server are Linux applications on a simple local network ( less than 10 nodes). It can sync to 10 micro (not milli) seconds. Assuming Linux of BSD. For Windows apparently 1ms is more like it. Hmmm. I have a lightly loaded windows 7 client of a 1PPS disciplined server which only manages around 5ms and it is only 1 switch away. LInux clients do stay sync'd with offsets 1ms. But only when reasonably loaded, or when the network is not saturated. It is quite easy to get into a situation where a 1ms client gets pushed above that. While the answer to CAN is yes, the answer to WILL depends on local factors. If the OP needs to give an answer to a third party, say his boss, he should probably be asking him what the real requirements are first. Sincerely, Peter ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On Thu, Apr 24, 2014 at 8:07 AM, Montgomery, Peter BIS peter.montgom...@fs.utc.com wrote: I am new to NTP. But I have a quick question that I need to answer soon. I would like to know whether NTP can sync between a client and a server within 1ms if the client and server are Linux applications on a simple local network ( less than 10 nodes). Yes, absolutely and easily. It can usually achieve that even over the Internet. Henry ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
Henry Hallam he...@pericynthion.org wrote: On Thu, Apr 24, 2014 at 8:07 AM, Montgomery, Peter BIS peter.montgom...@fs.utc.com wrote: I am new to NTP. But I have a quick question that I need to answer soon. I would like to know whether NTP can sync between a client and a server within 1ms if the client and server are Linux applications on a simple local network ( less than 10 nodes). Yes, absolutely and easily. It can usually achieve that even over the Internet. Henry Of course there is a bit of a difference between usually this will work very well and it better works OK or we will lose millions of dollars. You know, the financial trade markets where they try to rip eachother off by sending transactions across links 1ms shorter then someone else to use prior knowledge. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
I would like to know whether NTP can sync between a client and a server within 1ms if the client and server are Linux applications on a simple local network ( less than 10 nodes). Yes, if simply go by the offset figure in NTP, you can usually get sub-millisecond figures between two machines. If you push your maxpoll down some, like to 6 (64s) or even 4 (16s) then you can keep things nice and tight (this is for LAN traffic only, I wouldn't do that on a remote Internet sever). My local S2 machines typically even have a Root Dispersion under 2ms (usually closer to 1ms). Nothing to complain about there... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 2014-04-25, Rob nom...@example.com wrote: Henry Hallam he...@pericynthion.org wrote: On Thu, Apr 24, 2014 at 8:07 AM, Montgomery, Peter BIS peter.montgom...@fs.utc.com wrote: I am new to NTP. But I have a quick question that I need to answer soon. I would like to know whether NTP can sync between a client and a server within 1ms if the client and server are Linux applications on a simple local network ( less than 10 nodes). Yes, absolutely and easily. It can usually achieve that even over the Internet. Henry Of course there is a bit of a difference between usually this will work very well and it better works OK or we will lose millions of dollars. You know, the financial trade markets where they try to rip eachother off by sending transactions across links 1ms shorter then someone else to use prior knowledge. If you need for accurate time is that great, get a local refclock-- gps receiver, local atomic clock, etc. attached to each of your machines. And even then there is no guarentee (gps goes down due to a war between the USSR and USA, atmonic clock burns out, computer crystal cracks,...) Also do not use Windows. ntpd has a number of mitigation factors against network congestion. The delay filter ( choosing only that offset whose delay is the smallest of the past 8 tries for example, slowly changing the rate due to non-zero offsets, etc) and you CANNOT go by the offsets to see if your clock is off. You have to get in another better time source (eg gps pps) to see how far off your clocks are, precisely because the offsets could be off while the clocks are not due to network congestion which the clock-filter may ignore. If you have network problems such that your network is full 24 hours a day, then clearly a network is not the way to get the clocks synchronized. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On Thu, Apr 24, 2014 at 11:07 AM, Montgomery, Peter BIS peter.montgom...@fs.utc.com wrote: I would like to know whether NTP can sync between a client and a server within 1ms if the client and server are Linux applications on a simple local network ( less than 10 nodes). As previously mentioned it depends. (These machines are all on the same network but the last one is wireless) remote refid st t when poll reach delay offset jitter == -nub .GPPS. 1 u 203 1024 3770.676 -0.084 0.114 +black .GPPS. 1 u 432 1024 3770.345 -0.051 0.066 +aster .GPPS. 1 u 914 1024 3770.354 -0.093 0.083 *ntp1.GPS.1 u 299 1024 3771.248 -0.055 0.120 remote refid st t when poll reach delay offset jitter == +aster .GPPS. 1 u 140 256 3770.383 -2.281 0.679 +ntp1.GPS.1 u 40 256 3771.201 -2.306 0.703 *nub .GPPS. 1 u 211 256 3770.628 -2.457 0.706 +black .GPPS. 1 u 32 256 3770.184 -2.484 0.645 remote refid st t when poll reach delay offset jitter == +black .GPPS. 1 u 897 1024 3771.024 33.284 46.324 -nub .GPPS. 1 u 45 1024 377 18.423 18.726 203.720 *aster .GPPS. 1 u 86 1024 377 43.362 10.866 26.145 +ntp1.GPS.1 u 267 1024 377 25.155 21.369 75.804 For reference the view from one server: remote refid st t when poll reach delay offset jitter == oPPS(0) .GPPS. 0 l48 3770.0000.001 0.002 *GPS_NMEA(0) .FURY. 0 l38 3770.000 -0.041 0.029 time-d.nist.gov .ACTS. 1 u 96 128 375 36.1203.038 1.156 +nub .GPPS. 1 s68 3760.1710.005 0.007 +black .GPPS. 1 s38 3770.0320.016 0.009 +rPi1.GPPS. 1 s18 3770.0830.073 0.059 +ntp1.GPS.1 u3 32 3771.063 -0.115 0.003 +bbb2.GPPS. 1 u68 3770.258 -0.066 0.008 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
In article 8188ba2b01fb534a99c03d79c62ce1d80982f...@uusnwe3a.global.utcmail.com, Montgomery, Peter BIS peter.montgom...@fs.utc.com wrote: I am new to NTP. But I have a quick question that I need to answer soon. I would like to know whether NTP can sync between a client and a server within 1ms if the client and server are Linux applications on a simple local network ( less than 10 nodes). Not reliably, for a million reasons. A better rule is 10 milliseconds, and even that requires work and care. The most reliable approach is an IRIG network. But you need to describe your problem and constraints before people can give better answers. Joe Gwinn ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On 2014-04-26, Joe Gwinn joegw...@comcast.net wrote: In article 8188ba2b01fb534a99c03d79c62ce1d80982f...@uusnwe3a.global.utcmail.com, Montgomery, Peter BIS peter.montgom...@fs.utc.com wrote: I am new to NTP. But I have a quick question that I need to answer soon. I would like to know whether NTP can sync between a client and a server within 1ms if the client and server are Linux applications on a simple local network ( less than 10 nodes). Not reliably, for a million reasons. A better rule is 10 milliseconds, and even that requires work and care. Well, since I have 8 machines that reliably sync from one GPS PPS driven machine (all using chrony) and they get time reliability of about 10microseconds, your experience seems a bit different than mine. And how did you determine that you were only getting 10ms. As I said, you cannot conclude that by looking at the offsets reported by ntpd. The most reliable approach is an IRIG network. Or put a gps pps receiver onto each machine. But you need to describe your problem and constraints before people can give better answers. Agreed. Joe Gwinn ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
