Re: Residential VSAT experiences?
On Tue, Jun 23, 2015 at 9:37 AM, Rafael Possamai raf...@gav.ufsc.br wrote: Reading about SIP made it seem like latency alone is not an issue, aside from delays which impact verbal communication as previously mentioned. What is going to be much worse is jitter and packet loss. You can eventually get used to a significant delay, but dropped calls and chopped sound renders the service useless. With modern software implementing a responsive jitter buffer, jitter shouldn't be much of a problem. Practical effect would be a longer delay as the receiver buffers enough packets to deal with the measured variance in receipt times. Perhaps a few chops early in the conversation as the software grows the buffer. Not all SIP implementations are equal. Try yours in a high-jitter environment and see what happens. High packet loss is deadly. That'll depend on the satellite vendor's network implementation, the weather, etc. But then high packet loss is deadly to essentially all IP networking activity. In situations where a high bit error rate (BER) is endemic, the layer-2 vendor is expected to redress that with forward error correction (FEC) and retransmission that trades jitter for loss. I have no idea which satellite vendors are better or worse about this. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/
Re: Residential VSAT experiences?
On 23 Jun 2015, at 3:39, Nicholas Oas wrote: What are your experiences with the following applications? -SSH, (specifically interactive CLI shell access) -RDP -SIP over SSL -IPSec Tunneling (should be a non-starter due to latency) -GRE Tunneling Latency, latency, latency, RTTs, RTTs, RTTs. Not an option for anything interactive, very poor for general user-type Internet access. --- Roland Dobbins rdobb...@arbor.net
Re: REMINDER: LEAP SECOND
On Jun 22, 2015, at 7:06 PM, Harlan Stenn st...@ntp.org wrote: Time going backwards is deadly to a number of applications. But apparently not to applications you care about. Oh it is a problem, and most handle it very ungracefully, such as dovecot which just dies: http://wiki.dovecot.org/TimeMovedBackwards The issue is also most people are used to using rc.local or rc.* type scripts to spawn a daemon which leads to the next major sysadmin/developer problem with is handling error cases improperly or not at all. (86401 is perhaps and error case that people should test for). - Jared
Re: Residential VSAT experiences?
On Mon, Jun 22, 2015 at 09:11:17PM -0400, TR Shaw wrote: I don’t know what your location is but a wireless internet provider using Canopy or Ubiquity or whatever is much more preferable. Also cellular is used in “remote” locations with good results. Using the UBNT gear if you can put together a link is really what you want to do. The equipment is cheap as in disposable and if you install it properly you should have almost no issues even with adverse weather. Even using something like the NSM5 back to back and constructing a multi-link path will end up producing nice results. Make sure you have clear line of sight and plan for any tree growth along the route. I've been using a WISP that has the UBNT gear for years now with no outages attributed to the equipment. I have used SSH from a transatlantic flight but the delay can weigh on you ;-) I did as well this last time on my way to europe and it worked better than I expected. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Thanks aws / gcc / azure
Since you have failed to achieve in the modest task that was your charge You now get this https://www.markshuttleworth.com/archives/1471 Or s/money/addresses/ http://youtu.be/pA8f-Nh5gRs
Re: Thanks aws / gcc / azure
On Jun 23, 2015, at 9:01 AM, Ca By cb.li...@gmail.com wrote: Since you have failed to achieve in the modest task that was your charge You now get this https://www.markshuttleworth.com/archives/1471 Or s/money/addresses/ http://youtu.be/pA8f-Nh5gRs Cameron, I share your disappointment that IPv6 isn’t available and has kept me away from these platforms for my activities. Using the 240/4 net can be useful but misses the point for many cases. I will say what kinky things people do in their own private networks I am less concerned about, but when it prevents proper IPv6 from occurring, that is a problem. - Jared
Re: Residential VSAT experiences?
Reading about SIP made it seem like latency alone is not an issue, aside from delays which impact verbal communication as previously mentioned. What is going to be much worse is jitter and packet loss. You can eventually get used to a significant delay, but dropped calls and chopped sound renders the service useless. On Tue, Jun 23, 2015 at 3:44 AM, Tim Franklin t...@pelican.org wrote: Interesting that you say that about sip. We had a client that would use it for sip on ships all the time. It wasn't the best but it worked. Ping times were between 500-700ms. It really depends on your expectations - or more to the point, your end-users' expectations. I've tested SIP in the lab up to 2000ms RTT. The protocols all hang together and keep working, but it's obviously very much in walkie-talkie mode, you can't hold a normal duplex conversation. 500ms there's more of the talking over each other / sorry, you go / no, you go dance, but it *is* workable. If your end-user is expecting land-line replacement though... Regards, Tim.
Re: Residential VSAT experiences?
On Mon, Jun 22, 2015 at 10:39 PM, Nicholas Oas nicholas@gmail.com wrote: Would anyone mind sharing with me their first-hand experiences with residential satellite internet? Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm thinking specifically as a sysadmin who needs to use the uplink for work, not surf. What are your experiences with the following applications? -SSH, (specifically interactive CLI shell access) -RDP -SIP over SSL -IPSec Tunneling (should be a non-starter due to latency) -GRE Tunneling Working for an satellite ISP I can give you some technical background. We're only target enterprise/government/military customers with more specific use cases because offering satellite based Internet to residential customers without making them angry while being profitable is hard. So I've no experience with HughesNet Gen4 or ViaSat Exede as products in particular but I know the underling platforms. In general the systems are optimized for fast browsing and VoIP from the own operator. The modems you'll use with the mentioned services will include all kinds of acceleration features. General acceleration of TCP sessions to work around TCP implementation issues in combination the the high RTT (slow start, behavior during packet loss/high jitter, window scaling, ...) are standard for these services. The residential services usually use additional acceleration features like HTTP prefetching/pushing. That's usually done using a transparent HTTP proxy which sits at the teleport analyzing all HTTP requests/responses, download images etc. already before they are actually requested the the end users browser. They are then pushed to the modem which will delivery them as soon as the end user requests them. As a result the end user doesn't have to wait another RTT for the images etc.. Similar sniffing/spoofing acceleration options are available for other protocols. But with end to end encryption becoming more common these days all these transparent higher level acceleration features of the modems, etc. no longer work. Of course you still can do the same but you have to move the acceleration to the client device. That's not very common yet in the satellite industry. Regarding phone conversations our experience is that the high RTT is not that much of an problem in practice. People recognize the delay and wait longer before starting to talk automatically. But the experience might vary extremely depending on the operators config and end devices. You need corresponding QoS settings to keep latency/jitter low and stable. For residential services the return channel will be most likely time division multiplexed. Once the network is congested (=profitable for the operator) you'll see the latency go beyond 1 second more or less often without proper QoS settings. That of course will completely break your VoIP experience. You should expect that the operator only has corresponding QoS settings for their own VoIP service in place. Experience with third party services might suck due to that. Another issue you might run into are some VoIP phones. Some of them only support very small jitter buffers (10ms) which might cause problems. IPsec tunneling, GRE tunneling etc. should work perfectly fine unless it's intentionally filtered. But as soon as you do tunneling/encryption you should expect that you byepass any acceleration feature or high priority QoS rule. Besides that both products you mentioned AFAIK are using Ka-Band spot beam satellites. There's probably roughly one beam per US state. Assuming 200 MHz per beam that translate to roughly to a maximum of 600-700 Mbit/s downstream capacity shared by all customers in that beam (one state). Upstream is probably designed for half of that. This grouping of customers also makes a simple experience comparison difficult as your experience will heavily depend on the congestion level in your beam. From other similar services we already know that at the launch new customers are happy (always getting the maximum speed) but as the network fills up they get angry due to bad performance during peak times. I really wouldn't recommend a sysadmin to use a geo stationary satellite based connection for your daily work unless there's no other way - simply due to the latency. You'll notice a significant productivity impact. Best Regards, Frederik Kriewitz
Re: RES: REMINDER: LEAP SECOND
If you don’t have NTP enabled your clock may be wrong so it likely won’t impact you. I’ve always had trouble getting NTP to work right over the years for a variety of reasons. Just set something in cron to ntpdate -u your host on july 1st and you should be good. - Jared On Jun 23, 2015, at 9:14 AM, Leonardo Oliveira Ortiz leonardo.or...@marisolsa.com wrote: Guys, if we don't have NTP enable on our Linux we still have problem with leap second ?? -Mensagem original- De: NANOG [mailto:nanog-boun...@nanog.org] Em nome de Jared Mauch Enviada em: terça-feira, 23 de junho de 2015 10:08 Para: Harlan Stenn Cc: nanog@nanog.org Assunto: Re: REMINDER: LEAP SECOND On Jun 22, 2015, at 7:06 PM, Harlan Stenn st...@ntp.org wrote: Time going backwards is deadly to a number of applications. But apparently not to applications you care about. Oh it is a problem, and most handle it very ungracefully, such as dovecot which just dies: http://wiki.dovecot.org/TimeMovedBackwards The issue is also most people are used to using rc.local or rc.* type scripts to spawn a daemon which leads to the next major sysadmin/developer problem with is handling error cases improperly or not at all. (86401 is perhaps and error case that people should test for). - Jared
Re: REMINDER: LEAP SECOND
On Jun 23, 2015, at 1:23 PM, shawn wilson ag4ve...@gmail.com wrote: NTP causes jumps - not skews, right? ntpdate jumps, ntpd will try to make small adjustments within a range unless -x is specified. Many operating systems have -x as a default. - Jared
RES: REMINDER: LEAP SECOND
Guys, if we don't have NTP enable on our Linux we still have problem with leap second ?? -Mensagem original- De: NANOG [mailto:nanog-boun...@nanog.org] Em nome de Jared Mauch Enviada em: terça-feira, 23 de junho de 2015 10:08 Para: Harlan Stenn Cc: nanog@nanog.org Assunto: Re: REMINDER: LEAP SECOND On Jun 22, 2015, at 7:06 PM, Harlan Stenn st...@ntp.org wrote: Time going backwards is deadly to a number of applications. But apparently not to applications you care about. Oh it is a problem, and most handle it very ungracefully, such as dovecot which just dies: http://wiki.dovecot.org/TimeMovedBackwards The issue is also most people are used to using rc.local or rc.* type scripts to spawn a daemon which leads to the next major sysadmin/developer problem with is handling error cases improperly or not at all. (86401 is perhaps and error case that people should test for). - Jared
RE: NANOG Digest, Vol 89, Issue 24
Not to inject more confusion - but GPS and NTP are noted in the thread... but not PTP (IEEE1588)? alex hardie | +1 404 229 7635 | www.nominum.com -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of nanog-requ...@nanog.org Sent: Tuesday, June 23, 2015 8:00 AM To: nanog@nanog.org Subject: NANOG Digest, Vol 89, Issue 24 Send NANOG mailing list submissions to nanog@nanog.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-requ...@nanog.org You can reach the person managing the list at nanog-ow...@nanog.org When replying, please edit your Subject line so it is more specific than Re: Contents of NANOG digest... Today's Topics: 1. Re: REMINDER: LEAP SECOND (Tony Finch) 2. Re: REMINDER: LEAP SECOND (Stephane Bortzmeyer) 3. Re: REMINDER: LEAP SECOND (Bjoern A. Zeeb) 4. Re: REMINDER: LEAP SECOND (Stephane Bortzmeyer) 5. Re: REMINDER: LEAP SECOND (Tony Finch) 6. Re: REMINDER: LEAP SECOND (Alan Buxey) 7. Re: REMINDER: LEAP SECOND (Saku Ytti) 8. Re: REMINDER: LEAP SECOND (Randy Bush) 9. Re: REMINDER: LEAP SECOND (shawn wilson) 10. Re: REMINDER: LEAP SECOND (Tony Finch) 11. Re: Data Center Network Monitoring with TAPs (Rafael Possamai) 12. Re: REMINDER: LEAP SECOND (Harlan Stenn) 13. Facebook contact, images issues in IL/WI (David Sovereen) 14. Re: REMINDER: LEAP SECOND (Marshall Eubanks) 15. Residential VSAT experiences? (Nicholas Oas) 16. Core alignment fusion splicers (Peter Kranz) 17. Re: Core alignment fusion splicers (Mel Beckman) 18. AW: Core alignment fusion splicers (J?rgen Jaritsch) 19. Re: Residential VSAT experiences? (William Herrin) 20. Re: REMINDER: LEAP SECOND (Doug Barton) 21. Re: Residential VSAT experiences? (Mike Lyon) 22. Re: Residential VSAT experiences? (Fred Baker (fred)) 23. Re: Residential VSAT experiences? (Dovid Bender) 24. Re: Residential VSAT experiences? (Mike Lyon) 25. Re: Residential VSAT experiences? (Hugo Slabbert) 26. Re: REMINDER: LEAP SECOND (Harlan Stenn) 27. Re: Residential VSAT experiences? (Mike Hale) 28. Re: Residential VSAT experiences? (Michael Conlen) 29. Re: Residential VSAT experiences? (Scott Weeks) 30. Fwd: Residential VSAT experiences? (Alfred Olton) 31. Re: Residential VSAT experiences? (Lyndon Nerenberg) 32. Re: Residential VSAT experiences? (TR Shaw) 33. Re: Residential VSAT experiences? (Dave Crocker) 34. Re: Residential VSAT experiences? (Mikael Abrahamsson) 35. Re: Residential VSAT experiences? (Dave Taht) 36. Re: REMINDER: LEAP SECOND (Mel Beckman) 37. Re: REMINDER: LEAP SECOND (Harlan Stenn) 38. Re: Residential VSAT experiences? (Tim Franklin) 39. Re: REMINDER: LEAP SECOND (Mel Beckman) 40. Re: REMINDER: LEAP SECOND (Nick Hilliard) -- Message: 1 Date: Mon, 22 Jun 2015 13:15:41 +0100 From: Tony Finch d...@dotat.at To: Harlan Stenn st...@ntp.org Cc: Saku Ytti s...@ytti.fi, nanog@nanog.org Subject: Re: REMINDER: LEAP SECOND Message-ID: alpine.lsu.2.00.1506221312330.3...@hermes-1.csi.cam.ac.uk Content-Type: TEXT/PLAIN; charset=US-ASCII Harlan Stenn st...@ntp.org wrote: It's a problem with POSIX, not UTC. UTC is monotonic. The problems are that UTC is unpredictable, and it breaks the standard labelling of points in time that was used for hundreds (arguably thousands) of years before 1972. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Irish Sea: Northwesterly 4 or 5, occasionally 6 at first, becoming variable 4. Slight or moderate. Mainly fair. Good. -- Message: 2 Date: Mon, 22 Jun 2015 14:27:18 +0200 From: Stephane Bortzmeyer bortzme...@nic.fr To: Tony Finch d...@dotat.at Cc: Harlan Stenn st...@ntp.org, nanog@nanog.org Subject: Re: REMINDER: LEAP SECOND Message-ID: 20150622122718.ga10...@nic.fr Content-Type: text/plain; charset=us-ascii On Mon, Jun 22, 2015 at 01:15:41PM +0100, Tony Finch d...@dotat.at wrote a message of 15 lines which said: The problems are that UTC is unpredictable, That's because the earth rotation is unpredictable. Any time based on this buggy planet's movements will be unpredictable. Let's patch it now! -- Message: 3 Date: Mon, 22 Jun 2015 12:38:28 + From: Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net To: Stephane Bortzmeyer bortzme...@nic.fr Cc: Tony Finch d...@dotat.at, nanog@nanog.org Subject: Re: REMINDER: LEAP SECOND Message-ID: 8c40413b-b22c-4bce-85d2-b4f93a233...@lists.zabbadoz.net Content-Type: text/plain; charset=us-ascii On 22 Jun 2015, at 12:27 , Stephane Bortzmeyer bortzme...@nic.fr wrote: On Mon, Jun 22, 2015 at 01:15:41PM +0100, Tony Finch d...@dotat.at wrote a message of 15 lines which said: The problems are that UTC is unpredictable, That's because the
Re: REMINDER: LEAP SECOND
On Jun 23, 2015 6:26 AM, Nick Hilliard n...@foobar.org wrote: Blocking NTP at the NTP edge will probably work fine for most situations. Bear in mind that your NTP edge is not necessarily the same as your network edge. E.g. you might have internal GPS / radio sources which could unexpectedly inject the leap second. The larger the network, the more likely this is to happen. Most organisations have network fossils and ntp is an excellent source of these. I.e. systems which work away for years without any problems before one day accidentally triggering meltdown because some developer didn't understand the subtleties of clock monotonicity. NTP causes jumps - not skews, right?
Re: REMINDER: LEAP SECOND
On 23/06/2015 18:23, shawn wilson wrote: NTP causes jumps - not skews, right? this is implementation dependent. For normal clock differences on ntpd, if you start it with the -x parameter, it will always slew and never step. If you start ntpd without the -x parameter, if the calculated correct time after slewing is out by 128ms relative to other ntp servers, then after 900 seconds, it will step to the correct time. However in the case of leap seconds, if the operating system implements ntp kernel discipline, then the ntp server will immediately step by the leap second (forwards or backwards), as soon as it receives the leap second notification. It does this on the basis that the kernel supports leap seconds, therefore it's probably the right thing to do. Nick
Re: REMINDER: LEAP SECOND
Matthew Huff writes: A backward step is a known issue and something that people are more comfortable dealing with as it can happen on any machine with a noisy clock crystal. A clock crystal has to be REALLY bad for ntpd to need to step the clock. Having 61 seconds in a minute or 86401 seconds in a day is a different story. Yeah, leap years suck too. And those jumps around daylight savings time. H
Re: REMINDER: LEAP SECOND
Harlan, Why should your head explode? Possibly you’re overthinking the problem. And there is no reason (or simple way I can envision) to test my plan, as you advise, in advance. I will just block NTP in my border router temporarily. No need to make a mountain out of this molehill. Cisco, and many other NTP client gear vendors, recommend this approach, and they’ve published extensive research on the matter. -mel On Jun 23, 2015, at 12:46 AM, Harlan Stenn st...@ntp.org wrote: This stuff can make my head explode. When a leap second is added, like on 30 June 2015 at the last second of the day, POSIX insists that the day still have 86400 seconds in it. This makes the day longer by one second, so time has to either slow down or move backwards. The dumb way to do this is to step the clock back by 1 second at the instant before the stroke of midnight. The allegedly better way to do this would be to stop the clock a bit before midnight, and hold the time for 1 second. To continue providing monotonic time, every time somebody says what time is it during that holding period one would want to bump the time by the smallest amount possible, usually 1 nanosecond (assuming the kernel keeps time in nanoseconds). Ideally you wouldn't want to add enough nanoseconds to cause the clock to roll over into the next day too early. But apparently nobody has implemented this, even though Prof. Mills described it in RFC-i-forget about 20 years ago. This is mostly because POSIX deals with absolute time and not relative time. In the unlikely event of a leap second deletion, there would be no 23:59:59, so when the clock is about to strike 23:59:59 it's OK to add an extra second to the clock to effectively have the time jump from 23:59:58 to 00:00:00. This is still a monotonic increment in time. Whatever you decide to do, I recommend you actually test it out to see if it behaves the way you think it will. You have a whole week still. H
Re: REMINDER: LEAP SECOND
Harlan, Help me understand why there is a serious risk of going back in time. I acknowledge that there is a remote chance of a backstep, but the probability seems very low. Suppose I disable my NTP service five minutes before a positive leap second occurs, so that no server in my network can query it. These servers will then run on their own internal clocks. Then, five minutes after the leap second, I re-engage NTP. Assuming a high degree of local oscillator fidelity, imagine the clock drift is zero. The result is that NTP will report one second older than the time currently in my server, i.e. exactly five minutes after the 23:59:60 leap second. Thus even systems, such as Unix, where 23:59:60 does not exist in the UTC implementation, the timestamp the server sees from NTP is not the potentially code-crashing 23:59:60, but a perfectly rational 00:05:01. This is what my server’s NTP client compares with its internal clock of 00:04:59. NTP's target time is in the future, so there is no risk of going back in time. NTP gradually increments the local time to converge on NTP’s time. In the alternative case of a negative leap second, following the NTP clock discipline algorithm, the NTP client amortizes the one-second reverse jump, specifically in order to avoid setting the clock backward: the local time will be gradually adjusted again via the clock discipline algorithm until local and NTP times converge. Although the offset is more than the 125ms step threshold, stepping a full one second backward is still statistically unlikely. It may be that I’ve misread the NTP specification in RPC-5905 and its antecedents, as well as the leap second historical records of problems. But the disabling-NTP-prior-to-leap workaround seems to bypass all the documented leap-second live lock hangs and other bugs.. -mel On Jun 22, 2015, at 4:06 PM, Harlan Stenn st...@ntp.orgmailto:st...@ntp.org wrote: Doug Barton writes: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) On 6/19/15 2:58 PM, Harlan Stenn wrote: Bad idea. When restarting ntpd your clocks will likely be off by a second, which will cause a backward step, which will force the problem you claim to be avoiding. There are plenty of ways to solve this problem, and you just get to choose what you want to risk/pay. You misunderstand the problem. :) The problem is not clock skips backward one second, because most of the time that's not what happens. The problem is that most software does not handle it well when the clock ticks ... :59 :60 :00 instead of ticking directly from :59 to :00. POSIX NEVER shows :60. THAT problem is avoided by temporarily turning off NTP and then turning it back on again when the coast is clear. Most software can handle the clock skips forward or backwards one second problem fairly robustly,= and as Baldur pointed out by doing the reset in a controlled manner you greatly reduce your overall risk. Time going backwards is deadly to a number of applications. But apparently not to applications you care about. You're also not doing anything where somebody is going to get sued because a timestamp is off by a second. There are people for whom this is a very real risk. H
Re: Residential VSAT experiences?
Interesting that you say that about sip. We had a client that would use it for sip on ships all the time. It wasn't the best but it worked. Ping times were between 500-700ms. It really depends on your expectations - or more to the point, your end-users' expectations. I've tested SIP in the lab up to 2000ms RTT. The protocols all hang together and keep working, but it's obviously very much in walkie-talkie mode, you can't hold a normal duplex conversation. 500ms there's more of the talking over each other / sorry, you go / no, you go dance, but it *is* workable. If your end-user is expecting land-line replacement though... Regards, Tim.
Re: REMINDER: LEAP SECOND
This stuff can make my head explode. When a leap second is added, like on 30 June 2015 at the last second of the day, POSIX insists that the day still have 86400 seconds in it. This makes the day longer by one second, so time has to either slow down or move backwards. The dumb way to do this is to step the clock back by 1 second at the instant before the stroke of midnight. The allegedly better way to do this would be to stop the clock a bit before midnight, and hold the time for 1 second. To continue providing monotonic time, every time somebody says what time is it during that holding period one would want to bump the time by the smallest amount possible, usually 1 nanosecond (assuming the kernel keeps time in nanoseconds). Ideally you wouldn't want to add enough nanoseconds to cause the clock to roll over into the next day too early. But apparently nobody has implemented this, even though Prof. Mills described it in RFC-i-forget about 20 years ago. This is mostly because POSIX deals with absolute time and not relative time. In the unlikely event of a leap second deletion, there would be no 23:59:59, so when the clock is about to strike 23:59:59 it's OK to add an extra second to the clock to effectively have the time jump from 23:59:58 to 00:00:00. This is still a monotonic increment in time. Whatever you decide to do, I recommend you actually test it out to see if it behaves the way you think it will. You have a whole week still. H
Re: REMINDER: LEAP SECOND
On 23/06/2015 10:25, Mel Beckman wrote: Why should your head explode? Possibly you’re overthinking the problem. The problems don't relate to Harlan overthinking the problem. They relate to developers underthinking the problem and assuming that all clocks are monotonic and that certain rules apply, e.g. that there are 60 seconds in a minute, 86400 seconds in a day and so forth. Mostly applications are not time sensitive, but sometimes they are. When they are, and when the developer assumes something which isn't true, unexpected things might happen. assert()s can be triggered, time synchronisation lost with third party applications, unexpected and untested code paths could be used, etc. Blocking NTP at the NTP edge will probably work fine for most situations. Bear in mind that your NTP edge is not necessarily the same as your network edge. E.g. you might have internal GPS / radio sources which could unexpectedly inject the leap second. The larger the network, the more likely this is to happen. Most organisations have network fossils and ntp is an excellent source of these. I.e. systems which work away for years without any problems before one day accidentally triggering meltdown because some developer didn't understand the subtleties of clock monotonicity. Nick
Re: REMINDER: LEAP SECOND
- Original Message - From: Harlan Stenn st...@ntp.org You misunderstand the problem. :) The problem is not clock skips backward one second, because most of the time that's not what happens. The problem is that most software does not handle it well when the clock ticks ... :59 :60 :00 instead of ticking directly from :59 to :00. POSIX NEVER shows :60. Then I hope POSIX does not claim to represent UTC, because UTC does, no? (IE: somewhere between a bit and a lot more expansion was called for there; most of us don't have ntp.org email addresses. :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
FOLO: Leap Seconds
Herewith, for your amusement in the copious free time I hope you have from having smoothly humming networks that don't demand your attention: Falsehoods programers believe about time: http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time and More Falsehoods programmers believe about time: http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time If your heads explode, *I* am not wiping up after. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: REMINDER: LEAP SECOND
Yo Jay! On Tue, 23 Jun 2015 22:02:50 -0400 (EDT) Jay Ashworth j...@baylink.com wrote: - Original Message - From: Harlan Stenn st...@ntp.org You misunderstand the problem. :) The problem is not clock skips backward one second, because most of the time that's not what happens. The problem is that most software does not handle it well when the clock ticks ... :59 :60 :00 instead of ticking directly from :59 to :00. POSIX NEVER shows :60. Then I hope POSIX does not claim to represent UTC, because UTC does, no? POSIX-1:2001 clearly 61 seeconds in a minute: The POSIX-1:2001 docs are here: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html From the Description: The time.h header shall declare the structure tm, which shall include at least the following members: inttm_sec Seconds [0,60]. From the Application Usage: The range [0,60] for tm_sec allows for the occasional leap second. From the Rationale: The range [0,60] seconds allows for positive or negative leap seconds. But, from the section on Seconds Since the Epoch http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_14 POSIX seconds is defined as: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 Summed up with: The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified. Which basically says if you are gonna split hairs on leap seconds things will be undefined. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1(541)382-8588 pgp7sfNLqXqeR.pgp Description: OpenPGP digital signature
Re: FOLO: Leap Seconds
24. Jun 2015 02:06 by j...@baylink.com: Falsehoods programers believe about time: and More Falsehoods programmers believe about time: Great links! If only every programmer would take heed... :)
Re: NANOG Digest, Vol 89, Issue 24
Alex Hardie writes: Not to inject more confusion - but GPS and NTP are noted in the thread... but not PTP (IEEE1588)? I don't belive PTP generally uses UTC as a timescale. H
Re: REMINDER: LEAP SECOND
shawn wilson writes: On Jun 23, 2015 6:26 AM, Nick Hilliard n...@foobar.org wrote: Blocking NTP at the NTP edge will probably work fine for most situations. Bear in mind that your NTP edge is not necessarily the same as your network edge. E.g. you might have internal GPS / radio sources which could unexpectedly inject the leap second. The larger the network, the more likely this is to happen. Most organisations have network fossils and ntp is an excellent source of these. I.e. systems which work away for years without any problems before one day accidentally triggering meltdown because some developer didn't understand the subtleties of clock monotonicity. NTP causes jumps - not skews, right? Left to its default condition, ntp will step/jump a change in excess of 128msec. If you want to slew the clock instead, a 1 second correction will take a little over 33 minutes' time to apply. I don't understand why people believe that stopping ntpd for a few minutes while the leap second is applied will help. If the system clock keeps good time, it will *still* be about 1 second ahead when ntpd is restarted, and that will trigger a backward step which is fatal to a number of applications. H
Re: REMINDER: LEAP SECOND
A backward step is a known issue and something that people are more comfortable dealing with as it can happen on any machine with a noisy clock crystal. Having 61 seconds in a minute or 86401 seconds in a day is a different story. On Jun 23, 2015, at 8:37 PM, Harlan Stenn st...@ntp.org wrote: shawn wilson writes: On Jun 23, 2015 6:26 AM, Nick Hilliard n...@foobar.org wrote: Blocking NTP at the NTP edge will probably work fine for most situations. Bear in mind that your NTP edge is not necessarily the same as your network edge. E.g. you might have internal GPS / radio sources which could unexpectedly inject the leap second. The larger the network, the more likely this is to happen. Most organisations have network fossils and ntp is an excellent source of these. I.e. systems which work away for years without any problems before one day accidentally triggering meltdown because some developer didn't understand the subtleties of clock monotonicity. NTP causes jumps - not skews, right? Left to its default condition, ntp will step/jump a change in excess of 128msec. If you want to slew the clock instead, a 1 second correction will take a little over 33 minutes' time to apply. I don't understand why people believe that stopping ntpd for a few minutes while the leap second is applied will help. If the system clock keeps good time, it will *still* be about 1 second ahead when ntpd is restarted, and that will trigger a backward step which is fatal to a number of applications. H
