Portions of the Internet panicked yesterday when Gmail was hit by an outage that lasted for an agonizing 18 minutes . The outage coincided with reports of Google’s Chrome browser crashing. It turns out the culprit was a faulty load balancing change that affected products including Chrome’s sync service, which allows users to sync bookmarks and other browser settings across multiple computers and mobile devices. Ultimately, it was human error. Google engineer Tim Steele explained the problem’s origins in a developer forum : Chrome Sync Server relies on a backend infrastructure component to enforce quotas on per-datatype sync traffic. That quota service experienced traffic problems today due to a faulty load balancing configuration change. That change was to a core piece of infrastructure that many services at Google depend on. This means other services may have been affected at the same time, leading to the confounding original title of this bug [which referred to Gmail]. Because of the quota service failure, Chrome Sync Servers reacted too conservatively by telling clients to throttle “all” data types, without accounting for the fact that not all client versions support all data types. The crash is due to faulty logic responsible for handling “throttled” data types on the client when the data types are unrecognized. If the Chrome sync service had gone down entirely, the Chrome browser crashes would not have occurred, it turns out. “In fact this crash would *not* happen if the sync server itself was unreachable,” Steele wrote. “It’s due to a backend service that sync servers depend on becoming overwhelmed, and sync servers responding to that by telling all clients to throttle all data types (including data types that the client may not understand yet).” Read 4 remaining paragraphs | Comments
Read More:
Why Gmail went down: Google misconfigured load balancing servers
Time Machine should by default back up all internal hard drives on a Mac; however, some people are experiencing a problem in which drives appear to be automatically excluded from being backed up. [Read more] 
MrSeb writes with news on the happenings with next generation fabrication processes. From the article: “… Intel’s 22nm SoC unveil is important for a host of reasons. As process nodes shrink and more components move on-die, the characteristics of each new node have become particularly important. 22nm isn’t a new node for Intel; it debuted the technology last year with Ivy Bridge, but SoCs are more complex than CPU designs and create their own set of challenges. Like its 22nm Ivy Bridge CPUs, the upcoming 22nm SoCs rely on Intel’s Tri-Gate implementation of FinFET technology. According to Intel engineer Mark Bohr, the 3D transistor structure is the principle reason why the company’s 22nm technology is as strong as it is. Earlier this year, we brought you news that Nvidia was deeply concerned about manufacturing economics and the relative strength of TSMC’s sub-28nm planar roadmap. Morris Chang, TSMC’s CEO, has since admitted that such concerns are valid, given that performance and power are only expected to increase by 20-25% as compared to 28nm. The challenge for both TSMC and GlobalFoundries is going to be how to match the performance of Intel’s 22nm technology with their own 28nm products. 20nm looks like it won’t be able to do so, which is why both companies are emphasizing their plans to move to 16nm/14nm ahead of schedule. There’s some variation on which node comes next; both GlobalFoundries and Intel are talking up 14nm; TSMC is implying a quick jump to 16nm. Will it work? Unknown. TSMC and GlobalFoundries both have excellent engineers, but FinFET is a difficult technology to deploy. Ramping it up more quickly than expected while simultaneously bringing up a new process may be more difficult than either company anticipates.” Read more of this story at Slashdot. 
It’s not clear what might have caused the outage this morning, but it appeared to be fairly widespread. [Read more] 
