Because people have been trained by marketeers to look for the 'silver bullet' But there are generally only a few methods to accomplish a given task Heck look at the 'cloud' those of us who were using large scale computers in the 80's called it 'timesharing' and the most important app on the PC at the time was a vt100 or 3270 emulator and graphics were done on a Tek vector terminal Content by Scott Typos by Siri > On Aug 4, 2016, at 9:39 PM, Chris Albertson <albertson.chris@gmail.com> wrote: > > I always wonder why people try all kinds of solutions when there are two > known to work as well as theoretically possible. > > There is NTP and PTP. > > NTP was released to the world in 1985, about 30 years ago. The algorithm > has been in peer reviewed papers and the source code gets reviewed > continuously by experts in the field and when one of them finds a problem > solutions are discussed and corrections are made. After 30 years of > continuous review and revision it is close to as good as it will get. > (except for possible security issues in the implementation) There is a > very active community of academics and computer scientists that keep NTP up > to date. Its problem is that it is designed to work over a public > network that the user has no control over so the assumption must be made > that the network equipment has only some minimum features. NTP's accuracy > tops out (with great effort) at about 1 microsecond but typically 1 > millisecond > > PTP on the other hand is designed to do about the same as NTP but over a > local network the user has complete control over and requires specialized > networking equipment. PTP accuracy routinely breaks 1uSec but can't work > so well over a public Internet. > > If these two where not free, easy to set up and well supported then it > might be worth looking for something else. > > From a "Time Nuts" point of view none of the above are even close to > accurate clocks. A microsecond is a very course and crude measure of > time. Pico and Femto seconds are were it gets interesting. > > Maybe someday NTP will have a time nuts level of accuracy. the new up > coming version, I hear will be using 64 bits to carry the factional part of > a second. That is truly nuts. > > Yes, there is room for more software if maybe one needs to transform time > under conditions not covered by NTP or PTP or needs to do much better than > 1uSec. But typically when that happens we resort to hardware solutions > like 1PPS distributions and/or 10MHz distortions or common view of GPS > carriers signals. Packetized network just don't work if you need to be > much better than 1uSec. > >> On Thu, Aug 4, 2016 at 11:47 AM, David <davidwhess@gmail.com> wrote: >> >> The old Tardis program for Windows (Tardis2000 now) handles it >> correctly by altering the rate and only jamming the time if it is >> outside of a specified window but I do not think its GPS mode supports >> the 1 PPS signal. >> >> I am not sure if Tardis works with Windows 7 and above though; I >> forget to test it on my Windows 7 test system when I had it. It is a >> pretty old (but free) program. >> >>> On Tue, 2 Aug 2016 23:28:06 -0700, you wrote: >>> >>> The WRONG way to adjust a PC clock is to set the TIME periodically from >>> some standard. When you do this then the time on the PC is not running at >>> a constant rate. The correct way to do this is to adjust the PC's clocks >>> RATE. You make it runs slightly faster if you notice it is getting behind >>> and slightly slower if it is running fast. >>> >>> Think about what you would do to a real physical clock. You would not set >>> it every few minutes, you'd adjust the rate and wait a little while to see >>> if the adjustment needs refinement or not. >>> >>> ... >>> >>> Most operating systems in use today run NTP to keep their clocks in order. >>> Well most OSes except for Windows. Microsoft uses a vey much simplified >>> version of this that does the wrong thing and periodically sets the PC's >>> clock. You could enable this and likely, maybe reach your +/- 100ms >> goal. >>> Not the "real" NTP is a free program and not hard to set up so you can >>> have 1ms level accuracy without much effort and better with some work. >>> >>>> On Tue, Aug 2, 2016 at 8:13 PM, Ron Ott <ronott@sbcglobal.net> wrote: >>>> >>>> This has probably been covered in the past, but is there a way correct >> or >>>> control a PC (Windows 7) clock with the HP 58503A GPS receiver? I just >>>> bought one (on the way now) and have a copy of satstats50 on hand. I've >>>> been using Dimension 4 and I'm surprised at the size of correction every >>>> couple minutes to my PC clock. I'd be happy if my PC clock were >> accurate >>>> to plus/minus 100ms. >>>> Ron >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/ >> mailman/listinfo/time-nuts >> and follow the instructions there. > > > > -- > > Chris Albertson > Redondo Beach, California > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

