Here is an interview with Chen Guangbiao - he is the KING OF RECYCLING in China and said to be the number 1 richest in China. 2 days ago he smashed & crashed his Mercedes 600 on the so-called "No-driving Day". He is a big "donator" - even distributing the money by himself - it seems many people do not really trust him...here is an interview. Have your own thoughts on this:
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
Time, technology and leaping seconds
Google’s Site Reliability team is responsible for keeping Google’s services and data centers up and running 24/7. In this post, you’ll hear about a project our Site Reliability Engineers took on to make sure that the fluctuations of time don’t adversely affect Google’s products and services. If you like this (detailed) glimpse at the tech behind the scenes, come back for more about this team’s work in the future. -Ed.
Have you ever had a watch that ran slow or fast, and that you’d correct every morning off your bedside clock? Computers have that same problem. Many computers, including some desktop and laptop computers, use a service called the “Network Time Protocol” (NTP), which does something very similar—it periodically checks the computers’ time against a more accurate server, which may be connected to an external source of time, such as an atomic clock. NTP also takes into account variable factors like how long the NTP server takes to reply, or the speed of the network between you and the server when setting a to-the-second or better time on the computer you’re using.
Soon after the advent of ticking clocks, scientists observed that the time told by them (and now, much more accurate clocks), and the time told by the Earth's position were rarely exactly the same. It turns out that being on a revolving imperfect sphere floating in space, being reshaped by earthquakes and volcanic eruptions, and being dragged around by gravitational forces makes your rotation somewhat irregular. Who knew?
These fluctuations in Earth’s rotational speed mean that even very accurate clocks, like the atomic clocks used by global timekeeping services, occasionally have to be adjusted slightly to bring them in line with “solar time.” There have been 24 such adjustments, called “leap seconds,” since they were introduced in 1972. Their effect on technology has become more and more profound as people come to rely on fast, accurate and reliable technology.
Why time matters at Google
Having accurate time is critical to everything we do at Google. Keeping replicas of data up to date, correctly reporting the order of searches and clicks, and determining which data-affecting operation came last are all examples of why accurate time is crucial to our products and to our ability to keep your data safe.
Very large-scale distributed systems, like ours, demand that time be well-synchronized and expect that time always moves forwards. Computers traditionally accommodate leap seconds by setting their clock backwards by one second at the very end of the day. But this “repeated” second can be a problem. For example, what happens to write operations that happen during that second? Does email that comes in during that second get stored correctly? What about all the unforeseen problems that may come up with the massive number of systems and servers that we run? Our systems are engineered for data integrity, and some will refuse to work if their time is sufficiently “wrong.” We saw some of our clustered systems stop accepting work on a small scale during the leap second in 2005, and while it didn’t affect the site or any of our data, we wanted to fix such issues once and for all.
This was the problem that a group of our engineers identified during 2008, with a leap second scheduled for December 31. Given our observations in 2005, we wanted to be ready this time, and in the future. How could we make sure everything at Google stays running as if nothing happened, when all our server clocks suddenly see the same second happening twice? Also, how could we make this solution scale? Would we need to audit every line of code that cares about the time? (That’s a lot of code!)
The solution we came up with came to be known as the “leap smear.” We modified our internal NTP servers to gradually add a couple of milliseconds to every update, varying over a time window before the moment when the leap second actually happens. This meant that when it became time to add an extra second at midnight, our clocks had already taken this into account, by skewing the time over the course of the day. All of our servers were then able to continue as normal with the new year, blissfully unaware that a leap second had just occurred. We plan to use this “leap smear” technique again in the future, when new leap seconds are announced by the IERS.
Here’s the science bit
Usually when a leap second is almost due, the NTP protocol says a server must indicate this to its clients by setting the “Leap Indicator” (LI) field in its response. This indicates that the last minute of that day will have 61 seconds, or 59 seconds. (Leap seconds can, in theory, be used to shorten a day too, although that hasn’t happened to date.) Rather than doing this, we applied a patch to the NTP server software on our internal Stratum 2 NTP servers to not set LI, and tell a small “lie” about the time, modulating this “lie” over a time window w before midnight:
In an experiment, we performed two smears—one negative then one positive—and tested this setup using about 10,000 servers. We'd previously added monitoring to plot the skew between atomic time, our Stratum 2 servers and all those NTP clients, allowing us to constantly evaluate the performance of our time infrastructure. We were excited to see monitoring showing plots of those servers’ clocks tracking our model's predictions, and that we were continuing to serve users’ requests without errors.
Following the successful test, we reconfigured all our production Stratum 2 NTP servers with details of the actual leap second, ready for New Year's Eve, when they would automatically activate the smear for all production machines, without any further human intervention required. We had a “big red button” opt-out that allowed us to stop the smear in case anything went wrong.
What we learned
The leap smear is talked about internally in the Site Reliability Engineering group as one of our coolest workarounds, that took a lot of experimentation and verification, but paid off by ultimately saving us massive amounts of time and energy in inspecting and refactoring code. It meant that we didn’t have to sweep our entire (large) codebase, and Google engineers developing code don’t have to worry about leap seconds. The team involved in solving this issue was a handful of people, distributed around the world, who were able to work together without restriction in order to solve this problem.
The solution to this challenge drove a lot of thinking to develop better ways to implement locking and consistency, and synchronizing units of work between servers across the world. It also meant we thought more about the precision of our time systems, which have a knock-on effect on our ability to minimize resource wastage and run greener data centers by reducing the amount of time we must spend waiting for responses and rarely doing excess work.
By anticipating potential problems and developing solutions like these, the Site Reliability Engineering group informs and inspires the development of new technology for distributed systems—the systems that you use every day in Google’s products.
Have you ever had a watch that ran slow or fast, and that you’d correct every morning off your bedside clock? Computers have that same problem. Many computers, including some desktop and laptop computers, use a service called the “Network Time Protocol” (NTP), which does something very similar—it periodically checks the computers’ time against a more accurate server, which may be connected to an external source of time, such as an atomic clock. NTP also takes into account variable factors like how long the NTP server takes to reply, or the speed of the network between you and the server when setting a to-the-second or better time on the computer you’re using.
Soon after the advent of ticking clocks, scientists observed that the time told by them (and now, much more accurate clocks), and the time told by the Earth's position were rarely exactly the same. It turns out that being on a revolving imperfect sphere floating in space, being reshaped by earthquakes and volcanic eruptions, and being dragged around by gravitational forces makes your rotation somewhat irregular. Who knew?
These fluctuations in Earth’s rotational speed mean that even very accurate clocks, like the atomic clocks used by global timekeeping services, occasionally have to be adjusted slightly to bring them in line with “solar time.” There have been 24 such adjustments, called “leap seconds,” since they were introduced in 1972. Their effect on technology has become more and more profound as people come to rely on fast, accurate and reliable technology.
Why time matters at Google
Having accurate time is critical to everything we do at Google. Keeping replicas of data up to date, correctly reporting the order of searches and clicks, and determining which data-affecting operation came last are all examples of why accurate time is crucial to our products and to our ability to keep your data safe.
Very large-scale distributed systems, like ours, demand that time be well-synchronized and expect that time always moves forwards. Computers traditionally accommodate leap seconds by setting their clock backwards by one second at the very end of the day. But this “repeated” second can be a problem. For example, what happens to write operations that happen during that second? Does email that comes in during that second get stored correctly? What about all the unforeseen problems that may come up with the massive number of systems and servers that we run? Our systems are engineered for data integrity, and some will refuse to work if their time is sufficiently “wrong.” We saw some of our clustered systems stop accepting work on a small scale during the leap second in 2005, and while it didn’t affect the site or any of our data, we wanted to fix such issues once and for all.
This was the problem that a group of our engineers identified during 2008, with a leap second scheduled for December 31. Given our observations in 2005, we wanted to be ready this time, and in the future. How could we make sure everything at Google stays running as if nothing happened, when all our server clocks suddenly see the same second happening twice? Also, how could we make this solution scale? Would we need to audit every line of code that cares about the time? (That’s a lot of code!)
The solution we came up with came to be known as the “leap smear.” We modified our internal NTP servers to gradually add a couple of milliseconds to every update, varying over a time window before the moment when the leap second actually happens. This meant that when it became time to add an extra second at midnight, our clocks had already taken this into account, by skewing the time over the course of the day. All of our servers were then able to continue as normal with the new year, blissfully unaware that a leap second had just occurred. We plan to use this “leap smear” technique again in the future, when new leap seconds are announced by the IERS.
Here’s the science bit
Usually when a leap second is almost due, the NTP protocol says a server must indicate this to its clients by setting the “Leap Indicator” (LI) field in its response. This indicates that the last minute of that day will have 61 seconds, or 59 seconds. (Leap seconds can, in theory, be used to shorten a day too, although that hasn’t happened to date.) Rather than doing this, we applied a patch to the NTP server software on our internal Stratum 2 NTP servers to not set LI, and tell a small “lie” about the time, modulating this “lie” over a time window w before midnight:
lie(t) = (1.0 - cos(pi * t / w)) / 2.0What this did was make sure that the “lie” we were telling our servers about the time wouldn’t trigger any undesirable behavior in the NTP clients, such as causing them to suspect the time servers to be wrong and applying local corrections themselves. It also made sure the updates were sufficiently small so that any software running on the servers that were doing synchronization actions or had Chubby locks wouldn't lose those locks or abandon any operations. It also meant this software didn’t necessarily have to be aware of or resilient to the leap second.
In an experiment, we performed two smears—one negative then one positive—and tested this setup using about 10,000 servers. We'd previously added monitoring to plot the skew between atomic time, our Stratum 2 servers and all those NTP clients, allowing us to constantly evaluate the performance of our time infrastructure. We were excited to see monitoring showing plots of those servers’ clocks tracking our model's predictions, and that we were continuing to serve users’ requests without errors.
Following the successful test, we reconfigured all our production Stratum 2 NTP servers with details of the actual leap second, ready for New Year's Eve, when they would automatically activate the smear for all production machines, without any further human intervention required. We had a “big red button” opt-out that allowed us to stop the smear in case anything went wrong.
What we learned
The leap smear is talked about internally in the Site Reliability Engineering group as one of our coolest workarounds, that took a lot of experimentation and verification, but paid off by ultimately saving us massive amounts of time and energy in inspecting and refactoring code. It meant that we didn’t have to sweep our entire (large) codebase, and Google engineers developing code don’t have to worry about leap seconds. The team involved in solving this issue was a handful of people, distributed around the world, who were able to work together without restriction in order to solve this problem.
The solution to this challenge drove a lot of thinking to develop better ways to implement locking and consistency, and synchronizing units of work between servers across the world. It also meant we thought more about the precision of our time systems, which have a knock-on effect on our ability to minimize resource wastage and run greener data centers by reducing the amount of time we must spend waiting for responses and rarely doing excess work.
By anticipating potential problems and developing solutions like these, the Site Reliability Engineering group informs and inspires the development of new technology for distributed systems—the systems that you use every day in Google’s products.
Saying thanks—in person—to our Google Top Contributors
“Oh, you’re BlueQuoll!”
You heard a lot of enthusiastic cries of recognition at the Global Top Contributor Summit, as Googlers and members of our Top Contributor program got to leave their laptops behind and meet one another face to face. This two-day event held in and around our headquarters in Mountain View brought together some of our most prolific and knowledgeable users from the Google product forums for the first time.
Top Contributors are the folks you may know by “bkc56” in the Gmail forum, “Noisette” in the Google Earth forum and “theylmdl” in the German Webmaster forum—Google users who volunteer their time to help others with questions and troubleshooting issues. We began the program in 2005 to support this important group, and today there are more than 350 Top Contributors who are active in our forums. They also give Google teams important feedback to help shape the development of our products. In short, they’re some of Google’s most passionate users, and we wanted to take the time to share our appreciation.
At the summit, more than 250 Top Contributors joined us from around the world, representing 40+ product forums in 20+ languages. To see just how global this amazing bunch is, check out the map we set up to showcase their hometowns:
At the event, our Top Contributors met with Google engineers who demo’ed upcoming features, giving them the unique opportunity to give feedback and ask questions. This was also an opportunity for our Top Contributors to meet each other, and make a new friend or two.
We hope this summit gave our Top Contributors more insight into how Google works and expressed just how much we appreciate their help and dedication. In fact, they’re such a dedicated bunch that some of the Top Contributors were even spotted during the summit answering forum questions. To see them in action, head on over to the Google product forums.
Find out about how you can become a Top Contributor in our Help Forum guide.
You heard a lot of enthusiastic cries of recognition at the Global Top Contributor Summit, as Googlers and members of our Top Contributor program got to leave their laptops behind and meet one another face to face. This two-day event held in and around our headquarters in Mountain View brought together some of our most prolific and knowledgeable users from the Google product forums for the first time.
Top Contributors are the folks you may know by “bkc56” in the Gmail forum, “Noisette” in the Google Earth forum and “theylmdl” in the German Webmaster forum—Google users who volunteer their time to help others with questions and troubleshooting issues. We began the program in 2005 to support this important group, and today there are more than 350 Top Contributors who are active in our forums. They also give Google teams important feedback to help shape the development of our products. In short, they’re some of Google’s most passionate users, and we wanted to take the time to share our appreciation.
TCs from the AdSense, Gmail and Webmaster forums hang out with Googlers (in red)
At the summit, more than 250 Top Contributors joined us from around the world, representing 40+ product forums in 20+ languages. To see just how global this amazing bunch is, check out the map we set up to showcase their hometowns:
At the event, our Top Contributors met with Google engineers who demo’ed upcoming features, giving them the unique opportunity to give feedback and ask questions. This was also an opportunity for our Top Contributors to meet each other, and make a new friend or two.
Bottom right: TC treebles, as he’s known in the Maps and Places for business forums, talks with the custom maps team
We hope this summit gave our Top Contributors more insight into how Google works and expressed just how much we appreciate their help and dedication. In fact, they’re such a dedicated bunch that some of the Top Contributors were even spotted during the summit answering forum questions. To see them in action, head on over to the Google product forums.
Find out about how you can become a Top Contributor in our Help Forum guide.
A search insights lesson for back-to-school
(Cross-posted on the Inside Search Blog and the Retail Blog)
Time to sharpen those pencils: now that the back-to-school season is winding down and students are back at their desks, we thought we’d take a look at some popular searches from the last few weeks. Students across the U.S. are hitting the books—although, as we found, not all their back-to-school searches are academically inclined.
Overall, search interest in [back to school] is up about 10 percent from last year.
After a three-month hiatus, everyone wants to make a great impression on the first day of school. Searches related to starting fresh—like [kids shoes], [kids haircuts] and [healthy school lunches]—jump during the back-to-school season. People are also eager to sport just the right look—searches for [first day of school outfit] have increased 20 percent since the 2010 season.
A well-stocked locker is also top of mind for many at the start of the school year. Search interest for back-to-school staples like pencils, notebooks and backpacks routinely peaks during the season, as kids compare colors, styles and designs online. But tech-savvy students are seeking new essentials for the classroom. Searches for [tablet] exceeded searches for [backpack] for the first time in a July-September period. And with [etextbook] searches up 50 percent from September 2010, look for ereaders to slip into more backpacks in the future.
Crossing items off the back-to-school list is rewarding, but it’s a lot more satisfying when there’s a bargain involved. This year is no exception with shoppers scanning for deals before heading to stores. Searches for [back to school coupons] and [back to school sales] increased 10 and 25 percent, and searches for [printable coupons] jumped 45 percent from last year’s season.
College-bound freshmen seem to be looking for ways to take charge of their finances. Searches for [bank account] and [open bank account] peak in August, and were up about 20 percent from last year’s back-to-school season. Searches for [student credit card] are also highest during this time of year, along with searches for the means to pay a credit card bill: [campus jobs]. In recent years, securing a steady source of income has trumped on-the-spot spending. While searches for [student credit card] have decreased 30 percent since 2004, searches for [campus jobs] have steadily increased, up 50 percent in the same period.
Finally, we’ll leave you with a few back-to-school essentials that might not have made your list. To avoid using the modern version of the old “my dog ate my homework” excuse, protect your computer with a [laptop lock]—searches regularly spike in in August. If you’ve been thinking about picking up an instrument, now’s the time to jump on the bandwagon (pun intended), as searches for [flute], [cello], [violin] and [clarinet] jump every September. And for your mother’s sake (and your roommate’s), find a good [laundry service] on campus. Search interest peaks in September, though the clothes-washing learning curve lasts the entire year.
Time to sharpen those pencils: now that the back-to-school season is winding down and students are back at their desks, we thought we’d take a look at some popular searches from the last few weeks. Students across the U.S. are hitting the books—although, as we found, not all their back-to-school searches are academically inclined.
Overall, search interest in [back to school] is up about 10 percent from last year.
After a three-month hiatus, everyone wants to make a great impression on the first day of school. Searches related to starting fresh—like [kids shoes], [kids haircuts] and [healthy school lunches]—jump during the back-to-school season. People are also eager to sport just the right look—searches for [first day of school outfit] have increased 20 percent since the 2010 season.
A well-stocked locker is also top of mind for many at the start of the school year. Search interest for back-to-school staples like pencils, notebooks and backpacks routinely peaks during the season, as kids compare colors, styles and designs online. But tech-savvy students are seeking new essentials for the classroom. Searches for [tablet] exceeded searches for [backpack] for the first time in a July-September period. And with [etextbook] searches up 50 percent from September 2010, look for ereaders to slip into more backpacks in the future.
Crossing items off the back-to-school list is rewarding, but it’s a lot more satisfying when there’s a bargain involved. This year is no exception with shoppers scanning for deals before heading to stores. Searches for [back to school coupons] and [back to school sales] increased 10 and 25 percent, and searches for [printable coupons] jumped 45 percent from last year’s season.
College-bound freshmen seem to be looking for ways to take charge of their finances. Searches for [bank account] and [open bank account] peak in August, and were up about 20 percent from last year’s back-to-school season. Searches for [student credit card] are also highest during this time of year, along with searches for the means to pay a credit card bill: [campus jobs]. In recent years, securing a steady source of income has trumped on-the-spot spending. While searches for [student credit card] have decreased 30 percent since 2004, searches for [campus jobs] have steadily increased, up 50 percent in the same period.
Finally, we’ll leave you with a few back-to-school essentials that might not have made your list. To avoid using the modern version of the old “my dog ate my homework” excuse, protect your computer with a [laptop lock]—searches regularly spike in in August. If you’ve been thinking about picking up an instrument, now’s the time to jump on the bandwagon (pun intended), as searches for [flute], [cello], [violin] and [clarinet] jump every September. And for your mother’s sake (and your roommate’s), find a good [laundry service] on campus. Search interest peaks in September, though the clothes-washing learning curve lasts the entire year.
Subscribe to:
Posts (Atom)
