►
This July 30th, at 23:59:60, a leap second was added to Coordinated Universal Time (UTC). Dyn Research posted the following graph on Twitter that shows there was significant BGP update instability for five minutes after the leap second occurred:
▼
This July 30th, at 23:59:60, a leap second was added to Coordinated Universal Time (UTC). Dyn Research posted the following graph on Twitter that shows there was significant BGP update instability for five minutes after the leap second occurred:
Unfortunately, it's not clear why this happened. However, leap seconds have triggered all kinds of mishaps in the past. They're basically miniature Y2K problems. Time and time again, software engineers show that they can't be trusted to take corner cases into account properly.
This does remind me of a situation about a decade ago, where I had a customer that experienced BGP instability every night at the same time. They used Quagga running on Linux machines. We couldn't figure out what the problem was, until we realized that at that very moment, the ntpdate command was run from the cron. ntpdate synchronizes the system clock with an NTP server. As the machine in question had a very poor system clock, this meant that the system's time was adjusted a lot every night, I think a minute or more, but definitely more than 30 seconds.
Which meant that if Quagga had gotten a BGP keepalive message 8 seconds earlier, it now thought that was 38 seconds ago. If BGP is configured with a hold time of 30 seconds, this means that Quagga now thinks the other side has been quiet for longer than the hold time and it'll tear down the BGP session. This is what happened every night for a bunch of BGP sessions. We solved this by running the NTP daemon continuously, so there was never a big adjustment in system time. (Alternatively, just letting the time drift would also have worked.)
The minimum BGP hold time is 3 seconds, so adjusting for an (improperly handled) leap second shouldn't be able to make BGP think the hold time for a session is expired. However, there could be bug somewhere else that impacted BGP.
I'm not sure whether these kinds of issues are a good argument in favor of abandoning leap seconds, as the bugs won't go away, they'll just show up at a less predictable time. But I don't like the current leap second practice, as they're unpredictable, and you can't calculate the time difference in seconds between two dates without taking the entire list of leap seconds into account. I think it would be better to save the leap seconds up and apply them all at the end of a century.
Despite the blister on my foot I couldn't resist going out and trying out my new Powerslide Fothon wheels for my inline skates. I got a 4-pack of wheels with red LEDs:
The wheels contain a small generator that uses the rotation of the wheel to generate electricity for the LEDs, so they come on when the wheels turn. Because all of this slows down the wheels a bit, I'm only using one on each skate. They also come in white, blue and green.
And as always, iPhone slow motion video for the win!
At the NANOG meeting in San Francisco two weeks ago, there was a session on The benefits of deploying IPv6 only. Someone from T-Mobile explained that the latest Windows Mobile and Android support 464XLAT to allow IPv4-only applications to work over IPv6 with NAT64, so those devices now only get IPv6. Other devices only get IPv4, there's no dual stack. At that point, the panelists didn't know yet that Apple is requiring iOS 9 apps to work over IPv6 so those can work through NAT64 without 464XLAT.
Another interesting data point is the observation by Facebook that IPv6 tends to perform better than IPv4, with the margin being as large as 40%:
However, why this is is unclear: the RTTs are the same, yet the performance/bandwidth over IPv6 is better. There was some frustration because Apple's implementation of "happy eyeballs" only looks at the RTT to choose between IPv4 and IPv6, and thus lands on IPv4 a good deal of the time and doesn't enjoy the benefits of that better IPv6 performance.
I think yesterday's WWDC was the longest one I've seen at nearly 2.5 hours. Still, there wasn't much to get excited about. Apple Pay is coming to the UK, but not to the rest of the world. Apple Maps transit directions are coming to two handfuls of cities and all of China, but not to Holland. Apple's new news app is also limited to the US, the UK and Australia. The music stuff may or may not be interesting, but I'm afraid it's going to get in the way of simply playing the music I have on my computer and my iPhone.
But... reading the fine print, there is one thing I can get behind:
A customizable font for Safari Reader!
I must be getting old, but I really can't stand what the web has become these days. The trend to have fixed banners at the top and/or bottom of pages gets on my nerves, because that way you can't scroll a webpage one screen at a time. It's also visually distracting. As are the attention-grabbing ads, which are often animated or video. So there's hardly any text I read on the web without invoking Safari Reader.
However, Safari Reader itself isn't all that great: the width of the text is fixed, so in order to get avoid having too many words per line, which makes it hard to land on the next line, I need to keep the text size bigger than I'd like. (Funny, because 95% of web pages use text that is way too small.)
Safari Reader uses the Georgia font, which isn't terrible, but largish serif fonts just don't take advantage of high resolution displays. So I hope that in addition to the ability to configure a nice sans serif font, we also get to adjust the margins in Safari Reader.
Allen Pike, "crafter of fine software", writes about how insane browser user agent strings have gotten. Case in point, the mobile version of Edge, Microsoft's new cutting-edge browser:
Mozilla/5.0 (Windows Phone 10.0; Android 4.2.1; DEVICE INFO) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Mobile Safari/537.36 Edge/12.0
That is to say, Microsoft Edge claims to be every computing platform ever conceived - except for Internet Explorer.
The nasty thing with all this useless nonsense that the browser sends to the server for every request is that it takes up often precious upstream bandwidth. On a slow DSL or 3G link this can really slow things down.