Chris, On 08/05/2016 03:39 AM, Chris Albertson wrote: > I always wonder why people try all kinds of solutions when there are two > known to work as well as theoretically possible. > > There is NTP and PTP. > > NTP was released to the world in 1985, about 30 years ago. The algorithm > has been in peer reviewed papers and the source code gets reviewed > continuously by experts in the field and when one of them finds a problem > solutions are discussed and corrections are made. After 30 years of > continuous review and revision it is close to as good as it will get. > (except for possible security issues in the implementation) There is a > very active community of academics and computer scientists that keep NTP up > to date. Its problem is that it is designed to work over a public > network that the user has no control over so the assumption must be made > that the network equipment has only some minimum features. NTP's accuracy > tops out (with great effort) at about 1 microsecond but typically 1 > millisecond With essentially the same messages, but altered rules better performance can most likely be achieved in NTP. I'm not at all convinced that several of the assumptions in NTP is very useful or valid. > PTP on the other hand is designed to do about the same as NTP but over a > local network the user has complete control over and requires specialized > networking equipment. PTP accuracy routinely breaks 1uSec but can't work > so well over a public Internet. > > If these two where not free, easy to set up and well supported then it > might be worth looking for something else. It is worth looking for something else, because each have their technological and practical limits. > From a "Time Nuts" point of view none of the above are even close to > accurate clocks. A microsecond is a very course and crude measure of > time. Pico and Femto seconds are were it gets interesting. Certainly. Look at White Rabbit, which really changes how PTP works. It may not be pico second accurate, but you get pretty far with it. > Maybe someday NTP will have a time nuts level of accuracy. the new up > coming version, I hear will be using 64 bits to carry the factional part of > a second. That is truly nuts. Well, if NTP takes the main ideas from PTP and White Rabbit, maybe then. PTP adds hardware time-stamping and attempts to compensate one-way delays that otherwise eats precision for breakfast. White rabbit attempts much higher resolution while doing it, adding high resolution measures and Synchronous Ethernet into the mix, letting PTP be relatively time-insensitive message vehicle. > Yes, there is room for more software if maybe one needs to transform time > under conditions not covered by NTP or PTP or needs to do much better than > 1uSec. But typically when that happens we resort to hardware solutions > like 1PPS distributions and/or 10MHz distortions or common view of GPS > carriers signals. Packetized network just don't work if you need to be > much better than 1uSec. Slowly pushing down there, but there is a lot of things to care about, and tradition to break with. NTP might work nicely for you, PTP might help you too, but you can do better in several regards. There is work to be done, and there is other systems out there already. Cheers, Magnus > On Thu, Aug 4, 2016 at 11:47 AM, David <davidwhess@gmail.com> wrote: > >> The old Tardis program for Windows (Tardis2000 now) handles it >> correctly by altering the rate and only jamming the time if it is >> outside of a specified window but I do not think its GPS mode supports >> the 1 PPS signal. >> >> I am not sure if Tardis works with Windows 7 and above though; I >> forget to test it on my Windows 7 test system when I had it. It is a >> pretty old (but free) program. >> >> On Tue, 2 Aug 2016 23:28:06 -0700, you wrote: >> >>> The WRONG way to adjust a PC clock is to set the TIME periodically from >>> some standard. When you do this then the time on the PC is not running at >>> a constant rate. The correct way to do this is to adjust the PC's clocks >>> RATE. You make it runs slightly faster if you notice it is getting behind >>> and slightly slower if it is running fast. >>> >>> Think about what you would do to a real physical clock. You would not set >>> it every few minutes, you'd adjust the rate and wait a little while to see >>> if the adjustment needs refinement or not. >>> >>> ... >>> >>> Most operating systems in use today run NTP to keep their clocks in order. >>> Well most OSes except for Windows. Microsoft uses a vey much simplified >>> version of this that does the wrong thing and periodically sets the PC's >>> clock. You could enable this and likely, maybe reach your +/- 100ms >> goal. >>> Not the "real" NTP is a free program and not hard to set up so you can >>> have 1ms level accuracy without much effort and better with some work. >>> >>> On Tue, Aug 2, 2016 at 8:13 PM, Ron Ott <ronott@sbcglobal.net> wrote: >>> >>>> This has probably been covered in the past, but is there a way correct >> or >>>> control a PC (Windows 7) clock with the HP 58503A GPS receiver? I just >>>> bought one (on the way now) and have a copy of satstats50 on hand. I've >>>> been using Dimension 4 and I'm surprised at the size of correction every >>>> couple minutes to my PC clock. I'd be happy if my PC clock were >> accurate >>>> to plus/minus 100ms. >>>> Ron >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/ >> mailman/listinfo/time-nuts >> and follow the instructions there. >> > > >

		Attila Kinali

