There's a mistake in your calculation. As you say, a 1 m^2 panel produces about 200 W of power. But for ten hours of sunlight that's 2 kWh of energy. So everything improves by a factor of ten.
In any case, I wonder if someone could combine all that with the 36 dramatic situations and a few other components, and create a program that writes stories....
Someone has... every Hollywood studio has it running on their server farms
I think your summary is right. Skimming the article http://arxiv.org/abs/1309.0005 I get the same impression. In the paper they say that you have to be careful to design your tests to catch all the errors that would affect the answer. The summary doesn't say it, but one significant aspect of the work is that it is the first experimental demonstration of verification of a quantum computation.
GNSS receivers don' t use change in position to measure speed. They use the Doppler shift of the GNSS carrier signal ie a frequency measurement and this can be done accurately. Typically, accuracies of about 0.1 km/h are specified by the manufacturer. The usual caveats about satellite visibility apply.
Where I work, a government scientific organisation, you can be promoted according to either skill or responsibility, at least to a point. So there are instances of someone supervising half a dozen people, several of whom are employed at the same level as the supervisor. The management path is a bit easier though, and promotion on skill alone pretty much tops out at the level equivalent to supervising half a dozen people.
A friend who works at a large company said that they had two promotion paths too: management or technical skill.
From the article : "The problem is that about 40 percent or more of retail shoppers walk out without finding what they want. But in half of those cases, the product actually was in stock.”
Let me fix that: The problem is that about 40 percent or more of retail shoppers walk out without finding what they want because the store is understaffed, and the few staff on the floor are lowly-paid, inexperienced casuals.
Not all ion clocks are optical. Linear ion trap microwave clocks based on Yb and Hg were developed in the 90s. Some Hg clocks operated as part of the NASA Deep Space Network for a number of years and there's currently an active project to develop a highly miniaturised Yb clock. So the summary should say that lattice clocks can beat single ion clocks on QPN and fountains because optical beats microwave.
Big M= 1000000 (like in megohms) Little k =.1000 (like in kilograms) But your confusion is understandable, given the failure of Americans to grasp the metric system (humour)
Actually come to think of it, we should really write $100M as 100M$.
All those things that a supercomputer could do 20 years ago... they got done. So that powerful tablet is doomed to executing Angry Birds because the interesting problems that might create economic wealth still need a supercomputer and always will.
Not sure what you mean here. Are you referring to a systematic disagreement between the German and Japanese measurements of the Avogadro spheres that is not accommodated by the estimated uncertainties ?
It doesn't work that way. In the case of the Avogadro sphere, for example, you count the number of atoms of Si 28 and then choose a certain number to be equal to 1 kg, this number being chosen to give agreement with the prototype kg held by the BIPM in Paris. This in effect defines the Avogadro constant.
Well,there is one proposed. This is the Avogadro Project, one of two candidates for a redefinition of the kg, the other being the Watt balance. You take a lump of isotopically pure crystalline Si (Si 28) and optically polish it to a 'perfect' sphere. You then use very accurate laser interferometry to measure the volume of the sphere (and with a suitable set of measurements and model you can correct for any residual non-sphericity) You use X-ray diffraction to measure the lattice spacing. You can now calculate the number of atoms in the sphere. There are also corrections for the oxide layer at the surface,residual impurities etc. The nice thing, apart from the kg being defined by dimensional measurements (which are then traceable to the SI second) , is that if you chip your kg standard, you just repolish it and remeasure it. You then define what one kg is by saying a certain number of Si 28 atoms is equal to 1 kg. This number would be chosen to agree as closely as possible with the current definition of the kg. This process is similar to the way the second was redefined, from an astronomically defined value to a value defined by a microwave transition in the caesium atom.
I was doing leap second testing in the last month and I'm pretty sure that date returns 23:59:58 23:59:59 23:59:59 00:00:00 as you go through the leap second addition (Un)fortunately, not at work so I can't double check but a quick look at the date source code suggests that this is indeed its behaviour on Linux.
You're right. An application will see two 23:59:59 timestamps (in Linux anyway) because the clock is stepped back by 1 s during an addition.
In ntp.c second_overflow() it says/*
* Leap second processing. If in leap-insert state at the end of the
* day, the system clock is set back one second; if in leap-delete
* state, the system clock is set ahead one second.
*/ and at the time the leap second goes in
case TIME_INS:
if (secs % 86400 == 0) {
leap = -1;
time_state = TIME_OOP;
time_tai++;
printk(KERN NOTICE "Clock: inserting leap second 23:59:60 UTC\n");
}
break; and in timekeeping.c it says
leap = second_overflow(timekeeper.xtime.tv_sec);
timekeeper.xtime.tv_sec += leap;
timekeeper.wall_to_monotonic.tv_sec -= leap; where xtime is the "current time"
The wall clock time is still useable if you also use adjtimex() (on Linux anyway) to check whether or not there is a leap second in progress. If you want to compute a delta for some event external to your application like a file update then you're going to have to
use wall clock time. And you're also going to need a table of historical leap seconds if the event was a really long time ago.
"Assuming an average of one leap second per year, it would take 300 years to accumulate just a measly 5 minutes of difference."
It's a bit faster than this because the tidal slowing of the earth;s rotation increases the discrepancy by about 1 ms per day per century
(ie after 100 years, the average day is 1 ms longer, so you get an extra leap second every 3 years. And after 200 years, an extra leap
second every 18 months and so on).
Oops, now I see what you meant. When I said that GPS was not good enough for this application, I was referring to VLBI, not synchronizing a phone network.
Not quite sure what you're saying. GPS satellites do have good clocks on board - rubidium and cesium atomic clocks - and these clocks are steered from the ground by a very large ensemble of atomic clocks including hydrogen masers. The proBlem is transferring this to a ground station. The ionosphere and troposphere introduce short term noise that degrades timing references that you can derive from GPS. GPS broadcasts information that allows correction for these effects but this is of course via a model. You can average out some of the residual noise but you then want a good oscillator to flywheel on. The end result is an oscillator that is good to about 1 part in 10^12.
CDMA base stations typically used to have a GPSDO ie a GPS receiver disciplining a rubidium or good quartz clock because of timing and holdover (how long you can run if GPS signals are lost) requirements.
Disclaimer: I may or may not be working on a project connected with the SKA:-)
GPS does not provide a good enough time reference for an application like this.
Typically you need a hydrogen maser; these cost about $300K. The problem is that GPS has pretty poor short term stability - about +- 20 ns at 1 s for a low cost timing receiver. Averaged over one day GPS gives you a decent frequency reference but to average, you need another oscillator like a rubidium atomic clock. The rubidium gives you better short term stability and then you improve its long term stability by comparing it with GPS and adjusting it. But a rubidium isn't good enough either for the application.
Providing suitable timing references to a distributed system is an active area of research.
The paper "Phase transfer..."
http://www.skatelescope.org/publications/
gives you an idea of the timing requirements.
The problem with dumping unwanted NTP traffic is that the clients do not necessarily respect ntpd's 'bugger off' responses like a 'kiss off death' packet. This has led to many problems with public NTP servers being swamped by traffic from poorly written NTP clients. Blocking some clients simply causes them to increase their polling rate !
BTW ISC simply hosts the ntpd project, it does not run it. ntpd is developed and maintained by David Mills, the author of ntpd, and a group of volunteers.
>>NTP has the massive advantage of working anywhere you have a network connection and not requiring expensive hardware (GPS hardware you can attach to a PC & match the reliability of NTP is not your yum-cha $75 GPS unit)
This is right.
Most GPS receivers are not suitable for timing applications and will do rather worse than NTP under usual conditions. Typically, the receiver won't even have a 1 pps output; timing information is output as a serial time code, once per second, usually with a significant delay and jitter. Calibrating the delay is difficult without a trusted, external reference. Nonetheless, there are some cheap OEM receivers like the Trimble Resolution T that have a good 1 pps. But that $75 receiver doesn't come in a box or even with a power supply. So be prepared to use a soldering iron.
As another poster said, NTP can do sub-millisecond on a LAN. Jitter is usually down at the 100 microsecond level. I administer a network of NTP servers across Australia, and see mean offsets between servers of a few hundred microseconds. Of course, there are outliers, and occasional asymmetries in the network paths (network delays are compensated by dividing the round trip delay by two so asymmetric network paths result in spurious offsets) of one or two milliseconds.
The crystals used as the oscillators in PC clocks just aren't very good. The purpose of a watch is to keep time so naturally a good quartz crystal is used. Typically a watch will be good to 1 second over a week or two. The purpose of a PC is to post to Slashdot, so cheap crystals are used and these typically are good to only about 1 second per day. Higher end workstatsions like Sun used to have better crystals; I don't know what they're like now though.
Slashdot Mirror
There's a mistake in your calculation. As you say, a 1 m^2 panel produces about 200 W of power. But for ten hours of sunlight that's 2 kWh of energy. So everything improves by a factor of ten.
From TFA:
In any case, I wonder if someone could combine all that with the 36 dramatic situations and a few other components, and create a program that writes stories....
Someone has ... every Hollywood studio has it running on their server farms
I think your summary is right. Skimming the article
http://arxiv.org/abs/1309.0005
I get the same impression. In the paper they say that you have to be careful to design your tests to catch all the errors that would affect the answer. The summary doesn't say it, but one significant aspect of the work is that it is the first experimental demonstration of verification of a quantum computation.
GNSS receivers don' t use change in position to measure speed. They use the Doppler shift of the GNSS carrier signal ie a frequency measurement and this can be done accurately. Typically, accuracies of about 0.1 km/h are specified by the manufacturer. The usual caveats about satellite visibility apply.
Where I work, a government scientific organisation, you can be promoted according to either skill or responsibility, at least to a point. So there are instances of someone supervising half a dozen people, several of whom are employed at the same level as the supervisor. The management path is a bit easier though, and promotion on skill alone pretty much tops out at the level equivalent to supervising half a dozen people.
A friend who works at a large company said that they had two promotion paths too: management or technical skill.
From the article : "The problem is that about 40 percent or more of retail shoppers walk out without finding what they want. But in half of those cases, the product actually was in stock.”
Let me fix that: The problem is that about 40 percent or more of retail shoppers walk out without finding what they want because the store is understaffed, and the few staff on the floor are lowly-paid, inexperienced casuals.
Not all ion clocks are optical. Linear ion trap microwave clocks based on Yb and Hg were developed in the 90s. Some Hg clocks operated as part of the NASA Deep Space Network for a number of years and there's currently an active project to develop a highly miniaturised Yb clock. So the summary should say that lattice clocks can beat single ion clocks on QPN and fountains because optical beats microwave.
Big M= 1000000 (like in megohms)
Little k =.1000 (like in kilograms)
But your confusion is understandable, given the failure of Americans to grasp the metric system (humour)
Actually come to think of it, we should really write $100M as 100M$.
All those things that a supercomputer could do 20 years ago ... they got done.
So that powerful tablet is doomed to executing Angry Birds because the interesting
problems that might create economic wealth still need a supercomputer and
always will.
... because we'll still be picking through the smoking ruins of the NTP-time rollover in 2036 :-)
Not sure what you mean here.
Are you referring to a systematic disagreement between the German and Japanese measurements of the Avogadro spheres that is not accommodated by the estimated uncertainties ?
It doesn't work that way.
In the case of the Avogadro sphere, for example, you count the number of atoms of Si 28 and then choose a certain number to be equal to 1 kg, this number being chosen to give agreement with the prototype kg held by the BIPM in Paris. This in effect defines the Avogadro constant.
Well,there is one proposed.
This is the Avogadro Project, one of two candidates for a redefinition of the kg, the other
being the Watt balance.
You take a lump of isotopically pure crystalline Si (Si 28) and optically polish it to a 'perfect' sphere.
You then use very accurate laser interferometry to measure the volume of the sphere (and with a suitable set
of measurements and model you can correct for any residual non-sphericity)
You use X-ray diffraction to measure the lattice spacing. You can now calculate the number of atoms
in the sphere. There are also corrections for the oxide layer at the surface,residual impurities etc.
The nice thing, apart from the kg being defined by dimensional measurements (which are then traceable to the SI second) , is that if you chip your kg standard, you just repolish it and remeasure it.
You then define what one kg is by saying a certain number of Si 28 atoms is equal to 1 kg. This number would be chosen to agree as closely as possible with the current definition of the kg. This process is similar to the way the second was redefined, from an astronomically defined value to a value defined by a microwave transition in the caesium atom.
.. and I work in a guvmint department where XP+Office2003 is the standard install image ...
I was doing leap second testing in the last month and I'm pretty sure that date
returns
23:59:58
23:59:59
23:59:59
00:00:00
as you go through the leap second addition
(Un)fortunately, not at work so I can't double check but a quick look at the date source code suggests that this is indeed
its behaviour on Linux.
You're right.
An application will see two 23:59:59 timestamps (in Linux anyway) because the
clock is stepped back by 1 s during an addition.
In ntp.c second_overflow() it says /*
* Leap second processing. If in leap-insert state at the end of the
* day, the system clock is set back one second; if in leap-delete
* state, the system clock is set ahead one second.
*/
and at the time the leap second goes in
case TIME_INS:
if (secs % 86400 == 0) {
leap = -1;
time_state = TIME_OOP;
time_tai++;
printk(KERN NOTICE "Clock: inserting leap second 23:59:60 UTC\n");
}
break;
and in timekeeping.c it says
leap = second_overflow(timekeeper.xtime.tv_sec);
timekeeper.xtime.tv_sec += leap;
timekeeper.wall_to_monotonic.tv_sec -= leap;
where xtime is the "current time"
The wall clock time is still useable if you also use adjtimex() (on Linux anyway) to check whether or not there is a leap second in progress. If you want to compute a delta for some event external to your application like a file update then you're going to have to use wall clock time. And you're also going to need a table of historical leap seconds if the event was a really long time ago.
"Assuming an average of one leap second per year, it would take 300 years to accumulate just a measly 5 minutes of difference." It's a bit faster than this because the tidal slowing of the earth;s rotation increases the discrepancy by about 1 ms per day per century (ie after 100 years, the average day is 1 ms longer, so you get an extra leap second every 3 years. And after 200 years, an extra leap second every 18 months and so on).
umm maybe you had better lay off the crack. 100 000 x $650 = $65 000 000.
Oops, now I see what you meant. When I said that GPS was not good enough for this application, I was referring to VLBI, not synchronizing a phone network.
Not quite sure what you're saying. GPS satellites do have good clocks on board - rubidium and cesium atomic clocks - and these clocks are steered from the ground by a very large ensemble of atomic clocks including hydrogen masers. The proBlem is transferring this to a ground station. The ionosphere and troposphere introduce short term noise that degrades timing references that you can derive from GPS. GPS broadcasts information that allows correction for these effects but this is of course via a model. You can average out some of the residual noise but you then want a good oscillator to flywheel on. The end result is an oscillator that is good to about 1 part in 10^12. CDMA base stations typically used to have a GPSDO ie a GPS receiver disciplining a rubidium or good quartz clock because of timing and holdover (how long you can run if GPS signals are lost) requirements. Disclaimer: I may or may not be working on a project connected with the SKA :-)
GPS does not provide a good enough time reference for an application like this. Typically you need a hydrogen maser; these cost about $300K. The problem is that GPS has pretty poor short term stability - about +- 20 ns at 1 s for a low cost timing receiver. Averaged over one day GPS gives you a decent frequency reference but to average, you need another oscillator like a rubidium atomic clock. The rubidium gives you better short term stability and then you improve its long term stability by comparing it with GPS and adjusting it. But a rubidium isn't good enough either for the application. Providing suitable timing references to a distributed system is an active area of research. The paper "Phase transfer ..."
http://www.skatelescope.org/publications/
gives you an idea of the timing requirements.
The problem with dumping unwanted NTP traffic is that the clients do not necessarily respect ntpd's 'bugger off' responses like a 'kiss off death' packet. This has led to many problems with public NTP servers being swamped by traffic from poorly written NTP clients. Blocking some clients simply causes them to increase their polling rate !
BTW ISC simply hosts the ntpd project, it does not run it. ntpd is developed and maintained by David Mills, the author of ntpd, and a group of volunteers.
>>NTP has the massive advantage of working anywhere you have a network connection and not requiring expensive hardware (GPS hardware you can attach to a PC & match the reliability of NTP is not your yum-cha $75 GPS unit)
This is right.
Most GPS receivers are not suitable for timing applications and will do rather worse than NTP under usual conditions. Typically, the receiver won't even have a 1 pps output; timing information is output as a serial time code, once per second, usually with a significant delay and jitter. Calibrating the delay is difficult without a trusted, external reference. Nonetheless, there are some cheap OEM receivers like the Trimble Resolution T that have a good 1 pps. But that $75 receiver doesn't come in a box or even with a power supply. So be prepared to use a soldering iron.
As another poster said, NTP can do sub-millisecond on a LAN. Jitter is usually down at the 100 microsecond level. I administer a network of NTP servers across Australia, and see mean offsets between servers of a few hundred microseconds. Of course, there are outliers, and occasional asymmetries in the network paths (network delays are compensated by dividing the round trip delay by two so asymmetric network paths result in spurious offsets) of one or two milliseconds.
The crystals used as the oscillators in PC clocks just aren't very good. The purpose of a watch is to keep time so naturally a good quartz crystal is used. Typically a watch will be good to 1 second over a week or two. The purpose of a PC is to post to Slashdot, so cheap crystals are used and these typically are good to only about 1 second per day. Higher end workstatsions like Sun used to have better crystals; I don't know what they're like now though.