On Fri, 5 Aug 2016 21:35:05 +0200 Magnus Danielson <magnus@rubidium.dyndns.org> wrote: > > From a "Time Nuts" point of view none of the above are even close to > > accurate clocks. A microsecond is a very course and crude measure of > > time. Pico and Femto seconds are were it gets interesting. > > Certainly. Look at White Rabbit, which really changes how PTP works. > It may not be pico second accurate, but you get pretty far with it. WR achieves sub-ns accuracy. Depending on the environment <200ps offset/skew are possible. > > Maybe someday NTP will have a time nuts level of accuracy. the new up > > coming version, I hear will be using 64 bits to carry the factional part of > > a second. That is truly nuts. > > Well, if NTP takes the main ideas from PTP and White Rabbit, maybe then. This wont help. The achievable accuracy is dictated by the measurement and the delay uncertainty. Even with network cards that support time stamping, you cannot hope to get better than 1/125MHz=8ns. Standard network cards will just trigger an IRQ at some point after reception and enqueuing of the packet. The IRQ is measured by the OS, which leads to uncertainties in the order of several us to a couple of 10s of us. If the card does DMA the packet directly into main memory, then this value is even more inflated. The network itself has a relatively high jitter. Assume 10s to 100s of us on a local network per switch. Once you pass a router, you can assume jitter in the order of a couple of 100us to a couple of ms per router. To illustrate this, here a few ping statistics (64byte, 1000 packets each): Local network, GBit/s, two level1 smart switches: rtt min/avg/max/mdev = 0.073/0.131/0.362/0.044 ms Two hosts in colo centers within the same city, same ISP, hence on the same "network" (ie no conguestion), 4 hops: rtt min/avg/max/mdev = 0.288/0.437/0.620/0.051 ms Two hosts in colo centers, within the same city, different ISP but with direct peering (ie no conguestion), 9 hops: rtt min/avg/max/mdev = 2.916/3.008/3.505/0.078 ms Two hosts in colo centers, one in Switzerland, one in Germany, 9 hops rtt min/avg/max/mdev = 12.636/12.947/28.943/0.609 ms These are all well connected machines, with "carrier grade" networks inbetween. No consumer internet connections with their huge delays and jitter. So, best you can hope for is an jitter of ~50us rms within the same city with _good_ network connections. Once the distance increases and especially if you get routers with conquestion inbetween, then the delay and its jitter rise quickly. Attila Kinali -- Malek's Law: Any simple idea will be worded in the most complicated way.

On 08/05/2016 01:41 PM, Attila Kinali wrote: > Standard network cards will just trigger an IRQ at some point after > reception and enqueuing of the packet. Perhaps drifting a bit... In the broadest of handwaving terms, prior to Gigabit Ethernet, NICs (Ethernet anyway) would post an interrupt for each arriving frame. In the 100 Mbit/s Ethernet cards, (and perhaps FDDI and others) they started avoiding transmit completion interrupts. With gigabit Ethernet, they started avoiding receive interrupts through interrupt coalescing settings. Different NICs did/do it differently, and some better than others. Under Linux at least, one can use the ethtool utility to tweak or even disable interrupt coalescing. That would likely be Just Fine (tm) for a system dedicated to timekeeping, but the performance effects on "normal" networking might be more than one desired. With 10 Gigabit NICs, multiple receive queues come into play (again, handwaving a bit). I would think that some of the later ones would be sophisticated enough to enable sending NTP traffic through a specific queue/IRQ but I don't know of any 10 GbE NICs with per-queue coalescing settings. My experience with 10 Gbit/s NICs and the likes of say a netperf TCP_RR test has been that except perhaps for the worst of them, they will not arbitrarily delay a packet arriving at an "idle" time. What *will* be a non-trivial bummer for such things as a netperf TCP_RR test (think ping without "think time") will be power management in the processor(s). Perhaps not visible in a MAN/WAN test setup, but certainly visible in a LAN one. rick jones

Hi Ok, here I am at home. My network gear is simple. Cisco low end switches and Gig-E wires. No fancy Sync-E. No 1588 stamps from the switches. Data comes in via a cable modem. The beast has highly asymmetric send and receive transit times. They both wander around in response to their own gods. These limits are not at all unusual. In fact, the Gig-E probably is more stable than the WiFi that some people now consider to be the standard approach to home networking. My cable modem is not at all unusual in it’s design or performance. There are a *lot* of businesses out there with worse issues than what I have here. If I call up my cable guy and ask about Sync-E or 1588 stamps they actually are smart enough (or Bob’s calls get routed specifically …) to tell me I’m nuts and carefully explain why. The unusual part there is the care rather than me being nuts to ask for that sort of stuff on my external connection. This all pretty quickly gets one back to an NTP-like approach. All of the “cool new stuff” in hardware isn’t going to do me much good. I go looking for 1588 gear and my switch budget starts to look like the price of a nice new BMW. That isn’t going to happen (the switches or the BMW). Someday maybe 1588 will become “normal”. That hasn’t happened yet. The early predictions of it being universal in the next generation of switches died several generations ago. In terms of the question “how do I keep my PC at the right time?” …. the solutions are all pretty basic due to the lack of fancy network time transfer support. Bob > On Aug 5, 2016, at 3:35 PM, Magnus Danielson <magnus@rubidium.dyndns.org> wrote: > > Chris, > > On 08/05/2016 03:39 AM, Chris Albertson wrote: >> I always wonder why people try all kinds of solutions when there are two >> known to work as well as theoretically possible. >> >> There is NTP and PTP. >> >> NTP was released to the world in 1985, about 30 years ago. The algorithm >> has been in peer reviewed papers and the source code gets reviewed >> continuously by experts in the field and when one of them finds a problem >> solutions are discussed and corrections are made. After 30 years of >> continuous review and revision it is close to as good as it will get. >> (except for possible security issues in the implementation) There is a >> very active community of academics and computer scientists that keep NTP up >> to date. Its problem is that it is designed to work over a public >> network that the user has no control over so the assumption must be made >> that the network equipment has only some minimum features. NTP's accuracy >> tops out (with great effort) at about 1 microsecond but typically 1 >> millisecond > > With essentially the same messages, but altered rules better performance can most likely be achieved in NTP. I'm not at all convinced that several of the assumptions in NTP is very useful or valid. > >> PTP on the other hand is designed to do about the same as NTP but over a >> local network the user has complete control over and requires specialized >> networking equipment. PTP accuracy routinely breaks 1uSec but can't work >> so well over a public Internet. >> >> If these two where not free, easy to set up and well supported then it >> might be worth looking for something else. > > It is worth looking for something else, because each have their technological and practical limits. > >> From a "Time Nuts" point of view none of the above are even close to >> accurate clocks. A microsecond is a very course and crude measure of >> time. Pico and Femto seconds are were it gets interesting. > > Certainly. Look at White Rabbit, which really changes how PTP works. > It may not be pico second accurate, but you get pretty far with it. > >> Maybe someday NTP will have a time nuts level of accuracy. the new up >> coming version, I hear will be using 64 bits to carry the factional part of >> a second. That is truly nuts. > > Well, if NTP takes the main ideas from PTP and White Rabbit, maybe then. > > PTP adds hardware time-stamping and attempts to compensate one-way delays that otherwise eats precision for breakfast. > > White rabbit attempts much higher resolution while doing it, adding high resolution measures and Synchronous Ethernet into the mix, letting PTP be relatively time-insensitive message vehicle. > >> Yes, there is room for more software if maybe one needs to transform time >> under conditions not covered by NTP or PTP or needs to do much better than >> 1uSec. But typically when that happens we resort to hardware solutions >> like 1PPS distributions and/or 10MHz distortions or common view of GPS >> carriers signals. Packetized network just don't work if you need to be >> much better than 1uSec. > > Slowly pushing down there, but there is a lot of things to care about, and tradition to break with. > > NTP might work nicely for you, PTP might help you too, but you can do better in several regards. There is work to be done, and there is other systems out there already. > > Cheers, > Magnus > >> On Thu, Aug 4, 2016 at 11:47 AM, David <davidwhess@gmail.com> wrote: >> >>> The old Tardis program for Windows (Tardis2000 now) handles it >>> correctly by altering the rate and only jamming the time if it is >>> outside of a specified window but I do not think its GPS mode supports >>> the 1 PPS signal. >>> >>> I am not sure if Tardis works with Windows 7 and above though; I >>> forget to test it on my Windows 7 test system when I had it. It is a >>> pretty old (but free) program. >>> >>> On Tue, 2 Aug 2016 23:28:06 -0700, you wrote: >>> >>>> The WRONG way to adjust a PC clock is to set the TIME periodically from >>>> some standard. When you do this then the time on the PC is not running at >>>> a constant rate. The correct way to do this is to adjust the PC's clocks >>>> RATE. You make it runs slightly faster if you notice it is getting behind >>>> and slightly slower if it is running fast. >>>> >>>> Think about what you would do to a real physical clock. You would not set >>>> it every few minutes, you'd adjust the rate and wait a little while to see >>>> if the adjustment needs refinement or not. >>>> >>>> ... >>>> >>>> Most operating systems in use today run NTP to keep their clocks in order. >>>> Well most OSes except for Windows. Microsoft uses a vey much simplified >>>> version of this that does the wrong thing and periodically sets the PC's >>>> clock. You could enable this and likely, maybe reach your +/- 100ms >>> goal. >>>> Not the "real" NTP is a free program and not hard to set up so you can >>>> have 1ms level accuracy without much effort and better with some work. >>>> >>>> On Tue, Aug 2, 2016 at 8:13 PM, Ron Ott <ronott@sbcglobal.net> wrote: >>>> >>>>> This has probably been covered in the past, but is there a way correct >>> or >>>>> control a PC (Windows 7) clock with the HP 58503A GPS receiver? I just >>>>> bought one (on the way now) and have a copy of satstats50 on hand. I've >>>>> been using Dimension 4 and I'm surprised at the size of correction every >>>>> couple minutes to my PC clock. I'd be happy if my PC clock were >>> accurate >>>>> to plus/minus 100ms. >>>>> Ron >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts@febo.com >>> To unsubscribe, go to https://www.febo.com/cgi-bin/ >>> mailman/listinfo/time-nuts >>> and follow the instructions there. >>> >> >> >> > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

                     Attila Kinali

On Sat, Aug 6, 2016 at 6:41 AM, Attila Kinali <attila@kinali.ch> wrote: > So, best you can hope for is an jitter of ~50us rms within the same > city with _good_ network connections. Once the distance increases > and especially if you get routers with conquestion inbetween, then > the delay and its jitter rise quickly. That pretty well agrees with my practical experience of NTP on somewhat longer, uncongested links. NTP servers separated physically by 1000-3000 km but perhaps 10 network hops had apparent offsets of about 100 us rms with respect to each other. Cheers Michael On Sat, Aug 6, 2016 at 6:41 AM, Attila Kinali <attila@kinali.ch> wrote: > On Fri, 5 Aug 2016 21:35:05 +0200 > Magnus Danielson <magnus@rubidium.dyndns.org> wrote: > >> > From a "Time Nuts" point of view none of the above are even close to >> > accurate clocks. A microsecond is a very course and crude measure of >> > time. Pico and Femto seconds are were it gets interesting. >> >> Certainly. Look at White Rabbit, which really changes how PTP works. >> It may not be pico second accurate, but you get pretty far with it. > > WR achieves sub-ns accuracy. Depending on the environment <200ps offset/skew > are possible. > >> > Maybe someday NTP will have a time nuts level of accuracy. the new up >> > coming version, I hear will be using 64 bits to carry the factional part of >> > a second. That is truly nuts. >> >> Well, if NTP takes the main ideas from PTP and White Rabbit, maybe then. > > This wont help. The achievable accuracy is dictated by the measurement > and the delay uncertainty. Even with network cards that support time stamping, > you cannot hope to get better than 1/125MHz=8ns. Standard network cards > will just trigger an IRQ at some point after reception and enqueuing of > the packet. The IRQ is measured by the OS, which leads to uncertainties > in the order of several us to a couple of 10s of us. If the card does DMA > the packet directly into main memory, then this value is even more inflated. > > The network itself has a relatively high jitter. Assume 10s to 100s of us > on a local network per switch. Once you pass a router, you can assume > jitter in the order of a couple of 100us to a couple of ms per router. > > To illustrate this, here a few ping statistics (64byte, 1000 packets each): > > Local network, GBit/s, two level1 smart switches: > rtt min/avg/max/mdev = 0.073/0.131/0.362/0.044 ms > > Two hosts in colo centers within the same city, same ISP, hence > on the same "network" (ie no conguestion), 4 hops: > rtt min/avg/max/mdev = 0.288/0.437/0.620/0.051 ms > > Two hosts in colo centers, within the same city, different ISP > but with direct peering (ie no conguestion), 9 hops: > rtt min/avg/max/mdev = 2.916/3.008/3.505/0.078 ms > > Two hosts in colo centers, one in Switzerland, one in Germany, 9 hops > rtt min/avg/max/mdev = 12.636/12.947/28.943/0.609 ms > > These are all well connected machines, with "carrier grade" networks > inbetween. No consumer internet connections with their huge delays > and jitter. > > So, best you can hope for is an jitter of ~50us rms within the same > city with _good_ network connections. Once the distance increases > and especially if you get routers with conquestion inbetween, then > the delay and its jitter rise quickly. > > > Attila Kinali > > -- > Malek's Law: > Any simple idea will be worded in the most complicated way. > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.