Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Turkish Air 1951 crash - the dirty truth
165 views
Skip to first unread message
EricP
Apr 27, 2012, 1:48:07 AM4/27/12
to
TK1951 crashed in 2009 in Amsterdam when the computers idled the
engines while still 350 feet in the air, killing 9 including the pilots.
The report focuses on the pilots and the radar altimeters as the faults.
The final report is available here (228 pages):
http://www.onderzoeksraad.nl/docs/rapporten/Rapport_TA_ENG_web.pdf
The automated control systems involved, by FAA law, are required
to be dual redundant, ultra reliable, life critical systems.
Prior to reading this I was under the impression that
"dual redundant system" mean something loosely similar to the
shuttle design... one component fails and others take over.
Subsystems comparing values and bring problems to human attention.
But that is not how these work.
In my opinion, it is appalling how badly designed these
system were in so many respects, from human ergonomics,
to architecture, design, to not testing failure modes.
Systems that don't talk to each other, or compare values,
or compare decisions, major automatic mode changes with
little indication to humans that it has occurred.
One subsystem tried to fly while another tried to land,
without this even being detected.
I draw interested parties attention to sections:
5.2 Technology
5.4.1 Peculiarities before the ILS approach
5.4.2 Peculiarities during the ILS approach
Appendix Q: Automatic flight system investigation
From the report:
"The aircraft involved in the accident was being flown by the
first officer, who was sitting on the right-hand side.
His primary flight display showed the readings measured by the
right radio altimeter system. The right-hand autopilot was in use and,
once air traffic control had provided a heading and altitude to be flown,
it was in the ‘altitude hold’ mode in order to maintain that altitude.
During the approach, the left radio altimeter system displayed an
incorrect height of -8 feet. This could be seen on the captain’s
(left-hand) primary flight display. The first officer’s (right-hand)
primary flight display, by contrast, indicated the correct height,
as provided by the right-hand system. The lefthand radio altimeter system,
however, categorised the erroneous altitude reading as a correct one,
and did not record any error. This is why there was no transfer to
the right-hand radio altimeter system. In turn, this meant that it
was the erroneous altitude reading that was used by various aircraft
systems, including the autothrottle. The crew were unaware of this,
and could not have known about it. The manuals for use during the flight
did not contain any procedures for errors in the radio altimeter system.
In addition, the training that the pilots had undergone did not include
any detailed system information that would have allowed them to
understand the significance of the problem
When the aircraft started to follow the glidepath (the ideal path to
the runway) because of the incorrect altitude reading, the autothrottle
moved into the ‘retard flare’ mode. This mode is normally only activated
in the final phase of the landing, below 27 feet. This was possible
because the other preconditions had also been met, including flaps
at (minimum) position 15. The thrust from both engines was accordingly
reduced to a minimum value (approach idle). This mode was shown on the
primary flight displays as ‘RETARD’. However, the right hand autopilot,
which was activated, was receiving the correct altitude from the
right-hand radio altimeter system. Thus the autopilot attempted to
keep the aircraft flying on the glide path for as long as possible.
This meant that the aircraft’s nose continued to rise, creating an
increasing angle of attack of the wings. This was necessary
in order to maintain the same lift as the airspeed reduced.
In the first instance, the pilots’ only indication that the
autothrottle would no longer maintain the pre-selected speed of
144 knots was the RETARD display. When the speed fell below this
value at a height of 750 feet, they would have been able to see
this on the airspeed indicator on the primary flight displays.
When subsequently, the airspeed reached 126 knots, the frame of the
airspeed indicator also changed colour and started to flash.
The artificial horizon also showed that the nose attitude of the
aircraft was becoming far too high. The cockpit crew did not respond
to these indications and warnings. The reduction in speed and excessively
high pitch attitude of the aircraft were not recognised until the approach
to stall warning (stick shaker) went off at an altitude of 460 feet.
This warning is activated shortly before the aircraft reaches a stall
situation. In a stall situation the wings of the aircraft are not
providing sufficient lift and the aircraft cannot fly anymore.
If the prescribed recovery procedure - i.e. selecting full engine power and
reducing the pitch attitude of the aircraft - is implemented correctly
and immediately when the stick shaker starts, then the aircraft will
continue to fly normally. Boeing’s procedures also prescribe that the
throttle levers should be pushed fully forward in such a case.
The first officer responded immediately to the stick shaker by pushing
the control column forward and also pushing the throttle levers forward.
The captain however, also responded to the stick shaker commencing by
taking over control. Assumingly the result of this was that the first
officer’s selection of thrust was interrupted. The result of this was
that the autothrottle, which was not yet switched off, immediately pulled
the throttle levers back again to the position where the engines
were not providing any significant thrust. Once the captain had taken
over control, the autothrottle was disconnected, but no thrust was
selected at that point. Nine seconds after the commencement of the first
approach to stall warning, the throttle levers were pushed fully forward,
but at that point the aircraft had already stalled and the height
remaining, of about 350 feet, was insufficientfor a recovery."
Eric
engines while still 350 feet in the air, killing 9 including the pilots.
The report focuses on the pilots and the radar altimeters as the faults.
The final report is available here (228 pages):
http://www.onderzoeksraad.nl/docs/rapporten/Rapport_TA_ENG_web.pdf
The automated control systems involved, by FAA law, are required
to be dual redundant, ultra reliable, life critical systems.
Prior to reading this I was under the impression that
"dual redundant system" mean something loosely similar to the
shuttle design... one component fails and others take over.
Subsystems comparing values and bring problems to human attention.
But that is not how these work.
In my opinion, it is appalling how badly designed these
system were in so many respects, from human ergonomics,
to architecture, design, to not testing failure modes.
Systems that don't talk to each other, or compare values,
or compare decisions, major automatic mode changes with
little indication to humans that it has occurred.
One subsystem tried to fly while another tried to land,
without this even being detected.
I draw interested parties attention to sections:
5.2 Technology
5.4.1 Peculiarities before the ILS approach
5.4.2 Peculiarities during the ILS approach
Appendix Q: Automatic flight system investigation
From the report:
"The aircraft involved in the accident was being flown by the
first officer, who was sitting on the right-hand side.
His primary flight display showed the readings measured by the
right radio altimeter system. The right-hand autopilot was in use and,
once air traffic control had provided a heading and altitude to be flown,
it was in the ‘altitude hold’ mode in order to maintain that altitude.
During the approach, the left radio altimeter system displayed an
incorrect height of -8 feet. This could be seen on the captain’s
(left-hand) primary flight display. The first officer’s (right-hand)
primary flight display, by contrast, indicated the correct height,
as provided by the right-hand system. The lefthand radio altimeter system,
however, categorised the erroneous altitude reading as a correct one,
and did not record any error. This is why there was no transfer to
the right-hand radio altimeter system. In turn, this meant that it
was the erroneous altitude reading that was used by various aircraft
systems, including the autothrottle. The crew were unaware of this,
and could not have known about it. The manuals for use during the flight
did not contain any procedures for errors in the radio altimeter system.
In addition, the training that the pilots had undergone did not include
any detailed system information that would have allowed them to
understand the significance of the problem
When the aircraft started to follow the glidepath (the ideal path to
the runway) because of the incorrect altitude reading, the autothrottle
moved into the ‘retard flare’ mode. This mode is normally only activated
in the final phase of the landing, below 27 feet. This was possible
because the other preconditions had also been met, including flaps
at (minimum) position 15. The thrust from both engines was accordingly
reduced to a minimum value (approach idle). This mode was shown on the
primary flight displays as ‘RETARD’. However, the right hand autopilot,
which was activated, was receiving the correct altitude from the
right-hand radio altimeter system. Thus the autopilot attempted to
keep the aircraft flying on the glide path for as long as possible.
This meant that the aircraft’s nose continued to rise, creating an
increasing angle of attack of the wings. This was necessary
in order to maintain the same lift as the airspeed reduced.
In the first instance, the pilots’ only indication that the
autothrottle would no longer maintain the pre-selected speed of
144 knots was the RETARD display. When the speed fell below this
value at a height of 750 feet, they would have been able to see
this on the airspeed indicator on the primary flight displays.
When subsequently, the airspeed reached 126 knots, the frame of the
airspeed indicator also changed colour and started to flash.
The artificial horizon also showed that the nose attitude of the
aircraft was becoming far too high. The cockpit crew did not respond
to these indications and warnings. The reduction in speed and excessively
high pitch attitude of the aircraft were not recognised until the approach
to stall warning (stick shaker) went off at an altitude of 460 feet.
This warning is activated shortly before the aircraft reaches a stall
situation. In a stall situation the wings of the aircraft are not
providing sufficient lift and the aircraft cannot fly anymore.
If the prescribed recovery procedure - i.e. selecting full engine power and
reducing the pitch attitude of the aircraft - is implemented correctly
and immediately when the stick shaker starts, then the aircraft will
continue to fly normally. Boeing’s procedures also prescribe that the
throttle levers should be pushed fully forward in such a case.
The first officer responded immediately to the stick shaker by pushing
the control column forward and also pushing the throttle levers forward.
The captain however, also responded to the stick shaker commencing by
taking over control. Assumingly the result of this was that the first
officer’s selection of thrust was interrupted. The result of this was
that the autothrottle, which was not yet switched off, immediately pulled
the throttle levers back again to the position where the engines
were not providing any significant thrust. Once the captain had taken
over control, the autothrottle was disconnected, but no thrust was
selected at that point. Nine seconds after the commencement of the first
approach to stall warning, the throttle levers were pushed fully forward,
but at that point the aircraft had already stalled and the height
remaining, of about 350 feet, was insufficientfor a recovery."
Eric
Robert Myers
May 1, 2012, 5:34:48 PM5/1/12
to
On 4/27/2012 1:48 AM, EricP wrote:
>
> The first officer responded immediately to the stick shaker by pushing
> the control column forward and also pushing the throttle levers forward.
> The captain however, also responded to the stick shaker commencing by
> taking over control. Assumingly the result of this was that the first
> officer’s selection of thrust was interrupted. The result of this was
> that the autothrottle, which was not yet switched off, immediately pulled
> the throttle levers back again to the position where the engines
> were not providing any significant thrust. Once the captain had taken
> over control, the autothrottle was disconnected, but no thrust was
> selected at that point. Nine seconds after the commencement of the first
> approach to stall warning, the throttle levers were pushed fully forward,
> but at that point the aircraft had already stalled and the height
> remaining, of about 350 feet, was insufficientfor a recovery."
>
The crash of Air France 447 also involved left-seat/right-seat issues.
>
> The first officer responded immediately to the stick shaker by pushing
> the control column forward and also pushing the throttle levers forward.
> The captain however, also responded to the stick shaker commencing by
> taking over control. Assumingly the result of this was that the first
> officer’s selection of thrust was interrupted. The result of this was
> that the autothrottle, which was not yet switched off, immediately pulled
> the throttle levers back again to the position where the engines
> were not providing any significant thrust. Once the captain had taken
> over control, the autothrottle was disconnected, but no thrust was
> selected at that point. Nine seconds after the commencement of the first
> approach to stall warning, the throttle levers were pushed fully forward,
> but at that point the aircraft had already stalled and the height
> remaining, of about 350 feet, was insufficientfor a recovery."
>
The discussions of that crash that I've read have been disheartening.
It appears to me that fly-by-rote would be a more apt way of describing
the current approach to piloting aircraft than fly-by-wire. Perhaps
that's inevitable: the pilots don't necessarily seem to understand
either the physics or the intentions of the design or the inherent
limitations of the design of the aircraft they are flying. I don't know
how you design around no one really knowing what they are doing.
Robert.
EricP
May 2, 2012, 2:40:16 PM5/2/12
to
the report does not make me think that was the root of the problem.
I was referring to the repeated use of single-point-of-failure design.
The single-point-of-failure style architecture allowed a single
erroneous device, the radar altimeter (RA), to trigger the crash.
Illustration 2 on page 22 shows the connections.
This is not a fail-passive design because there is no ability
to detect errors. There was an error, and it crashed.
(Later 737-800 versions used a Rockwell Collins EDFCS which
does compare the RA values and could be fail-passive.)
The RA had history of hundreds of operational problems.
As Appendix N shows, there were 6 prior incidents where a single
erroneous RA caused a hazardous situation. In those cases the pilots
caught the problem and averted disaster. This leads me to question
whether, rather than this being a problem with these pilots,
if this wasn't the design being an accident waiting to happen.
The plane in question was built in 2002, and plenty was known
at that time about how to do reliable designs.
As Illustration 2 shows, the autothrottle received inputs from both RA's.
Even though it had both inputs, it did not compare the values.
It used only the left value and ignored the right unless the
left RA sent a 'fail warn' status - a single-fail prone design.
The left RA sent a -8 value, a valid, but erroneous, value.
(-8 is the value the RA shows when the plane is on the runway.
0 is the value when the wheels just touch down with no weight on them.)
Furthermore, that there is only a single autothrottle computer is
also a single-fail prone design, though not a factor in this crash.
Furthermore, the left RA only connects to the left autopilot,
the right RA to the right autopilot. This is a semi-redundant design,
in that there are 2 autopilots, and might be a fail-passive design
if the autopilots talked to each other and compared results.
However as each connects to a single RA, a single autopilot is
unable to check its own inputs and detect an erroneous value.
So it continues in some manner to be a single-fail prone design.
The human interface issues possibly made it difficult
for the pilots to detect the problem in time.
This all makes me wonder how many other devices,
such as air speed pitots, are connected in similar fashion.
Newer autopilot and autothrottle designs are supposedly triple
redundant, fail-operational (available at extra cost, of course).
I would hope also that all redundant inputs go to all computers,
that the values are all cross checked, and that the computers
all compare each others results.
Eric
Robert Myers
May 2, 2012, 9:36:50 PM5/2/12
to
your objection to the design. I'm not a pilot, so I don't know whether
what I think a pilot should be able to do under pressure is reasonable,
but the situation was recoverable right up until the stall warning
sounded. At that point, the pilot took control and apparently made
incorrect assumptions about how such a handoff would affect the aircraft
controls--in particular, the throttle. Those incorrect assumptions were
fatal.
Robert.
MitchAlsup
May 3, 2012, 1:11:02 PM5/3/12
to
What this tragedy reminds me of is all those groups trying to make cars that drive themselves, and why I don't want to own a car like that.
Mitch
Mitch
nm...@cam.ac.uk
May 3, 2012, 2:13:42 PM5/3/12
to
In article <21309082.1474.1336065062959.JavaMail.geo-discussion-forums@ynjn4>,
Regards,
Nick Maclaren.
MitchAlsup <Mitch...@aol.com> wrote:
>
> What this tragedy reminds me of is all those groups trying to
>
> What this tragedy reminds me of is all those groups trying to
> drive themselves, and why I don't want to own a car like that.
It adds a new meaning to The Blue Screen of Death, certainly.
Regards,
Nick Maclaren.
Casper H.S. Dik
May 3, 2012, 2:30:44 PM5/3/12
to
MitchAlsup <Mitch...@aol.com> writes:
>What this tragedy reminds me of is all those groups trying to make cars that drive themselves, and why I don't want to own a car like that.
I wouldn't want other people to own such a car either.
>What this tragedy reminds me of is all those groups trying to make cars that drive themselves, and why I don't want to own a car like that.
It is unfortunate that when two redundant instruments have clearly different readings,
then someone should inform the pilots.
Casper
van...@vsta.org
May 3, 2012, 2:38:18 PM5/3/12
to
MitchAlsup <Mitch...@aol.com> wrote:
> What this tragedy reminds me of is all those groups trying to make cars
> that drive themselves, and why I don't want to own a car like that.
When I mentally graph quality of average driver over time, and overlay with
> What this tragedy reminds me of is all those groups trying to make cars
> that drive themselves, and why I don't want to own a car like that.
quality of Dr. Thrun's software over time, I end up being pretty certain that
the latter's ascending line crosses the former's descending line in the
foreseeable future. At which point, yes, sign me up.
--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
Terje Mathisen
May 4, 2012, 3:06:37 AM5/4/12
to
van...@vsta.org wrote:
> MitchAlsup<Mitch...@aol.com> wrote:
>> What this tragedy reminds me of is all those groups trying to make cars
>> that drive themselves, and why I don't want to own a car like that.
>
> When I mentally graph quality of average driver over time, and overlay with
> quality of Dr. Thrun's software over time, I end up being pretty certain that
> the latter's ascending line crosses the former's descending line in the
> foreseeable future. At which point, yes, sign me up.
>
I'm pretty sure those two lines have crossed already:
> MitchAlsup<Mitch...@aol.com> wrote:
>> What this tragedy reminds me of is all those groups trying to make cars
>> that drive themselves, and why I don't want to own a car like that.
>
> When I mentally graph quality of average driver over time, and overlay with
> quality of Dr. Thrun's software over time, I end up being pretty certain that
> the latter's ascending line crosses the former's descending line in the
> foreseeable future. At which point, yes, sign me up.
>
Even if the Google cars are biased (they have an interested and
presumably very observant "pilot" at all times, ready to take over),
they have passed the average driving distance per serious accident,
haven't they?
Terje
PS. Here in Norway the large amount of roads without any centerline (or
lines at all) would presumably make the lane-keeping sw work a lot
harder. OTOH from what I remember from the reports of the driverless
desert crossing, some cars were very successful by simply imitating what
the car in front did: Images of lemmings following each other of a cliff
comes to mind...
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
Andy (Super) Glew
May 4, 2012, 3:13:11 AM5/4/12
to van...@vsta.org
On 5/3/2012 11:38 AM, van...@vsta.org wrote:
> MitchAlsup<Mitch...@aol.com> wrote:
>> What this tragedy reminds me of is all those groups trying to make cars
>> that drive themselves, and why I don't want to own a car like that.
>
> When I mentally graph quality of average driver over time, and overlay with
> quality of Dr. Thrun's software over time, I end up being pretty certain that
> the latter's ascending line crosses the former's descending line in the
> foreseeable future. At which point, yes, sign me up.
Having spent much of much of my life in 2009-2011 commuting 200 miles
> MitchAlsup<Mitch...@aol.com> wrote:
>> What this tragedy reminds me of is all those groups trying to make cars
>> that drive themselves, and why I don't want to own a car like that.
>
> When I mentally graph quality of average driver over time, and overlay with
> quality of Dr. Thrun's software over time, I end up being pretty certain that
> the latter's ascending line crosses the former's descending line in the
> foreseeable future. At which point, yes, sign me up.
between Portland (Hillsboro) and Seattle (Bellevue) at least once a
week, sometimes two or three times, I would look forward to automated
driving. At least for long highway stretches, which are probably its
best case.
(For the Europeans: yes, I tried the train. Took at least 2 hours
longer. More so if I included time to get to train. Several times 5
*hours* late because of landslides. (No Mussolini here). I also tried
multiperson shuttle (went out of business for lack of customers). And
bus. One might hope that automated driving may be more efficient than non.)
Andy (Super) Glew
May 4, 2012, 3:31:03 AM5/4/12
to
Although, the commute might not have been so bad if I could have worked
on the train. Amtrak added wifi only after I stopped commuting. Cell
phone connectivity was lousy on the train (at least for my AT&T phone).
Terje Mathisen
May 4, 2012, 6:01:31 AM5/4/12
to
Andy (Super) Glew wrote:
> (For the Europeans: yes, I tried the train. Took at least 2 hours
> longer. More so if I included time to get to train. Several times 5
> *hours* late because of landslides. (No Mussolini here). I also tried
> multiperson shuttle (went out of business for lack of customers). And
> bus. One might hope that automated driving may be more efficient than non.)
>
As some of you know, my wife Tone is (since a year ago) responsible for
> (For the Europeans: yes, I tried the train. Took at least 2 hours
> longer. More so if I included time to get to train. Several times 5
> *hours* late because of landslides. (No Mussolini here). I also tried
> multiperson shuttle (went out of business for lack of customers). And
> bus. One might hope that automated driving may be more efficient than non.)
>
making all the trains in Norway run on schedule:
She has told me that the Mussolini story is somewhat misleading:
He made the trains run on schedule by simply modifying all the
schedules, making them significantly slower!
I.e. by including _lots_ of slack time for each train, it was suddenly
easy to follow said (very relaxed) schedule.
Terje
Paul A. Clayton
May 4, 2012, 9:35:57 AM5/4/12
to
On May 4, 6:01 am, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
[snip]
For public transportation, having a very high confidence of
not having to wait--or even just having a predictable wait
time--seems more attractive than, say, 15% longer transit
time.
This effect also applies for human-computer interfaces.
If the computer response is not "instantaneous", then a
predictable delay is often better. I think it can even
be the case that for some response times, delaying the
response (at least in terms of actively alerting the
user of completion--still allowing the user to "poll"
for completed requests) would be preferred to avoid
excessive context switching.
WRT computer-driven cars, I would actually prefer such
(for at least one wrong reason: I seem to feel excessively
stressed about the responsibility involved--simple
mistakes can do expensive damage to my own property
(which is painfully wasteful as well as just costly),
damage to others' property (likewise inducing guilt and
cost), or hurting--even killing--other people). (Yes,
I am sick, but at least it does not seem to be
contagious.)
It seems that public transportation costs could be
reduced with computer-driven vehicles. Public
transportation vehicles would not require the same
fully general driving capabilities, though they would
probably require higher safety standards, being
high occupancy vehicles. Perhaps cargo transport
would be a reasonable early target for automation
(limited routes, potentially more flexibility in
scheduling, and no passengers [only external potential
human accident victims]).
[snip]
> As some of you know, my wife Tone is (since a year ago) responsible for
> making all the trains in Norway run on schedule:
>
> She has told me that the Mussolini story is somewhat misleading:
>
> He made the trains run on schedule by simply modifying all the
> schedules, making them significantly slower!
>
> I.e. by including _lots_ of slack time for each train, it was suddenly
> easy to follow said (very relaxed) schedule.
Sometimes consistency/predictability is better than faster.
> making all the trains in Norway run on schedule:
>
> She has told me that the Mussolini story is somewhat misleading:
>
> He made the trains run on schedule by simply modifying all the
> schedules, making them significantly slower!
>
> I.e. by including _lots_ of slack time for each train, it was suddenly
> easy to follow said (very relaxed) schedule.
For public transportation, having a very high confidence of
not having to wait--or even just having a predictable wait
time--seems more attractive than, say, 15% longer transit
time.
This effect also applies for human-computer interfaces.
If the computer response is not "instantaneous", then a
predictable delay is often better. I think it can even
be the case that for some response times, delaying the
response (at least in terms of actively alerting the
user of completion--still allowing the user to "poll"
for completed requests) would be preferred to avoid
excessive context switching.
WRT computer-driven cars, I would actually prefer such
(for at least one wrong reason: I seem to feel excessively
stressed about the responsibility involved--simple
mistakes can do expensive damage to my own property
(which is painfully wasteful as well as just costly),
damage to others' property (likewise inducing guilt and
cost), or hurting--even killing--other people). (Yes,
I am sick, but at least it does not seem to be
contagious.)
It seems that public transportation costs could be
reduced with computer-driven vehicles. Public
transportation vehicles would not require the same
fully general driving capabilities, though they would
probably require higher safety standards, being
high occupancy vehicles. Perhaps cargo transport
would be a reasonable early target for automation
(limited routes, potentially more flexibility in
scheduling, and no passengers [only external potential
human accident victims]).
Chris Gray
May 4, 2012, 1:13:13 PM5/4/12
to
Terje Mathisen <"terje.mathisen at tmsw.no"> writes:
> PS. Here in Norway the large amount of roads without any centerline
> (or lines at all) would presumably make the lane-keeping sw work a lot
> harder. OTOH from what I remember from the reports of the driverless
> desert crossing, some cars were very successful by simply imitating
> what the car in front did: Images of lemmings following each other of
> a cliff comes to mind...
I wonder how they would do on the Hana Road:
> PS. Here in Norway the large amount of roads without any centerline
> (or lines at all) would presumably make the lane-keeping sw work a lot
> harder. OTOH from what I remember from the reports of the driverless
> desert crossing, some cars were very successful by simply imitating
> what the car in front did: Images of lemmings following each other of
> a cliff comes to mind...
http://www.youtube.com/watch?v=5ER2K-ERLlk&feature=fvwrel
(Pick the HD version for best movie.)
When we drove it, we had much better weather and less traffic. Also, the
road gets much more interesting once you get *past* Hana.
Traffic avoidance would be very important there - sometimes you meet
dumptrucks coming your way, and I'll bet there are situations where you
have no choice except to backup to a passing point. It's going to be a
long time before computer drivers can work everywhere!
--
Chris Gray
van...@vsta.org
May 4, 2012, 1:38:40 PM5/4/12
to
Paul A. Clayton <paaron...@gmail.com> wrote:
> Sometimes consistency/predictability is better than faster.
Be careful when you tell bureaucrats that.
> Sometimes consistency/predictability is better than faster.
In California, when a Joint Power Board (multi-county agency) took over
Caltrain, I watched as each successive schedule change made the trains slower
and slower. I remember when several years into the experiment, a friend from
UK was visiting and sat bemused as our Caltrain lumbered slowly but surely up
the Peninsula. She finally commented brightly that it was nice to have
plenty of time to look at the scenery.
This process was continuing when I finally had a chance to move out of
California. I see that something finally happened; Caltrain has somehow
ended up with some express schedules which at least make a pretense of being
something other than an overweight local bus service.
The ultimately predictable train is one which is scheduled to not move.
EricP
May 4, 2012, 2:09:56 PM5/4/12
to
Chris Gray wrote:
>
> I wonder how they would do on the Hana Road:
>
> http://www.youtube.com/watch?v=5ER2K-ERLlk&feature=fvwrel
>
> (Pick the HD version for best movie.)
>
> When we drove it, we had much better weather and less traffic. Also, the
> road gets much more interesting once you get *past* Hana.
>
> Traffic avoidance would be very important there - sometimes you meet
> dumptrucks coming your way, and I'll bet there are situations where you
> have no choice except to backup to a passing point. It's going to be a
> long time before computer drivers can work everywhere!
>
NOVA: The Great Robot Race
>
> I wonder how they would do on the Hana Road:
>
> http://www.youtube.com/watch?v=5ER2K-ERLlk&feature=fvwrel
>
> (Pick the HD version for best movie.)
>
> When we drove it, we had much better weather and less traffic. Also, the
> road gets much more interesting once you get *past* Hana.
>
> Traffic avoidance would be very important there - sometimes you meet
> dumptrucks coming your way, and I'll bet there are situations where you
> have no choice except to backup to a passing point. It's going to be a
> long time before computer drivers can work everywhere!
>
is DARPA's 2004 robot race across the desert (52 minutes)
http://www.youtube.com/watch?v=uoiJeIb0wBA&feature=related
DARPA Urban Challenge
in 2007 robots must abide by California driving laws (37 minutes)
http://www.youtube.com/watch?v=-xibwwNVLgg&feature=related
The Robot Champion of DARPA's Urban Challenge (2.5 minutes)
http://www.youtube.com/watch?v=lULl63ERek0&feature=fvsr
Eric
nm...@cam.ac.uk
May 4, 2012, 3:07:37 PM5/4/12
to
In article <a0iih0...@mid.individual.net>, <van...@vsta.org> wrote:
>Paul A. Clayton <paaron...@gmail.com> wrote:
>
>> Sometimes consistency/predictability is better than faster.
>
>Be careful when you tell bureaucrats that.
>
>In California, when a Joint Power Board (multi-county agency) took over
>Caltrain, I watched as each successive schedule change made the trains slower
>and slower. I remember when several years into the experiment, a friend from
>UK was visiting and sat bemused as our Caltrain lumbered slowly but surely up
>the Peninsula. She finally commented brightly that it was nice to have
>plenty of time to look at the scenery.
>
>Paul A. Clayton <paaron...@gmail.com> wrote:
>
>> Sometimes consistency/predictability is better than faster.
>
>Be careful when you tell bureaucrats that.
>
>In California, when a Joint Power Board (multi-county agency) took over
>Caltrain, I watched as each successive schedule change made the trains slower
>and slower. I remember when several years into the experiment, a friend from
>UK was visiting and sat bemused as our Caltrain lumbered slowly but surely up
>the Peninsula. She finally commented brightly that it was nice to have
>plenty of time to look at the scenery.
>
>The ultimately predictable train is one which is scheduled to not move.
Not in California - too many earthquakes :-)
Regards,
Nick Maclaren.
Tom Gardner
May 4, 2012, 3:41:22 PM5/4/12
to
Chris Gray wrote:
> Terje Mathisen<"terje.mathisen at tmsw.no"> writes:
>
>> PS. Here in Norway the large amount of roads without any centerline
>> (or lines at all) would presumably make the lane-keeping sw work a lot
>> harder. OTOH from what I remember from the reports of the driverless
>> desert crossing, some cars were very successful by simply imitating
>> what the car in front did: Images of lemmings following each other of
>> a cliff comes to mind...
>
> I wonder how they would do on the Hana Road:
>
> http://www.youtube.com/watch?v=5ER2K-ERLlk&feature=fvwrel
Well, in Norway does have the Trollstigen
> Terje Mathisen<"terje.mathisen at tmsw.no"> writes:
>
>> PS. Here in Norway the large amount of roads without any centerline
>> (or lines at all) would presumably make the lane-keeping sw work a lot
>> harder. OTOH from what I remember from the reports of the driverless
>> desert crossing, some cars were very successful by simply imitating
>> what the car in front did: Images of lemmings following each other of
>> a cliff comes to mind...
>
> I wonder how they would do on the Hana Road:
>
> http://www.youtube.com/watch?v=5ER2K-ERLlk&feature=fvwrel
http://www.youtube.com/watch?v=GBkWH-fTLKY
> Traffic avoidance would be very important there - sometimes you meet
> dumptrucks coming your way,
http://www.youtube.com/watch?v=N4glfWBdCEk
> and I'll bet there are situations where you
> have no choice except to backup to a passing point. It's going to be a
> long time before computer drivers can work everywhere!
One also wonders how they would cope when the vehicle's
characteristics suddenly change, e.g. a wheel falls off while
overtaking, as happened to me once.
Terje Mathisen
May 4, 2012, 3:44:22 PM5/4/12
to
Chris Gray wrote:
> I wonder how they would do on the Hana Road:
>
> http://www.youtube.com/watch?v=5ER2K-ERLlk&feature=fvwrel
>
> (Pick the HD version for best movie.)
Nice video, even with a good mount they probably had to do some sw
> I wonder how they would do on the Hana Road:
>
> http://www.youtube.com/watch?v=5ER2K-ERLlk&feature=fvwrel
>
> (Pick the HD version for best movie.)
debouncing to get it so stable.
>
> When we drove it, we had much better weather and less traffic. Also, the
> road gets much more interesting once you get *past* Hana.
>
> Traffic avoidance would be very important there - sometimes you meet
> dumptrucks coming your way, and I'll bet there are situations where you
> have no choice except to backup to a passing point. It's going to be a
> long time before computer drivers can work everywhere!
>
That's actually a very good road.
> When we drove it, we had much better weather and less traffic. Also, the
> road gets much more interesting once you get *past* Hana.
>
> Traffic avoidance would be very important there - sometimes you meet
> dumptrucks coming your way, and I'll bet there are situations where you
> have no choice except to backup to a passing point. It's going to be a
> long time before computer drivers can work everywhere!
>
I'm certain we still have European International Highways (E-nn) here in
Norway which are _far_ worse. :-(
Terje
nm...@cam.ac.uk
May 4, 2012, 4:02:13 PM5/4/12
to
In article <n5od79-...@ntp6.tmsw.no>,
routes in the West Country, Wales and Highlands - which often have
more traffic and worse weather.
>> Traffic avoidance would be very important there - sometimes you meet
>> dumptrucks coming your way, and I'll bet there are situations where you
>> have no choice except to backup to a passing point. It's going to be a
>> long time before computer drivers can work everywhere!
There are still single-track trunk roads in the Highlands, as far as
I recall.
>That's actually a very good road.
Yes. Anyone who can't hack that shouldn't drive in the trickier
parts of Europe :-)
Regards,
Nick Maclaren.
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>Chris Gray wrote:
>> I wonder how they would do on the Hana Road:
>>
>> http://www.youtube.com/watch?v=5ER2K-ERLlk&feature=fvwrel
>
>Chris Gray wrote:
>> I wonder how they would do on the Hana Road:
>>
>> http://www.youtube.com/watch?v=5ER2K-ERLlk&feature=fvwrel
>
>> When we drove it, we had much better weather and less traffic. Also, the
>> road gets much more interesting once you get *past* Hana.
It looked fairly straightforward to me, compared with some of the
>> road gets much more interesting once you get *past* Hana.
routes in the West Country, Wales and Highlands - which often have
more traffic and worse weather.
>> Traffic avoidance would be very important there - sometimes you meet
>> dumptrucks coming your way, and I'll bet there are situations where you
>> have no choice except to backup to a passing point. It's going to be a
>> long time before computer drivers can work everywhere!
I recall.
>That's actually a very good road.
parts of Europe :-)
Regards,
Nick Maclaren.
EricP
May 4, 2012, 7:20:15 PM5/4/12
to
Tom Gardner wrote:
>
> Well, in Norway does have the Trollstigen
> http://www.youtube.com/watch?v=GBkWH-fTLKY
This is one of the best UK Top Gear episodes.
>
> Well, in Norway does have the Trollstigen
> http://www.youtube.com/watch?v=GBkWH-fTLKY
In 2007 s10e01 they went in search of the best driving road in a
Porsche 911 GT3 RS, Lamborghini Gallardo Superleggera and Aston Vantage N24.
They come across it about 25 minutes into the episode.
According to them, it's Davos, Switzerland to Stelvio, Italy via Bormio.
Top Gear Best Driving Road In The World (31 minutes)
http://www.youtube.com/watch?v=3JndYyYbPL0
But in 2009 in S14E01 they found the Transfagarasan highway in Romania
in a Lamborghini Gallardo LP560-4 Spyder, Ferrari California
and Aston Martin DBS Volante. (3.5 minutes)
http://www.topgear.com/uk/videos/brand-new-clip-tg-goes-to-romania-part-6
Eric
Rick Jones
May 4, 2012, 7:26:08 PM5/4/12
to
And any quake large enough to appreciably move a Caltrain probably
means we have bigger worries than the train schedule. (I'm not sure
how much the trains moved during Loma Prieta in 1989 but am guessing
it wasn't very much... certainly
http://www.trainorders.com/discussion/read.php?1,1844920 suggests it)
rick jones
Wonders what a Google self driving car would do if it crossed from
France into the UK by either Ferry or Chunnel...
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
EricP
May 4, 2012, 8:02:34 PM5/4/12
to
Rick Jones wrote:
>
> Wonders what a Google self driving car would do if it crossed from
> France into the UK by either Ferry or Chunnel...
I'm guessing something like the F16 computer that,
>
> Wonders what a Google self driving car would do if it crossed from
> France into the UK by either Ferry or Chunnel...
during testing in simulation, when crossing the equator
flipped the plane over killing the simulated pilot.
http://catless.ncl.ac.uk/Risks/3.44.html
Yep... it'll roll the car.
Eric
Robert Wessel
May 4, 2012, 11:02:21 PM5/4/12
to
On Fri, 04 May 2012 12:01:31 +0200, Terje Mathisen <"terje.mathisen at
tmsw.no"> wrote:
>Andy (Super) Glew wrote:
>> (For the Europeans: yes, I tried the train. Took at least 2 hours
>> longer. More so if I included time to get to train. Several times 5
>> *hours* late because of landslides. (No Mussolini here). I also tried
>> multiperson shuttle (went out of business for lack of customers). And
>> bus. One might hope that automated driving may be more efficient than non.)
>>
>As some of you know, my wife Tone is (since a year ago) responsible for
>making all the trains in Norway run on schedule:
>
>She has told me that the Mussolini story is somewhat misleading:
>
>He made the trains run on schedule by simply modifying all the
>schedules, making them significantly slower!
>
>I.e. by including _lots_ of slack time for each train, it was suddenly
>easy to follow said (very relaxed) schedule.
It's actually more complicated than that. Yes, he "fixed" the
tmsw.no"> wrote:
>Andy (Super) Glew wrote:
>> (For the Europeans: yes, I tried the train. Took at least 2 hours
>> longer. More so if I included time to get to train. Several times 5
>> *hours* late because of landslides. (No Mussolini here). I also tried
>> multiperson shuttle (went out of business for lack of customers). And
>> bus. One might hope that automated driving may be more efficient than non.)
>>
>As some of you know, my wife Tone is (since a year ago) responsible for
>making all the trains in Norway run on schedule:
>
>She has told me that the Mussolini story is somewhat misleading:
>
>He made the trains run on schedule by simply modifying all the
>schedules, making them significantly slower!
>
>I.e. by including _lots_ of slack time for each train, it was suddenly
>easy to follow said (very relaxed) schedule.
schedule. But the train system in Italy was a mess after WWI, and
many repairs were in progress at the time he took office. The
completion of those helped as well. And third, trains were always
reported as running on time, because it reporting to the contrary was
generally not allowed (in fact, it's clearly a myth that the on time
performance was exceptional, or even particularly good).
Somewhat amusingly(?), the Chicago region of the US Postal Service did
the same thing. A long term complaint in the area was that pickup
times listed on mailboxes were grossly optimistic, and USPS internal
statistics backed that up. They promised to fix it, and a couple of
years later announced that the situation had gotten much better. It
was quickly discovered that the major contribution to the "solution"
was changing the pickup times listed on the mailboxes.
Joe Pfeiffer
May 5, 2012, 1:38:06 AM5/5/12
to
reasonable solution. My first concern is that I can predict when the
train will turn up, or the mail will be picked up. Having things happen
quickly in these sorts of circumstances is also very important, but
clearly a lower priority.
Terje Mathisen
May 5, 2012, 4:00:47 AM5/5/12
to
Tom Gardner wrote:
> Chris Gray wrote:
>> Terje Mathisen<"terje.mathisen at tmsw.no"> writes:
>>
>>> PS. Here in Norway the large amount of roads without any centerline
>>> (or lines at all) would presumably make the lane-keeping sw work a lot
>>> harder. OTOH from what I remember from the reports of the driverless
>>> desert crossing, some cars were very successful by simply imitating
>>> what the car in front did: Images of lemmings following each other of
>>> a cliff comes to mind...
>>
>> I wonder how they would do on the Hana Road:
>>
>> http://www.youtube.com/watch?v=5ER2K-ERLlk&feature=fvwrel
>
> Well, in Norway does have the Trollstigen
> http://www.youtube.com/watch?v=GBkWH-fTLKY
Trollstigen (lit: "The Troll's Ladder") is a nice road. :-)
> Chris Gray wrote:
>> Terje Mathisen<"terje.mathisen at tmsw.no"> writes:
>>
>>> PS. Here in Norway the large amount of roads without any centerline
>>> (or lines at all) would presumably make the lane-keeping sw work a lot
>>> harder. OTOH from what I remember from the reports of the driverless
>>> desert crossing, some cars were very successful by simply imitating
>>> what the car in front did: Images of lemmings following each other of
>>> a cliff comes to mind...
>>
>> I wonder how they would do on the Hana Road:
>>
>> http://www.youtube.com/watch?v=5ER2K-ERLlk&feature=fvwrel
>
> Well, in Norway does have the Trollstigen
> http://www.youtube.com/watch?v=GBkWH-fTLKY
2.5 years ago I rode my mountain bike from Åndalsnes (where I was as a
scout troop leader for a national jamboree) up Trollstigen and back down
again.
The most exciting part was that I noticed on my way into the valley that
my brakes didn't grab properly, so I decided to adjust them up at the
top, before riding back down:
Turned out the back brakes were totally worn out, hitting the stops
there was no more adjusting possible, and the front brake was only
marginally better.
I rode all the way down with one foot loose, sliding it on the pavement
when the speed got too high. Not recommended, particularly when meeting
huge tourist buses on the hairpins. :-(
BTW, the old trail which people used before the road was put in still
exists, it has several sections with wires/chains bolted to the rock so
you'll have something to hold on to. On the video that trail is on the
right-hand side of the waterfall/river. The really amazing thing is that
I guy once got ~20 cows up that trail, in order to get them to the next
valley over.
Terje
Tom Gardner
May 5, 2012, 4:27:12 AM5/5/12
to
Robert Wessel wrote:
> And third, trains were always
> reported as running on time, because it reporting to the contrary was
> generally not allowed (in fact, it's clearly a myth that the on time
> performance was exceptional, or even particularly good).
Oh, so they had "British Rail" time too. Many years ago there
> And third, trains were always
> reported as running on time, because it reporting to the contrary was
> generally not allowed (in fact, it's clearly a myth that the on time
> performance was exceptional, or even particularly good).
was a photo in the satirical mag "Private Eye" of a clock on
a railway station showing 19:65. The BR explanation was that
this was allowed when a train was late, and readers confirmed
it was not uncommon.
Tom Gardner
May 5, 2012, 4:33:02 AM5/5/12
to
Joe Pfeiffer wrote:
> Which (both for trains and mailboxes) strikes me as an eminently
> reasonable solution. My first concern is that I can predict when the
> train will turn up, or the mail will be picked up. Having things happen
> quickly in these sorts of circumstances is also very important, but
> clearly a lower priority.
Also true for many other situations, from call centre operators picking
> Which (both for trains and mailboxes) strikes me as an eminently
> reasonable solution. My first concern is that I can predict when the
> train will turn up, or the mail will be picked up. Having things happen
> quickly in these sorts of circumstances is also very important, but
> clearly a lower priority.
up their phone (much better than being interrupted by "your call is
important to us" every 60s), to virtually all hard-realtime systems.
BTW, how do hard-realtime system designed cope with the variability
caused by large caches in modern computers.? Do they simply turn it off?
nm...@cam.ac.uk
May 5, 2012, 4:33:46 AM5/5/12
to
In article <jo1oig$b5n$2...@usenet01.boi.hp.com>,
entirely judgments on your lifestyle - I wonder what they will say
one one of the earthquakes in their area lets rip - probably that
it's the fault of their neighbours :-(
>And any quake large enough to appreciably move a Caltrain probably
>means we have bigger worries than the train schedule.
Apparently there are cases where quite small quakes shook trains
enough to start them rolling and raised the ground enough for
there to be a slope - if that were followed by a long natural
slope, they could go some distance. I can't remember where or
when or even how reliable my source was.
But, harking back to the topic, it is a myth that predictability
always trumps frequency or trip brevity, just as the converse is
a myth. A lot of people need and want to take trips that aren't
scheduled in detail - e.g. getting home when a meeting ends.
Getting the balance right is tricky.
Regards,
Nick Maclaren.
Rick Jones <rick....@hp.com> wrote:
>
>> >The ultimately predictable train is one which is scheduled to not
>> >move.
>
>> Not in California - too many earthquakes :-)
>
>Well, we do not as yet have the ability to schedule our earthquakes :)
Well, according to some people due to the east of you, they are
>
>> >The ultimately predictable train is one which is scheduled to not
>> >move.
>
>> Not in California - too many earthquakes :-)
>
>Well, we do not as yet have the ability to schedule our earthquakes :)
entirely judgments on your lifestyle - I wonder what they will say
one one of the earthquakes in their area lets rip - probably that
it's the fault of their neighbours :-(
>And any quake large enough to appreciably move a Caltrain probably
>means we have bigger worries than the train schedule.
enough to start them rolling and raised the ground enough for
there to be a slope - if that were followed by a long natural
slope, they could go some distance. I can't remember where or
when or even how reliable my source was.
But, harking back to the topic, it is a myth that predictability
always trumps frequency or trip brevity, just as the converse is
a myth. A lot of people need and want to take trips that aren't
scheduled in detail - e.g. getting home when a meeting ends.
Getting the balance right is tricky.
Regards,
Nick Maclaren.
nm...@cam.ac.uk
May 5, 2012, 4:44:56 AM5/5/12
to
In article <Av5pr.429900$ed1.2...@fx04.am4>,
Any old Phoenix (Cambridge) users here? INFO.EAGLE.CURRENT.STATUS :-)
But the utterly ridiculous thing is that this lunacy has got into
computer standards - the POSIX time model has seconds being physical
seconds, mapping to UTC, but with no leap seconds. The 'fix' is to
have multiple 'clocks', but there is a single timestamp and it has
no clock identification attribute! Markus Kuehn made a worthy
attempt to introduce sanity, but got nowhere.
Regards,
Nick Maclaren.
But the utterly ridiculous thing is that this lunacy has got into
computer standards - the POSIX time model has seconds being physical
seconds, mapping to UTC, but with no leap seconds. The 'fix' is to
have multiple 'clocks', but there is a single timestamp and it has
no clock identification attribute! Markus Kuehn made a worthy
attempt to introduce sanity, but got nowhere.
Regards,
Nick Maclaren.
Tom Gardner
May 5, 2012, 5:21:04 AM5/5/12
to
customers by the second, with teh cost depending on the
time of day. They thought time was easy, but then
they did think (and I use that word loosely) that there were
24 hours in a day, 12 months in a year, and 60s in an hour.
They did realise there were 365/366 days in a year (well,
almost always!), but still re-hard coded their systems once
every four years.
OTOH, their customers continued to buy the products, so
the attitude wasn't completely unreasonable.
Robert Myers
May 5, 2012, 8:53:27 AM5/5/12
to
but I haven't been following it closely) to eliminate leap seconds:
http://en.wikipedia.org/wiki/Leap_second#Proposal_to_abolish_leap_seconds
As you would say, the mind boggles at the prospect of any autonomous
system dealing with ad hoc changes to nominal "real" time, as in the
following article:
http://7thspace.com/headlines/410501/leap_second_to_be_added_on_july_1_2012.html
which I don't know whether to take seriously or not.
Robert.
Paul A. Clayton
May 5, 2012, 9:12:41 AM5/5/12
to
On May 5, 4:33 am, n...@cam.ac.uk wrote:
[snip]
brevity factor--though I wrote "longer" instead of "shorter"
as the alternative to better [by an undefined amount]
predictability.)
I suspect connections make the problem even more challenging.
Add economic factors (and political factors in the case of
public transportation) and the problem seems overwhelming.
(One can then add other forms of transportation and even
zoning laws and other factors that influence placement of
points of interests.)
[snip]
> But, harking back to the topic, it is a myth that predictability
> always trumps frequency or trip brevity, just as the converse is
> a myth. A lot of people need and want to take trips that aren't
> scheduled in detail - e.g. getting home when a meeting ends.
> Getting the balance right is tricky.
So true. (That is why I used "sometimes" and a 15% example
> always trumps frequency or trip brevity, just as the converse is
> a myth. A lot of people need and want to take trips that aren't
> scheduled in detail - e.g. getting home when a meeting ends.
> Getting the balance right is tricky.
brevity factor--though I wrote "longer" instead of "shorter"
as the alternative to better [by an undefined amount]
predictability.)
I suspect connections make the problem even more challenging.
Add economic factors (and political factors in the case of
public transportation) and the problem seems overwhelming.
(One can then add other forms of transportation and even
zoning laws and other factors that influence placement of
points of interests.)
nm...@cam.ac.uk
May 5, 2012, 10:31:11 AM5/5/12
to
In article <Ap9pr.185880$s82....@newsfe10.iad>,
the NTP protocol followed POSIX and almost all computer systems follow
one or the other. Modern design seems to be mostly about covering up
a previous gross error by a layer of kludges, and often results in
throwing out the baby with the bathwater.
>As you would say, the mind boggles at the prospect of any autonomous
>system dealing with ad hoc changes to nominal "real" time, as in the
>following article:
>
>http://7thspace.com/headlines/410501/leap_second_to_be_added_on_july_1_2012.html
>
>which I don't know whether to take seriously or not.
Try: http://www.nist.gov/pml/div688/grp50/leapsecond.cfm.
I first looked at NPL's Web site, but our more monetarist than Ayn
Rand governments have required it to charge for anything that might
be deemed to be useful information.
Regards,
Nick Maclaren.
Robert Myers <rbmye...@gmail.com> wrote:
>>
>> But the utterly ridiculous thing is that this lunacy has got into
>> computer standards - the POSIX time model has seconds being physical
>> seconds, mapping to UTC, but with no leap seconds. The 'fix' is to
>> have multiple 'clocks', but there is a single timestamp and it has
>> no clock identification attribute! Markus Kuehn made a worthy
>> attempt to introduce sanity, but got nowhere.
>>
>There is apparently a proposal on the table (I had heard this elsewhere,
>but I haven't been following it closely) to eliminate leap seconds:
>
>http://en.wikipedia.org/wiki/Leap_second#Proposal_to_abolish_leap_seconds
Yup. I believe that is a consequence of the POSIX imbecility, because
>>
>> But the utterly ridiculous thing is that this lunacy has got into
>> computer standards - the POSIX time model has seconds being physical
>> seconds, mapping to UTC, but with no leap seconds. The 'fix' is to
>> have multiple 'clocks', but there is a single timestamp and it has
>> no clock identification attribute! Markus Kuehn made a worthy
>> attempt to introduce sanity, but got nowhere.
>>
>There is apparently a proposal on the table (I had heard this elsewhere,
>but I haven't been following it closely) to eliminate leap seconds:
>
>http://en.wikipedia.org/wiki/Leap_second#Proposal_to_abolish_leap_seconds
the NTP protocol followed POSIX and almost all computer systems follow
one or the other. Modern design seems to be mostly about covering up
a previous gross error by a layer of kludges, and often results in
throwing out the baby with the bathwater.
>As you would say, the mind boggles at the prospect of any autonomous
>system dealing with ad hoc changes to nominal "real" time, as in the
>following article:
>
>http://7thspace.com/headlines/410501/leap_second_to_be_added_on_july_1_2012.html
>
>which I don't know whether to take seriously or not.
I first looked at NPL's Web site, but our more monetarist than Ayn
Rand governments have required it to charge for anything that might
be deemed to be useful information.
Regards,
Nick Maclaren.
ken...@cix.compulink.co.uk
May 6, 2012, 4:44:16 AM5/6/12
to
In article <jo2ola$bdr$1...@needham.csi.cam.ac.uk>, nm...@cam.ac.uk () wrote:
> I can't remember where or
> when or even how reliable my source was.
I have actually worked on the railways since 1980 or so and it seems
> I can't remember where or
> when or even how reliable my source was.
unlikely. Marshalling yards and train stables are usually built on flat
land and trains are secured. The only accounts of runaways I can
remember were actually in the steam days and due to operator error.
Ken Young
nm...@cam.ac.uk
May 6, 2012, 5:07:29 AM5/6/12
to
In article <boudnXbzw_Z9pDvS...@giganews.com>,
doesn't remain flat, and I can assure you that human nature is to
get careless with things like using handbrakes on flat ground,
and I doubt that the railways employ different kinds of human.
Even if it was true, that doesn't stop it being unlikely. One
woman has been injured by a meteorite - not that's both true and
as unlikely as it gets :-)
Regards,
Nick Maclaren.
<ken...@cix.compulink.co.uk> wrote:
>
>> I can't remember where or
>> when or even how reliable my source was.
>
> I have actually worked on the railways since 1980 or so and it seems
>unlikely. Marshalling yards and train stables are usually built on flat
>land and trains are secured. The only accounts of runaways I can
>remember were actually in the steam days and due to operator error.
Well, one of the properties of earthquakes is that flat ground
>
>> I can't remember where or
>> when or even how reliable my source was.
>
> I have actually worked on the railways since 1980 or so and it seems
>unlikely. Marshalling yards and train stables are usually built on flat
>land and trains are secured. The only accounts of runaways I can
>remember were actually in the steam days and due to operator error.
doesn't remain flat, and I can assure you that human nature is to
get careless with things like using handbrakes on flat ground,
and I doubt that the railways employ different kinds of human.
Even if it was true, that doesn't stop it being unlikely. One
woman has been injured by a meteorite - not that's both true and
as unlikely as it gets :-)
Regards,
Nick Maclaren.
Terje Mathisen
May 6, 2012, 6:44:40 AM5/6/12
to
We had a bad (multiple fatalities) accident in Oslo 2-3 years ago when
they lost control of a train in a marshalling yard. It ended up down in
the harbor area, plowing through working dock buildings.
gubs...@hotmail.com
May 7, 2012, 4:37:43 AM5/7/12
to nm...@cam.ac.uk
Den fredag den 4. maj 2012 22.02.13 UTC+2 skrev nm...@cam.ac.uk:
> In article <n5od79-...@ntp6.tmsw.no>,
> There are still single-track trunk roads in the Highlands, as far as
> I recall.
There is a beautiful stretch of single-track road (the B852) from Inverness down to Fort Augustus on the south side of Loch Ness.
It really is a fantastic drive if you're in a compact car, small british sports car or on motorbike.
Cheers
Martin
> In article <n5od79-...@ntp6.tmsw.no>,
> There are still single-track trunk roads in the Highlands, as far as
> I recall.
It really is a fantastic drive if you're in a compact car, small british sports car or on motorbike.
Cheers
Martin
Rick Jones
May 7, 2012, 1:38:56 PM5/7/12
to
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> BTW, the old trail which people used before the road was put in
> still exists, it has several sections with wires/chains bolted to
> the rock so you'll have something to hold on to. On the video that
> trail is on the right-hand side of the waterfall/river. The really
> amazing thing is that I guy once got ~20 cows up that trail, in
> order to get them to the next valley over.
How many did he start with?-)
> BTW, the old trail which people used before the road was put in
> still exists, it has several sections with wires/chains bolted to
> the rock so you'll have something to hold on to. On the video that
> trail is on the right-hand side of the waterfall/river. The really
> amazing thing is that I guy once got ~20 cows up that trail, in
> order to get them to the next valley over.
rick jones
--
web2.0 n, the dot.com reunion tour...
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
ChrisQ
May 9, 2012, 10:53:02 AM5/9/12
to
On 05/05/12 14:31, nm...@cam.ac.uk wrote:
> I first looked at NPL's Web site, but our more monetarist than Ayn
> Rand governments have required it to charge for anything that might
> be deemed to be useful information.
>
>
> Regards,
> Nick Maclaren.
Public *servants* indeed. I enquired about the cost for tech report held
> I first looked at NPL's Web site, but our more monetarist than Ayn
> Rand governments have required it to charge for anything that might
> be deemed to be useful information.
>
>
> Regards,
> Nick Maclaren.
at the national archive a while back. 20 or 30 pages to copy and they wanted
60.00 ukp for it. Apparently, you can go there and copy it yourself, but
charging that sort of fee is a bit much when it is funded by the taxpayer
anyway...
Regards,
Chris
nm...@cam.ac.uk
May 9, 2012, 12:02:49 PM5/9/12
to
In article <joe0cc$658$1...@speranza.aioe.org>,
and have been since 1995.
The government organisation that was the NPL opposed the change
but were told that servants should not question their masters'
decision to sell their indenture.
Regards,
Nick Maclaren.
ChrisQ <blac...@devnull.com> wrote:
>
>> I first looked at NPL's Web site, but our more monetarist than Ayn
>> Rand governments have required it to charge for anything that might
>> be deemed to be useful information.
>
>
>> I first looked at NPL's Web site, but our more monetarist than Ayn
>> Rand governments have required it to charge for anything that might
>> be deemed to be useful information.
>
>Public *servants* indeed. I enquired about the cost for tech report held
>at the national archive a while back. 20 or 30 pages to copy and they wanted
>60.00 ukp for it. Apparently, you can go there and copy it yourself, but
>charging that sort of fee is a bit much when it is funded by the taxpayer
>anyway...
No, they aren't, as their domain name shows - they are commercial,
>at the national archive a while back. 20 or 30 pages to copy and they wanted
>60.00 ukp for it. Apparently, you can go there and copy it yourself, but
>charging that sort of fee is a bit much when it is funded by the taxpayer
>anyway...
and have been since 1995.
The government organisation that was the NPL opposed the change
but were told that servants should not question their masters'
decision to sell their indenture.
Regards,
Nick Maclaren.
Tim McCaffrey
May 9, 2012, 6:13:09 PM5/9/12
to
In article <uobc79-...@ntp6.tmsw.no>, "terje.mathisenattmsw.no" says...
>
>van...@vsta.org wrote:
>> MitchAlsup<Mitch...@aol.com> wrote:
>>> What this tragedy reminds me of is all those groups trying to make cars
>>> that drive themselves, and why I don't want to own a car like that.
>>
>> When I mentally graph quality of average driver over time, and overlay
with
>> quality of Dr. Thrun's software over time, I end up being pretty certain
that
>> the latter's ascending line crosses the former's descending line in the
>> foreseeable future. At which point, yes, sign me up.
>>
>I'm pretty sure those two lines have crossed already:
>
>Even if the Google cars are biased (they have an interested and
>presumably very observant "pilot" at all times, ready to take over),
>they have passed the average driving distance per serious accident,
>haven't they?
>
>Terje
"almost all driving can be viewed as an exercise in chasing"
>
>van...@vsta.org wrote:
>> MitchAlsup<Mitch...@aol.com> wrote:
>>> What this tragedy reminds me of is all those groups trying to make cars
>>> that drive themselves, and why I don't want to own a car like that.
>>
>> When I mentally graph quality of average driver over time, and overlay
with
>> quality of Dr. Thrun's software over time, I end up being pretty certain
that
>> the latter's ascending line crosses the former's descending line in the
>> foreseeable future. At which point, yes, sign me up.
>>
>I'm pretty sure those two lines have crossed already:
>
>Even if the Google cars are biased (they have an interested and
>presumably very observant "pilot" at all times, ready to take over),
>they have passed the average driving distance per serious accident,
>haven't they?
>
>Terje
>PS. Here in Norway the large amount of roads without any centerline (or
>lines at all) would presumably make the lane-keeping sw work a lot
>harder. OTOH from what I remember from the reports of the driverless
>desert crossing, some cars were very successful by simply imitating what
>the car in front did: Images of lemmings following each other of a cliff
>comes to mind...
>
>lines at all) would presumably make the lane-keeping sw work a lot
>harder. OTOH from what I remember from the reports of the driverless
>desert crossing, some cars were very successful by simply imitating what
>the car in front did: Images of lemmings following each other of a cliff
>comes to mind...
>
>--
>- <Terje.Mathisen at tmsw.no>
>"almost all programming can be viewed as an exercise in caching"
So, your new sig is:
>- <Terje.Mathisen at tmsw.no>
>"almost all programming can be viewed as an exercise in caching"
"almost all driving can be viewed as an exercise in chasing"
Andy (Super) Glew
May 9, 2012, 7:02:32 PM5/9/12
to
>> -<Terje.Mathisen at tmsw.no>
>> "almost all programming can be viewed as an exercise in caching"
>
>> "almost all programming can be viewed as an exercise in caching"
>
On 5/9/2012 3:13 PM, Tim McCaffrey wrote:
> So, your new sig is:
> "almost all driving can be viewed as an exercise in chasing"
Almost all storage can be viewed as an exercise in stashing.
> So, your new sig is:
> "almost all driving can be viewed as an exercise in chasing"
Almost all dancing can viewed as an exercise in sashaying.
Almost all boxing can be viewed as an exercise in bashing.
Almost all securing of boats to the top of your car can be viewed as an
exercise in lashing.
Almost all waste disposal can be viewed as an exercise in trashing
^H^H^H^H^H^H^H^H^H recycling.
Almost all supercomputer applications can be viewed as an exercise in
thrashing.
Almost all website design can be viewed as an exercise in mashing.
Almost all automated driving can be viewed as an exercise in crashing.
Almost all non-rotating storage can be viewed as an exercise in flashing.
Terje Mathisen
May 10, 2012, 3:42:01 AM5/10/12
to
I'm officially impressed by both of you.
Terje
--
nm...@cam.ac.uk
May 10, 2012, 4:11:10 AM5/10/12
to
In article <a38s79-...@ntp6.tmsw.no>,
Regards,
Nick Maclaren.
>Wow!
>
>I'm officially impressed by both of you.
Could that be viewed as an exercise in tooth gnashing?
>
>I'm officially impressed by both of you.
Regards,
Nick Maclaren.
ChrisQ
May 10, 2012, 5:54:51 PM5/10/12
to
On 05/09/12 16:02, nm...@cam.ac.uk wrote:
>
> No, they aren't, as their domain name shows - they are commercial,
> and have been since 1995.
>
> The government organisation that was the NPL opposed the change
> but were told that servants should not question their masters'
> decision to sell their indenture.
>
>
> Regards,
> Nick Maclaren.
You are probably right. My argument would be that reports on research that
>
> No, they aren't, as their domain name shows - they are commercial,
> and have been since 1995.
>
> The government organisation that was the NPL opposed the change
> but were told that servants should not question their masters'
> decision to sell their indenture.
>
>
> Regards,
> Nick Maclaren.
were originally funded by the taxpayer should be available at nominal cost,
not some vastly inflated price, effectively at the taxpayers expense.
Same with online academic research reports, where the research was again
originally funded by the taxpayer. That market has been cornered by
publishers
who's only interest is profit, not the dissemination of knowledge for it's
own sake , nor any sense of the common good.
A not so subtle form of discrimination, in fact...
Regards,
Chris
ChrisQ
May 10, 2012, 5:57:35 PM5/10/12
to
> No, they aren't, as their domain name shows - they are commercial,
> and have been since 1995.
>
> The government organisation that was the NPL opposed the change
> but were told that servants should not question their masters'
> decision to sell their indenture.
>
>
> Regards,
> Nick Maclaren.
> and have been since 1995.
>
> The government organisation that was the NPL opposed the change
> but were told that servants should not question their masters'
> decision to sell their indenture.
>
>
> Regards,
> Nick Maclaren.
You are probably right. My argument would be that reports on research that
were originally funded by the taxpayer should be available at nominal cost,
not some vastly inflated price, effectively at the taxpayers expense.
Same with some online academic research reports, where the research was
were originally funded by the taxpayer should be available at nominal cost,
not some vastly inflated price, effectively at the taxpayers expense.
Terje Mathisen
May 11, 2012, 4:07:09 AM5/11/12
to
ChrisQ wrote:
> You are probably right. My argument would be that reports on research that
> were originally funded by the taxpayer should be available at nominal cost,
> not some vastly inflated price, effectively at the taxpayers expense.
>
That's simply god sense.
> You are probably right. My argument would be that reports on research that
> were originally funded by the taxpayer should be available at nominal cost,
> not some vastly inflated price, effectively at the taxpayers expense.
>
> Same with online academic research reports, where the research was again
> originally funded by the taxpayer. That market has been cornered by
> publishers
> who's only interest is profit, not the dissemination of knowledge for it's
> own sake , nor any sense of the common good.
>
> A not so subtle form of discrimination, in fact...
Finland have just (2 days ago) opened their entire LIDAR database for
open access. To try it out I just requested access to 9 tiles, each 3x3
km, and 10 min later I had an email with a custom download link valid
for a month or so. No registration/login or payment.
Here in Norway I've spent significant time (200+ hours last summer, i.e.
my entire vacation) working on an orienteering map of the forest around
the secondary school on Hvaler, an beautiful archipelago in the Oslo
fjord. (My map data is totally open access, even the raw OCAD drawings:
http://tmsw.no/asmaloy/)
I got a digested set of data from the community mapping authority to
start with, but in order to get access to the raw LIDAR files, I've been
told that I'd have to pay NOK 10,400.00 which is kind of steep for a pro
bono hobby project like this. :-(
The key is of course that I/we have already paid somewhere between 95%
and 99% of the costs to generate the mapping data via our tax bills.
"almost all programming can be viewed as an exercise in caching"
ChrisQ
May 11, 2012, 8:18:37 AM5/11/12
to
equivalent
is > 1000 uk pounds !!!. Absolutely outrageous. It's a sort of apartheid
on knowledge,
which discriminates in favour of large organisations or others with
large budgets. Not
all advancements in the sciences come from the well heeled.
Same applies to some professional organisations. I signed up to the IEEE
at one stage,
paid a years sub around March, assuming that the renewal would be the
following March.
The renewal demand arrived in December for the full years sub, which I
declined. Ever
since then, they've been pestering me with emails to renew at "half
price", ie: 12
months sub for 6 months fee. However, when the detail is examined, the
deal is in fact
9 months sub for 6 months fee. The main interest in the IEEE was the
online library,
even that, with member discount is not exactly a good deal, especially
if you need s
collection of reports. Such tricks make the IEEE look cheap and
grasping, not to
mention any ethical considerations. A more self serving organisation I
haven't met in
a long time...
Regards,
Chris
Terje Mathisen
May 11, 2012, 12:59:06 PM5/11/12
to
ChrisQ wrote:
> On 05/11/12 08:07, Terje Mathisen wrote:
>> I got a digested set of data from the community mapping authority
>> to start with, but in order to get access to the raw LIDAR files,
>> I've been told that I'd have to pay NOK 10,400.00 which is kind of
>> steep for a pro bono hobby project like this. :-(
>>
>> The key is of course that I/we have already paid somewhere between
>> 95% and 99% of the costs to generate the mapping data via our tax
>> bills.
>>
> On 05/11/12 08:07, Terje Mathisen wrote:
>> I got a digested set of data from the community mapping authority
>> to start with, but in order to get access to the raw LIDAR files,
>> I've been told that I'd have to pay NOK 10,400.00 which is kind of
>> steep for a pro bono hobby project like this. :-(
>>
>> The key is of course that I/we have already paid somewhere between
>> 95% and 99% of the costs to generate the mapping data via our tax
>> bills.
>>
> I wasn't aware of the exchange rate, but just did a translate and the
> equivalent is > 1000 uk pounds !!!. Absolutely outrageous. It's a
Yes indeed. I would have considered 5-10% of that, just because I want
> equivalent is > 1000 uk pounds !!!. Absolutely outrageous. It's a
the finished map to be as good as I can make it, but the "standard fee"
was out of the question. :-(
The fun part is that my professional consulting rate is NOK 1500 to
2000, so using that price range the value of my pro bono work would be
NOK 300-400K. :-)
> sort of apartheid on knowledge, which discriminates in favour of
> large organisations or others with large budgets. Not all
interests (in theory they all have at least some kind of data to
contribute) are part of the organization which sets the prices to outsiders.
All the insiders have free access to everything of course.
> advancements in the sciences come from the well heeled.
>
> Same applies to some professional organisations. I signed up to the
> IEEE at one stage, paid a years sub around March, assuming that the
> renewal would be the following March. The renewal demand arrived in
> December for the full years sub, which I declined. Ever since then,
> they've been pestering me with emails to renew at "half price", ie:
> 12 months sub for 6 months fee. However, when the detail is examined,
> the deal is in fact 9 months sub for 6 months fee. The main interest
> in the IEEE was the online library, even that, with member discount
> is not exactly a good deal, especially if you need s collection of
> reports. Such tricks make the IEEE look cheap and grasping, not to
> mention any ethical considerations. A more self serving organisation
> I haven't met in a long time...
I sent them email in 2010 about the horrible access policies to research
published in their journals; after a very unsatisfactory answer I left
the organization last year.
Since then I've gotten something like 15 pieces of paper and e-mail to
get me to sign up again.
Del Cecchi
May 11, 2012, 11:24:02 PM5/11/12
to
I will ask him what the purpose of IEEE is these days. I think he
apparently was president of ieee usa in 2011.
ChrisQ
May 12, 2012, 6:43:25 PM5/12/12
to
On 05/12/12 03:24, Del Cecchi wrote:
>>
> Good points. Next time I see my buddy that I worked with for many years
> I will ask him what the purpose of IEEE is these days. I think he
> apparently was president of ieee usa in 2011.
>
Would be interesting to hear what he says.
>>
> Good points. Next time I see my buddy that I worked with for many years
> I will ask him what the purpose of IEEE is these days. I think he
> apparently was president of ieee usa in 2011.
>
A bit off topic, but have been restoring an old IBM master clock from
the mid
1940's in the last week or so. I thought something quite early from IBM
would
complement all the much more recent computer kit in the lab. One of the
interesting things is that even the lower cost model had a rated accuracy of
15 seconds a month, though if they guaranteed that, they were probably
capable
of much better accuracy. It has a 1 second Invar pendulum and is spring
driven,
while the higher accuracy model (< 10 secs / month) used weight drive
and mercury
columns in the pendulum for temperature compensation. That accuracy is
better than
you would get from the average quartz wristwatch. So much for progress.
Slight
eccentricity, but the science of timekeeping is interesting in itself...
Regards,
Chris
Thomas Womack
May 13, 2012, 7:19:34 AM5/13/12
to
In article <jomp2d$665$1...@speranza.aioe.org>,
I'm with you up to 'so much for progress';
http://www-03.ibm.com/ibm/history/exhibits/cc/pdf/cc_2407MPL1.pdf
suggests that the cheaper Master Clock with invar pendulum was $175 in
1939 - three thousand dollars now. That a $15 quartz wristwatch
doesn't do quite as well is unsurprising; three thousand dollars now
buys you half a dozen GPS-stabilised OCXO oscillators from
http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm with an
accuracy of microseconds per month.
Tom
http://www-03.ibm.com/ibm/history/exhibits/cc/pdf/cc_2407MPL1.pdf
suggests that the cheaper Master Clock with invar pendulum was $175 in
1939 - three thousand dollars now. That a $15 quartz wristwatch
doesn't do quite as well is unsurprising; three thousand dollars now
buys you half a dozen GPS-stabilised OCXO oscillators from
http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm with an
accuracy of microseconds per month.
Tom
nm...@cam.ac.uk
May 13, 2012, 7:49:23 AM5/13/12
to
In article <Agt*Xy...@news.chiark.greenend.org.uk>,
I was seriously pissed off when a 2 million quid supercomputer kept
time to only 300 ppm, when why 10 quid wristwatch did to 10 ppm.
Regards,
Nick Maclaren.
time to only 300 ppm, when why 10 quid wristwatch did to 10 ppm.
Regards,
Nick Maclaren.
Robert Wessel
May 13, 2012, 11:35:20 AM5/13/12
to
On 13 May 2012 12:19:34 +0100 (BST), Thomas Womack
For $3K you can actually build your own (real) atomic clock. One of
Symmetricom's CSACs ("Chip Scale Atomic Clock") is only about $2K, you
need a PC or something with a serial port to add a display. Long term
(year+) PPB accuracy with no external inputs, short term up to 100
times better.
Symmetricom's CSACs ("Chip Scale Atomic Clock") is only about $2K, you
need a PC or something with a serial port to add a display. Long term
(year+) PPB accuracy with no external inputs, short term up to 100
times better.
ChrisQ
May 13, 2012, 1:06:30 PM5/13/12
to
On 05/13/12 11:19, Thomas Womack wrote:
> I'm with you up to 'so much for progress';
>
> http://www-03.ibm.com/ibm/history/exhibits/cc/pdf/cc_2407MPL1.pdf
> suggests that the cheaper Master Clock with invar pendulum was $175 in
> 1939 - three thousand dollars now. That a $15 quartz wristwatch
> doesn't do quite as well is unsurprising; three thousand dollars now
> buys you half a dozen GPS-stabilised OCXO oscillators from
> http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm with an
> accuracy of microseconds per month.
>
> Tom
Ok :-). Electromechanical will always be expensive, because of the cost of
> I'm with you up to 'so much for progress';
>
> http://www-03.ibm.com/ibm/history/exhibits/cc/pdf/cc_2407MPL1.pdf
> suggests that the cheaper Master Clock with invar pendulum was $175 in
> 1939 - three thousand dollars now. That a $15 quartz wristwatch
> doesn't do quite as well is unsurprising; three thousand dollars now
> buys you half a dozen GPS-stabilised OCXO oscillators from
> http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm with an
> accuracy of microseconds per month.
>
> Tom
manufacturing and the precision engineering. Considering like for like in
terms of usage, I guess a modern equivalent would be crystal double oven
or Rubidium standard, both of which are far more accurate and would cost
$k from a quality vendor like Symmetricom. Cheap gps disciplined are not
bad long tern, but often noisy short term, while caesium has the best
accuracy, but is eye wateringly expensive.
Still, 10 secs / month seems impressive to me, for a series of clocks that
date back to pre 1920...
Regards,
Chris
ChrisQ
May 13, 2012, 1:18:40 PM5/13/12
to
On 05/13/12 11:49, nm...@cam.ac.uk wrote:
>
> I was seriously pissed off when a 2 million quid supercomputer kept
> time to only 300 ppm, when why 10 quid wristwatch did to 10 ppm.
>
>
> Regards,
> Nick Maclaren.
The thing about the cheap wristwatch is that the crystal tolerance and
>
> I was seriously pissed off when a 2 million quid supercomputer kept
> time to only 300 ppm, when why 10 quid wristwatch did to 10 ppm.
>
>
> Regards,
> Nick Maclaren.
temperature coefficient is such that you may get a good one, or one that
needs regular adjustment. Any commercial kit on the other hand, will have
clock accuracy specified and is usually far better. Do you want absolute
time, or repeatability ?.
My wristwatch is good to about a minute / 3 months, (~32 Khz crystal)
depending on temp variation, while the Braun alarm clock bought in 1975
(~4Mhz crystal) is still good for a few seconds a year...
Regards,
Chris
nm...@cam.ac.uk
May 13, 2012, 1:49:46 PM5/13/12
to
In article <jooqdd$sb7$1...@speranza.aioe.org>,
that is a minute every two days. Almost all of the ones I have
had, or I have known other people have, have had drifts of less
than 50 ppm. 300 ppm is grounds for taking it back and demanding
a replacement.
But that wasn't my point - it was that the makers of the supercomputer
hadn't put in a clock that was good enough for synchronisation with
the available software. So I had to write msntp :-)
Regards,
Nick Maclaren.
ChrisQ <blac...@devnull.com> wrote:
>
>> I was seriously pissed off when a 2 million quid supercomputer kept
>> time to only 300 ppm, when why 10 quid wristwatch did to 10 ppm.
>
>
>> I was seriously pissed off when a 2 million quid supercomputer kept
>> time to only 300 ppm, when why 10 quid wristwatch did to 10 ppm.
>
>The thing about the cheap wristwatch is that the crystal tolerance and
>temperature coefficient is such that you may get a good one, or one that
>needs regular adjustment. Any commercial kit on the other hand, will have
>clock accuracy specified and is usually far better. Do you want absolute
>time, or repeatability ?.
It is extremely rare to have even a cheap watch drift by 300 ppm;
>temperature coefficient is such that you may get a good one, or one that
>needs regular adjustment. Any commercial kit on the other hand, will have
>clock accuracy specified and is usually far better. Do you want absolute
>time, or repeatability ?.
that is a minute every two days. Almost all of the ones I have
had, or I have known other people have, have had drifts of less
than 50 ppm. 300 ppm is grounds for taking it back and demanding
a replacement.
But that wasn't my point - it was that the makers of the supercomputer
hadn't put in a clock that was good enough for synchronisation with
the available software. So I had to write msntp :-)
Regards,
Nick Maclaren.
Del Cecchi
May 13, 2012, 3:10:46 PM5/13/12
to
airconditioned environment so the temperature may have varied by 20
degrees C. unlike a wrist watch that is coupled to a large constant
temperature heat sink.
BTW my experience, with a small sample size, is that even a timex quartz
watch is typically only off by a couple minutes per year. I never have
to set the one I am wearing now, except due to DST on and off, or maybe
a time zone change.
If you do active trim on the oscillator, and your arm is a constant
temp, then all you get is aging of a few ppm (2ppm is a minute per year).
Robert Wessel
May 13, 2012, 11:47:57 PM5/13/12
to
On Sun, 13 May 2012 17:06:30 +0000, ChrisQ <blac...@devnull.com>
wrote:
Purely mechanical marine chronometers have been achieving that order
of accuracy since the late 18th century. And in environments where
they're moving, and temperature control is limited.
Knowing the time is crucial for (pre-electronic) navigation - you can
determine your latitude easily enough celestially, but you cannot
determine longitude without knowing the time. In theory, you could
determine your longitude to within +/1 one mile if you know the time
to within a minute, in practice you can manage about half that. Given
multi-month ocean crossings in the sail era, your timepiece needs to
be accurate to within a few tens of seconds per month.
wrote:
of accuracy since the late 18th century. And in environments where
they're moving, and temperature control is limited.
Knowing the time is crucial for (pre-electronic) navigation - you can
determine your latitude easily enough celestially, but you cannot
determine longitude without knowing the time. In theory, you could
determine your longitude to within +/1 one mile if you know the time
to within a minute, in practice you can manage about half that. Given
multi-month ocean crossings in the sail era, your timepiece needs to
be accurate to within a few tens of seconds per month.
Message has been deleted
Terje Mathisen
May 14, 2012, 3:17:06 AM5/14/12
to
Robert Wessel wrote:
> Knowing the time is crucial for (pre-electronic) navigation - you can
> determine your latitude easily enough celestially, but you cannot
> determine longitude without knowing the time. In theory, you could
It's even worse, as Morten R have pointed out: You need an accuracy of 4
> Knowing the time is crucial for (pre-electronic) navigation - you can
> determine your latitude easily enough celestially, but you cannot
> determine longitude without knowing the time. In theory, you could
minutes per degree, so 4 seconds per minute/nautical mile.
The original test was to sail from England to the West Indies and back,
and still be within a few seconds.
> determine your longitude to within +/1 one mile if you know the time
> to within a minute, in practice you can manage about half that. Given
> multi-month ocean crossings in the sail era, your timepiece needs to
> be accurate to within a few tens of seconds per month.
If you have not, please do so asap, it is a very well-written story
about Harrison and his wonderful clocks.
http://www.amazon.com/Longitude-Genius-Greatest-Scientific-Problem/dp/0140258795
While waiting for the book to arrive, check out
http://en.wikipedia.org/wiki/John_Harrison
http://en.wikipedia.org/wiki/Longitude_prize
http://www.imdb.com/title/tt0192263/
nm...@cam.ac.uk
May 14, 2012, 4:51:05 AM5/14/12
to
In article <k4o689-...@ntp6.tmsw.no>,
that they would be of more interest to us than the chattering
classes.
Still, it was better than A Brief History of Time, though the
accolade for mistitling must be the fascinating (and information-
full) Astonishing Hypothesis: The Scientific Search for the Soul,
where even the blurb had damn-all to do with the content!
Regards,
Nick Maclaren.
>I assumed that everyone here had read "Longitude" at least once?
>
>If you have not, please do so asap, it is a very well-written story
>about Harrison and his wonderful clocks.
I found it a little short on the technical aspects, but am aware
>
>If you have not, please do so asap, it is a very well-written story
>about Harrison and his wonderful clocks.
that they would be of more interest to us than the chattering
classes.
Still, it was better than A Brief History of Time, though the
accolade for mistitling must be the fascinating (and information-
full) Astonishing Hypothesis: The Scientific Search for the Soul,
where even the blurb had damn-all to do with the content!
Regards,
Nick Maclaren.
Terje Mathisen
May 14, 2012, 7:54:29 AM5/14/12
to
nm...@cam.ac.uk wrote:
> In article<k4o689-...@ntp6.tmsw.no>,
> Terje Mathisen<"terje.mathisen at tmsw.no"> wrote:
>>
>> I assumed that everyone here had read "Longitude" at least once?
>>
>> If you have not, please do so asap, it is a very well-written story
>> about Harrison and his wonderful clocks.
>
> I found it a little short on the technical aspects, but am aware
> that they would be of more interest to us than the chattering
> classes.
I mostly missed any explanation of many of the _huge_ steps from his
> In article<k4o689-...@ntp6.tmsw.no>,
> Terje Mathisen<"terje.mathisen at tmsw.no"> wrote:
>>
>> I assumed that everyone here had read "Longitude" at least once?
>>
>> If you have not, please do so asap, it is a very well-written story
>> about Harrison and his wonderful clocks.
>
> I found it a little short on the technical aspects, but am aware
> that they would be of more interest to us than the chattering
> classes.
first clocks (making gears out of self-lubricating wood?) to the
all-metal H4 "pocket" chronometer.
Thomas Womack
May 14, 2012, 9:48:16 AM5/14/12
to
In article <8ckvq7phocegj9ct5...@4ax.com>,
pricing information for new ones - Symmetricom had 'ask for quote'
buttons instead of actual prices. They do seem reasonably available
from ebay in the $700 range but I thought that, if I used
time-standards from ebay, it would divert the thread into an argument
about ebay.
Tom
Robert Wessel <robert...@yahoo.com> wrote:
>For $3K you can actually build your own (real) atomic clock. One of
>Symmetricom's CSACs ("Chip Scale Atomic Clock") is only about $2K, you
>need a PC or something with a serial port to add a display. Long term
>(year+) PPB accuracy with no external inputs, short term up to 100
>times better.
I had looked at those while writing the post, but couldn't find
>For $3K you can actually build your own (real) atomic clock. One of
>Symmetricom's CSACs ("Chip Scale Atomic Clock") is only about $2K, you
>need a PC or something with a serial port to add a display. Long term
>(year+) PPB accuracy with no external inputs, short term up to 100
>times better.
pricing information for new ones - Symmetricom had 'ask for quote'
buttons instead of actual prices. They do seem reasonably available
from ebay in the $700 range but I thought that, if I used
time-standards from ebay, it would divert the thread into an argument
about ebay.
Tom
Brian Drummond
May 14, 2012, 3:18:31 PM5/14/12
to
On Mon, 14 May 2012 13:54:29 +0200, Terje Mathisen wrote:
> nm...@cam.ac.uk wrote:
>> In article<k4o689-...@ntp6.tmsw.no>,
>> Terje Mathisen<"terje.mathisen at tmsw.no"> wrote:
>>>
>>> I assumed that everyone here had read "Longitude" at least once?
>>>
>>> If you have not, please do so asap, it is a very well-written story
>>> about Harrison and his wonderful clocks.
>>
>> I found it a little short on the technical aspects, but am aware that
>> they would be of more interest to us than the chattering classes.
>
> I mostly missed any explanation of many of the _huge_ steps from his
> first clocks (making gears out of self-lubricating wood?) to the
> all-metal H4 "pocket" chronometer.
For better information, not just on Harrison's development process but
> nm...@cam.ac.uk wrote:
>> In article<k4o689-...@ntp6.tmsw.no>,
>> Terje Mathisen<"terje.mathisen at tmsw.no"> wrote:
>>>
>>> I assumed that everyone here had read "Longitude" at least once?
>>>
>>> If you have not, please do so asap, it is a very well-written story
>>> about Harrison and his wonderful clocks.
>>
>> I found it a little short on the technical aspects, but am aware that
>> they would be of more interest to us than the chattering classes.
>
> I mostly missed any explanation of many of the _huge_ steps from his
> first clocks (making gears out of self-lubricating wood?) to the
> all-metal H4 "pocket" chronometer.
other contemporary work and later development, get hold of Rupert Gould's
"The Marine Chronometer, Its History and Development". Difficult to get,
though a reprint has been promised for years, but there is a scan of it
available, from the Gutenberg project I think.
(300ppm is fairly routine from a mid-19th century fusee watch, even after
150 years of use...)
- Brian
Joe keane
May 14, 2012, 10:50:42 PM5/14/12
to
In article <joo743$lpv$1...@needham.csi.cam.ac.uk>, <nm...@cam.ac.uk> wrote:
>I was seriously pissed off when a 2 million quid supercomputer kept
>time to only 300 ppm, when why 10 quid wristwatch did to 10 ppm.
If your computer doesn't work right when the clock is off by 10%, then
>I was seriously pissed off when a 2 million quid supercomputer kept
>time to only 300 ppm, when why 10 quid wristwatch did to 10 ppm.
it's seriously flaky. I'm amused by some people adjusting wire lengths
to fix problems.
Also i think computers use mains power to do 'real-time clock'. It
drifts a bit but it is long-term highly accurate.
IIRC, when cheap quartz-based watches appeared, they almost instantly
laid rest to any claim that mechanical watches were superior, except for
something that only a millionaire would wear [so far as being accurate
rather than attractive jewelry].
Joe Pfeiffer
May 15, 2012, 12:55:36 AM5/15/12
to
j...@panix.com (Joe keane) writes:
> In article <joo743$lpv$1...@needham.csi.cam.ac.uk>, <nm...@cam.ac.uk> wrote:
>>I was seriously pissed off when a 2 million quid supercomputer kept
>>time to only 300 ppm, when why 10 quid wristwatch did to 10 ppm.
>
> If your computer doesn't work right when the clock is off by 10%, then
> it's seriously flaky. I'm amused by some people adjusting wire lengths
> to fix problems.
That *really* depends on what your computer is doing. I'm currently
> In article <joo743$lpv$1...@needham.csi.cam.ac.uk>, <nm...@cam.ac.uk> wrote:
>>I was seriously pissed off when a 2 million quid supercomputer kept
>>time to only 300 ppm, when why 10 quid wristwatch did to 10 ppm.
>
> If your computer doesn't work right when the clock is off by 10%, then
> it's seriously flaky. I'm amused by some people adjusting wire lengths
> to fix problems.
designing an oven for my workshop that'll be capable of logging its
activity over USB for debugging; the clock has to be accurate to well
within a percent (I'd have to check on the actual spec) to do low-speed
USB (which is all I'm aiming at) -- doing high-speed would require
enough added precision to need a crystal resonator instead of the
on-chip RC oscillator.
> Also i think computers use mains power to do 'real-time clock'. It
> drifts a bit but it is long-term highly accurate.
anything except various flavors of DC to the motherboard. See
http://pinouts.ru/Power/atxpower_pinout.shtml
My computers all use their internal RTC, and sync periodically over NTP.
nm...@cam.ac.uk
May 15, 2012, 4:54:15 AM5/15/12
to
In article <1btxzi8...@pfeifferfamily.net>,
Joe Pfeiffer <pfei...@cs.nmsu.edu> wrote:
modern era, all supercomputers are parallel, and almost always
set up with shared filing systems (eg. NFS). Now 'make' breaks
horribly once the discrepancy between any two nodes exceeds a
second ....
That is, in fact, what forced me into action. I and users were
editing a source file on the login node, submitting a job to
build and run, and it ran the old version. There are other ways
that happens, but 300 ppm means that you have to wait a LONG
time after editing before it is safe to submit :-(
>> Also i think computers use mains power to do 'real-time clock'. It
>> drifts a bit but it is long-term highly accurate.
>
>Where do you get this? The standard ATX power connector doesn't supply
>anything except various flavors of DC to the motherboard. See
>http://pinouts.ru/Power/atxpower_pinout.shtml
It was once true for many computers. Up until at least the 1970s,
IBM System/370s' main timer operated that way. I haven't heard of
it being done in decades.
Regards,
Nick Maclaren.
Joe Pfeiffer <pfei...@cs.nmsu.edu> wrote:
>j...@panix.com (Joe keane) writes:
>
>>>I was seriously pissed off when a 2 million quid supercomputer kept
>>>time to only 300 ppm, when why 10 quid wristwatch did to 10 ppm.
>>
>> If your computer doesn't work right when the clock is off by 10%, then
>> it's seriously flaky. I'm amused by some people adjusting wire lengths
>> to fix problems.
>
>That *really* depends on what your computer is doing.
True, but Joe Keane really should think before posting. In the
>
>>>I was seriously pissed off when a 2 million quid supercomputer kept
>>>time to only 300 ppm, when why 10 quid wristwatch did to 10 ppm.
>>
>> If your computer doesn't work right when the clock is off by 10%, then
>> it's seriously flaky. I'm amused by some people adjusting wire lengths
>> to fix problems.
>
>That *really* depends on what your computer is doing.
modern era, all supercomputers are parallel, and almost always
set up with shared filing systems (eg. NFS). Now 'make' breaks
horribly once the discrepancy between any two nodes exceeds a
second ....
That is, in fact, what forced me into action. I and users were
editing a source file on the login node, submitting a job to
build and run, and it ran the old version. There are other ways
that happens, but 300 ppm means that you have to wait a LONG
time after editing before it is safe to submit :-(
>> Also i think computers use mains power to do 'real-time clock'. It
>> drifts a bit but it is long-term highly accurate.
>
>Where do you get this? The standard ATX power connector doesn't supply
>anything except various flavors of DC to the motherboard. See
>http://pinouts.ru/Power/atxpower_pinout.shtml
IBM System/370s' main timer operated that way. I haven't heard of
it being done in decades.
Regards,
Nick Maclaren.
ChrisQ
May 15, 2012, 9:48:40 AM5/15/12
to
On 05/15/12 08:54, nm...@cam.ac.uk wrote:
> That is, in fact, what forced me into action. I and users were
> editing a source file on the login node, submitting a job to
> build and run, and it ran the old version. There are other ways
> that happens, but 300 ppm means that you have to wait a LONG
> time after editing before it is safe to submit :-(
Seen that make problem quite often. The solution here was to point all the
> That is, in fact, what forced me into action. I and users were
> editing a source file on the login node, submitting a job to
> build and run, and it ran the old version. There are other ways
> that happens, but 300 ppm means that you have to wait a LONG
> time after editing before it is safe to submit :-(
machines at one of the internet ntp servers. Within a second is good
enough and ntp seems to manage that quite well long term. The unix machines
have ntp with the os, but for windows, i've found the best client to be
Symmetricom's Symmtime utility, which is a free download from their website.
>
>>> Also i think computers use mains power to do 'real-time clock'. It
>>> drifts a bit but it is long-term highly accurate.
>>
>> Where do you get this? The standard ATX power connector doesn't supply
>> anything except various flavors of DC to the motherboard. See
>> http://pinouts.ru/Power/atxpower_pinout.shtml
>
> It was once true for many computers. Up until at least the 1970s,
> IBM System/370s' main timer operated that way. I haven't heard of
> it being done in decades.
>
cpu clock, which is an encapsulated dil package. They are not usually that
accurate long term, even from quality vendors...
Terje Mathisen
May 15, 2012, 10:03:50 AM5/15/12
to
ChrisQ wrote:
> On 05/15/12 08:54, nm...@cam.ac.uk wrote:
>
>> That is, in fact, what forced me into action. I and users were
>> editing a source file on the login node, submitting a job to
>> build and run, and it ran the old version. There are other ways
>> that happens, but 300 ppm means that you have to wait a LONG
>> time after editing before it is safe to submit :-(
>
> Seen that make problem quite often. The solution here was to point all the
> machines at one of the internet ntp servers. Within a second is good
> enough and ntp seems to manage that quite well long term. The unix machines
> have ntp with the os, but for windows, i've found the best client to be
> Symmetricom's Symmtime utility, which is a free download from their
> website.
Please don't!
> On 05/15/12 08:54, nm...@cam.ac.uk wrote:
>
>> That is, in fact, what forced me into action. I and users were
>> editing a source file on the login node, submitting a job to
>> build and run, and it ran the old version. There are other ways
>> that happens, but 300 ppm means that you have to wait a LONG
>> time after editing before it is safe to submit :-(
>
> Seen that make problem quite often. The solution here was to point all the
> machines at one of the internet ntp servers. Within a second is good
> enough and ntp seems to manage that quite well long term. The unix machines
> have ntp with the os, but for windows, i've found the best client to be
> Symmetricom's Symmtime utility, which is a free download from their
> website.
Symmtime _might_ be better than the Windows included w32time.exe (not
extremely hard to do), but it falls far behind the official release,
i.e. ntpd.exe from ntp.org.
Windows is one of the primary targets for the official ntpd
distribution, so the latest ntp-dev code will always compile with
Microsoft VS C(++).
If you want a pre-built binary distribution, there are several people in
the "NTP Hackers" group who maintain that, my server used to be the
official distribution point for a number of years.
Currently I have the last version I compiled for my own use on
http://norloff.org/ntp/dev/ntp-dev-4.2.7p241.zip but if you follow the
links from http://ntp.org/ you can probably find something more recent!
ChrisQ
May 15, 2012, 10:30:35 AM5/15/12
to
On 05/15/12 14:03, Terje Mathisen wrote:
> Please don't!
>
> Symmtime _might_ be better than the Windows included w32time.exe (not
> extremely hard to do), but it falls far behind the official release,
> i.e. ntpd.exe from ntp.org.
>
> Windows is one of the primary targets for the official ntpd
> distribution, so the latest ntp-dev code will always compile with
> Microsoft VS C(++).
>
> If you want a pre-built binary distribution, there are several people in
> the "NTP Hackers" group who maintain that, my server used to be the
> official distribution point for a number of years.
>
> Currently I have the last version I compiled for my own use on
> http://norloff.org/ntp/dev/ntp-dev-4.2.7p241.zip but if you follow the
> links from http://ntp.org/ you can probably find something more recent!
>
> Terje
I'm sure you are right. Probably lazyness, but am still using the symmtime
> Please don't!
>
> Symmtime _might_ be better than the Windows included w32time.exe (not
> extremely hard to do), but it falls far behind the official release,
> i.e. ntpd.exe from ntp.org.
>
> Windows is one of the primary targets for the official ntpd
> distribution, so the latest ntp-dev code will always compile with
> Microsoft VS C(++).
>
> If you want a pre-built binary distribution, there are several people in
> the "NTP Hackers" group who maintain that, my server used to be the
> official distribution point for a number of years.
>
> Currently I have the last version I compiled for my own use on
> http://norloff.org/ntp/dev/ntp-dev-4.2.7p241.zip but if you follow the
> links from http://ntp.org/ you can probably find something more recent!
>
> Terje
I downloaded years ago. It does put a neat little analog (or digital) clock
widget on the screen, which was what was needed at the time. If I want
better
accuracy, a dedicated time server, referenced to gps, would be the next
step.
Pc clocks are not very good, coming from the cmos hardware with a ~32Khz
watch
crystal typically. Most of them don't even have a trimmer for adjustment and
I find that machines left off for a few weeks can be several seconds out on
and initial reboot. Even if there is a trimmer, it's difficult to connect
a counter because of the probe loading...
Regards,
Chris
Robert Myers
May 15, 2012, 10:50:41 AM5/15/12
to
On 5/14/2012 3:17 AM, Terje Mathisen wrote:
> Robert Wessel wrote:
>> Knowing the time is crucial for (pre-electronic) navigation - you can
>> determine your latitude easily enough celestially, but you cannot
>> determine longitude without knowing the time. In theory, you could
>
> It's even worse, as Morten R have pointed out: You need an accuracy of 4
> minutes per degree, so 4 seconds per minute/nautical mile.
>
> The original test was to sail from England to the West Indies and back,
> and still be within a few seconds.
>
>> determine your longitude to within +/1 one mile if you know the time
>> to within a minute, in practice you can manage about half that. Given
>> multi-month ocean crossings in the sail era, your timepiece needs to
>> be accurate to within a few tens of seconds per month.
>
> I assumed that everyone here had read "Longitude" at least once?
>
While I'm sure the history is interesting, I suspect that the actual
> Robert Wessel wrote:
>> Knowing the time is crucial for (pre-electronic) navigation - you can
>> determine your latitude easily enough celestially, but you cannot
>> determine longitude without knowing the time. In theory, you could
>
> It's even worse, as Morten R have pointed out: You need an accuracy of 4
> minutes per degree, so 4 seconds per minute/nautical mile.
>
> The original test was to sail from England to the West Indies and back,
> and still be within a few seconds.
>
>> determine your longitude to within +/1 one mile if you know the time
>> to within a minute, in practice you can manage about half that. Given
>> multi-month ocean crossings in the sail era, your timepiece needs to
>> be accurate to within a few tens of seconds per month.
>
> I assumed that everyone here had read "Longitude" at least once?
>
current state of the art is classified and that it probably does not
rely exclusively on clocks built in laboratories. I say this warily,
because there are people here who have spent a lot more time thinking
about GPS than I have.
With the addition of techniques like Kalman filtering and probably not
much more than a desktop PC, I would guess that your ability to tell
time over a long period of time independent of earthbound devices
dedicated to timekeeping should depend only on the limits of the
accuracy of your astronomical observations.
I haven't put pencil to paper (including the proverbial envelope), but
if we can photograph a cluster of galaxies eleven billion years old and
find it again with an eight meter aperture telescope, I suspect that we
do not really need laboratory instruments to know what time it is. Or,
perhaps I should say, the cosmos surrounding us will have its own
opinion to offer, independent of earthbound estimates, and we can
probably infer that opinion with a great deal of accuracy.
What has changed since the original struggle to tell time is the easy
availability of very inexpensive computation.
Robert.
van...@vsta.org
May 15, 2012, 11:57:33 AM5/15/12
to
nm...@cam.ac.uk wrote:
> True, but Joe Keane really should think before posting. In the
> modern era, all supercomputers are parallel, and almost always
> set up with shared filing systems (eg. NFS). Now 'make' breaks
> horribly once the discrepancy between any two nodes exceeds a
> second ....
We had this problem on the Sequent Symmetry line, I believe it was the S16
> True, but Joe Keane really should think before posting. In the
> modern era, all supercomputers are parallel, and almost always
> set up with shared filing systems (eg. NFS). Now 'make' breaks
> horribly once the discrepancy between any two nodes exceeds a
> second ....
model. The first symptom was negative ping times, because the timestamp on
the outgoing packet reflected whatever CPU "ping" was running on when it
built the ICMP packet. The time comparison was WRT the clock of whatever
other CPU happened to run "ping" when the response came back. It could be
spuriously large, or negative.
The boot monitor folks (who also did diags) added the code to sync up the
clocks during startup, and asked me (as the OS dev) to write some code to
verify the clocks. I used processor binding and IPC, and all looked well.
Then the lead diag guy put me to shame by converting the test to a shared
memory algorithm which verified to a level at least two orders of magnitude
tighter than my own code. And their clocks were still testing OK and
synchronized.
--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
nm...@cam.ac.uk
May 15, 2012, 12:31:10 PM5/15/12
to
In article <jotmrm$s9o$1...@speranza.aioe.org>,
neither it, nor autoconfigure, nor gnu m4, nor gcc had been ported,
and where only cross-compilation was possible?
Designing and writing msntp took less time than I estimated it
would take to reverse engineer enough of xntp's build mechanism
to estimate whether it would be feasible to build it and start
porting ....
Regards,
Nick Maclaren.
ChrisQ <blac...@devnull.com> wrote:
>
>> That is, in fact, what forced me into action. I and users were
>> editing a source file on the login node, submitting a job to
>> build and run, and it ran the old version. There are other ways
>> that happens, but 300 ppm means that you have to wait a LONG
>> time after editing before it is safe to submit :-(
>
>Seen that make problem quite often. The solution here was to point all the
>machines at one of the internet ntp servers.
Have you ever even contemplated porting xntp - to a system which
>
>> That is, in fact, what forced me into action. I and users were
>> editing a source file on the login node, submitting a job to
>> build and run, and it ran the old version. There are other ways
>> that happens, but 300 ppm means that you have to wait a LONG
>> time after editing before it is safe to submit :-(
>
>Seen that make problem quite often. The solution here was to point all the
>machines at one of the internet ntp servers.
neither it, nor autoconfigure, nor gnu m4, nor gcc had been ported,
and where only cross-compilation was possible?
Designing and writing msntp took less time than I estimated it
would take to reverse engineer enough of xntp's build mechanism
to estimate whether it would be feasible to build it and start
porting ....
Regards,
Nick Maclaren.
George Neuner
May 15, 2012, 3:50:21 PM5/15/12
to
On Tue, 15 May 2012 02:50:42 +0000 (UTC), j...@panix.com (Joe keane)
wrote:
>Also i think computers use mains power to do 'real-time clock'. It
>drifts a bit but it is long-term highly accurate.
The US has stopped regulating current cycles as an experiment
http://www.nj.com/news/index.ssf/2011/06/electric_grid_experiment_could.html
http://wattsupwiththat.com/2011/06/25/it-hertz-when-you-do-that-power-grid-to-stop-regulating-60-hz-frequency/
and may decide to stop altogether if the power companies like the
results. It doesn't affect crystal clocks or PLLs, but there are many
consumer devices having electromechanical timers or simple RC
generator circuits that all have gone crazy.
Not everything is GPS based or Internet connected ... but everything
has a clock in it. I've got more than 30 devices containing clocks in
my home: 7 in my kitchen alone. Since the cycle "deregulation"
experiment started last summer, every one of them is running at a
different rate. Some are drifting by 3-4 minutes per day.
George
wrote:
>Also i think computers use mains power to do 'real-time clock'. It
>drifts a bit but it is long-term highly accurate.
http://www.nj.com/news/index.ssf/2011/06/electric_grid_experiment_could.html
http://wattsupwiththat.com/2011/06/25/it-hertz-when-you-do-that-power-grid-to-stop-regulating-60-hz-frequency/
and may decide to stop altogether if the power companies like the
results. It doesn't affect crystal clocks or PLLs, but there are many
consumer devices having electromechanical timers or simple RC
generator circuits that all have gone crazy.
Not everything is GPS based or Internet connected ... but everything
has a clock in it. I've got more than 30 devices containing clocks in
my home: 7 in my kitchen alone. Since the cycle "deregulation"
experiment started last summer, every one of them is running at a
different rate. Some are drifting by 3-4 minutes per day.
George
Terje Mathisen
May 16, 2012, 1:25:41 AM5/16/12
to
nm...@cam.ac.uk wrote:
>> Seen that make problem quite often. The solution here was to point all the
>> machines at one of the internet ntp servers.
>
> Have you ever even contemplated porting xntp - to a system which
> neither it, nor autoconfigure, nor gnu m4, nor gcc had been ported,
> and where only cross-compilation was possible?
>
> Designing and writing msntp took less time than I estimated it
> would take to reverse engineer enough of xntp's build mechanism
> to estimate whether it would be feasible to build it and start
> porting ....
As you might know, the windows version of ntpd simply punts:
>> Seen that make problem quite often. The solution here was to point all the
>> machines at one of the internet ntp servers.
>
> Have you ever even contemplated porting xntp - to a system which
> neither it, nor autoconfigure, nor gnu m4, nor gcc had been ported,
> and where only cross-compilation was possible?
>
> Designing and writing msntp took less time than I estimated it
> would take to reverse engineer enough of xntp's build mechanism
> to estimate whether it would be feasible to build it and start
> porting ....
It depends on being able to skip autoconfig and m4 completely, and the
source code has to at least be portable between gcc and MS VC.
All the remaining platform-specific stuff is placed in a separate
directory structure, along with the Win* build/make files.
Terje Mathisen
May 16, 2012, 1:28:23 AM5/16/12
to
George Neuner wrote:
> The US has stopped regulating current cycles as an experiment
>
> http://www.nj.com/news/index.ssf/2011/06/electric_grid_experiment_could.html
> http://wattsupwiththat.com/2011/06/25/it-hertz-when-you-do-that-power-grid-to-stop-regulating-60-hz-frequency/
>
> and may decide to stop altogether if the power companies like the
> results. It doesn't affect crystal clocks or PLLs, but there are many
> consumer devices having electromechanical timers or simple RC
> generator circuits that all have gone crazy.
>
> Not everything is GPS based or Internet connected ... but everything
> has a clock in it. I've got more than 30 devices containing clocks in
> my home: 7 in my kitchen alone. Since the cycle "deregulation"
> experiment started last summer, every one of them is running at a
> different rate. Some are drifting by 3-4 minutes per day.
That seems impossible!
> The US has stopped regulating current cycles as an experiment
>
> http://www.nj.com/news/index.ssf/2011/06/electric_grid_experiment_could.html
> http://wattsupwiththat.com/2011/06/25/it-hertz-when-you-do-that-power-grid-to-stop-regulating-60-hz-frequency/
>
> and may decide to stop altogether if the power companies like the
> results. It doesn't affect crystal clocks or PLLs, but there are many
> consumer devices having electromechanical timers or simple RC
> generator circuits that all have gone crazy.
>
> Not everything is GPS based or Internet connected ... but everything
> has a clock in it. I've got more than 30 devices containing clocks in
> my home: 7 in my kitchen alone. Since the cycle "deregulation"
> experiment started last summer, every one of them is running at a
> different rate. Some are drifting by 3-4 minutes per day.
Either your clocks depend on 50/60 Hz mains power as the timing source,
in which case all of them will drift exactly the same amount, or they
disregard that and use an internal quartz clock chip.
In the latter case you're back exactly where you were last year?
Terje Mathisen
May 16, 2012, 2:02:53 AM5/16/12
to
Robert Myers wrote:
> While I'm sure the history is interesting, I suspect that the actual
> current state of the art is classified and that it probably does not
> rely exclusively on clocks built in laboratories. I say this warily,
> because there are people here who have spent a lot more time thinking
> about GPS than I have.
Warely indeed: The currently best lab clocks are _far_ beyond what you
> While I'm sure the history is interesting, I suspect that the actual
> current state of the art is classified and that it probably does not
> rely exclusively on clocks built in laboratories. I say this warily,
> because there are people here who have spent a lot more time thinking
> about GPS than I have.
can do with celestial observation.
>
> With the addition of techniques like Kalman filtering and probably not
> much more than a desktop PC, I would guess that your ability to tell
> time over a long period of time independent of earthbound devices
> dedicated to timekeeping should depend only on the limits of the
> accuracy of your astronomical observations.
The day-to-day and season-to-season wobble of the Earth is orders of
> With the addition of techniques like Kalman filtering and probably not
> much more than a desktop PC, I would guess that your ability to tell
> time over a long period of time independent of earthbound devices
> dedicated to timekeeping should depend only on the limits of the
> accuracy of your astronomical observations.
magnitude larger than the stability of our "lab clocks" which define UTC.
We have the IERS
(http://en.wikipedia.org/wiki/International_Earth_Rotation_and_Reference_Systems_Service)
which has as its main task to determine how badly off the Earth is (as a
timing device) at any given time.
>
> I haven't put pencil to paper (including the proverbial envelope), but
> if we can photograph a cluster of galaxies eleven billion years old and
> find it again with an eight meter aperture telescope, I suspect that we
> do not really need laboratory instruments to know what time it is. Or,
the current rotation rate of the Earth.
> perhaps I should say, the cosmos surrounding us will have its own
> opinion to offer, independent of earthbound estimates, and we can
> probably infer that opinion with a great deal of accuracy.
>
> What has changed since the original struggle to tell time is the easy
> availability of very inexpensive computation.
precision.
Casper H.S. Dik
May 16, 2012, 7:17:20 AM5/16/12
to
George Neuner <gneu...@comcast.net> writes:
>Not everything is GPS based or Internet connected ... but everything
>has a clock in it. I've got more than 30 devices containing clocks in
>my home: 7 in my kitchen alone. Since the cycle "deregulation"
>experiment started last summer, every one of them is running at a
>different rate. Some are drifting by 3-4 minutes per day.
That is weird; if the clocks are using the frequency from the
>Not everything is GPS based or Internet connected ... but everything
>has a clock in it. I've got more than 30 devices containing clocks in
>my home: 7 in my kitchen alone. Since the cycle "deregulation"
>experiment started last summer, every one of them is running at a
>different rate. Some are drifting by 3-4 minutes per day.
grid, they would all have the same error. Or are some of them
limiting the frequency?
One interesting feature of a alarm clock/radio/iPod player
I installed in my daughters room is that it takes the time from
the iPod. This was rather puzzling because the iPod was unused
for a bit and was several hours wrong. The clock reset itself
to the same but random time and that was rather puzzling until
we figured out that the clock was taking the time from the iPod.
Casper
Message has been deleted
nm...@cam.ac.uk
May 16, 2012, 7:48:04 AM5/16/12
to
In article <mbqb89-...@ntp6.tmsw.no>,
era I am referring to (1996). It was a gibbering nightmare, every
bit as bad as the X Toolkit was a decade earlier.
Regards,
Nick Maclaren.
>As you might know, the windows version of ntpd simply punts:
>
>It depends on being able to skip autoconfig and m4 completely, and the
>source code has to at least be portable between gcc and MS VC.
>
>All the remaining platform-specific stuff is placed in a separate
>directory structure, along with the Win* build/make files.
I had forgotten, but all of that cleaning up vastly postdates the
>
>It depends on being able to skip autoconfig and m4 completely, and the
>source code has to at least be portable between gcc and MS VC.
>
>All the remaining platform-specific stuff is placed in a separate
>directory structure, along with the Win* build/make files.
era I am referring to (1996). It was a gibbering nightmare, every
bit as bad as the X Toolkit was a decade earlier.
Regards,
Nick Maclaren.
Robert Myers
May 16, 2012, 11:23:00 AM5/16/12
to
On 5/16/2012 2:02 AM, Terje Mathisen wrote:
>
> Time is probably the physical value we can measure with the highest
> precision.
>
I should have been more explicit. The implied context was the ability
>
> Time is probably the physical value we can measure with the highest
> precision.
>
to tell time wherever you are, so as to figure out where you are. If
you are standing in a lab at IBM, you probably don't need navigational
aids, although one never knows.
Things like wobble and the annoying fact that the earth is not a perfect
spherical mass of uniform density must all be taken into account when
performing certain tasks, like tracking an astronaut's glove or when
delivering certain kinds of payloads with great accuracy to distant
targets. I'm reasonably certain that the full arsenal of tricks
includes more than atomic clocks. Historically, it has included the
bright star Canopus.
Just as with memory fetches, the only thing that really matters is
unpredictability. At one time, the ability to take known complications
into account in a timely fashion was almost certainly limited by the
computational means available. The number of photons available per unit
time limits your choices if you are time-constrained, but the mere fact
that the astrodynamics are complicated should no longer be an issue.
Robert.
nm...@cam.ac.uk
May 16, 2012, 11:37:12 AM5/16/12
to
In article <HDPsr.18659$6Y6....@newsfe19.iad>,
As several of us have explained before, the problem with many
complicated analyses is that they are numerically unstable (a.k.a.
chaotic), and the amount of computation AND THE AMOUNT AND PRECISION
OF THE INPUT DATA goes up exponentially with the accuracy needed in
the prediction.
I am not enough of an astrodynamics expert to know whether that is
the case here, but I do know enough to know that it is the quality
of the input data that limits the precision of the results. While
we can't throw exponentially more computational power at problems,
we can use a higher order of complexity than we can use for gathering
the data. It is that that is the killer.
Regards,
Nick Maclaren.
complicated analyses is that they are numerically unstable (a.k.a.
chaotic), and the amount of computation AND THE AMOUNT AND PRECISION
OF THE INPUT DATA goes up exponentially with the accuracy needed in
the prediction.
I am not enough of an astrodynamics expert to know whether that is
the case here, but I do know enough to know that it is the quality
of the input data that limits the precision of the results. While
we can't throw exponentially more computational power at problems,
we can use a higher order of complexity than we can use for gathering
the data. It is that that is the killer.
Regards,
Nick Maclaren.
Robert Myers
May 16, 2012, 12:51:59 PM5/16/12
to
On 5/16/2012 11:37 AM, nm...@cam.ac.uk wrote:
>
> As several of us have explained before, the problem with many
> complicated analyses is that they are numerically unstable (a.k.a.
> chaotic), and the amount of computation AND THE AMOUNT AND PRECISION
> OF THE INPUT DATA goes up exponentially with the accuracy needed in
> the prediction.
>
> I am not enough of an astrodynamics expert to know whether that is
> the case here, but I do know enough to know that it is the quality
> of the input data that limits the precision of the results. While
> we can't throw exponentially more computational power at problems,
> we can use a higher order of complexity than we can use for gathering
> the data. It is that that is the killer.
>
Chaotic and numerically unstable are different qualities that go
>
> As several of us have explained before, the problem with many
> complicated analyses is that they are numerically unstable (a.k.a.
> chaotic), and the amount of computation AND THE AMOUNT AND PRECISION
> OF THE INPUT DATA goes up exponentially with the accuracy needed in
> the prediction.
>
> I am not enough of an astrodynamics expert to know whether that is
> the case here, but I do know enough to know that it is the quality
> of the input data that limits the precision of the results. While
> we can't throw exponentially more computational power at problems,
> we can use a higher order of complexity than we can use for gathering
> the data. It is that that is the killer.
>
together only if you are lazy or wish to be vague about the credibility
of your calculations. How sensitive the results of certain calculations
are to uncertainties of input is something that we don't understand
nearly well enough, and probably never will, given the posture you
apparently share with other superintendents of large computing facilities.
As it is, we can apparently do astrodynamics with enough accuracy to
predict whether asteroids we can barely track will hit the earth in
several years' time.
Robert.
nm...@cam.ac.uk
May 16, 2012, 1:29:53 PM5/16/12
to
In article <7XQsr.9942$x11....@newsfe21.iad>,
mechanics is very often both. We actually have a very good idea
of their sensitivities to the accuracy of their input, and it has
damn all to do with modern computation - it is a classic result
in numerical analysis.
>As it is, we can apparently do astrodynamics with enough accuracy to
>predict whether asteroids we can barely track will hit the earth in
>several years' time.
The mind boggles. When I was just beginning to be taught the most
elementary forms of physics, we were taught the necessity of doing
orders of magnitude calculations and crude error analyses. If you
do either, you will see why that is a ridiculous irrelevance.
Regards,
Nick Maclaren.
Robert Myers <rbmye...@gmail.com> wrote:
>>
>Chaotic and numerically unstable are different qualities that go
>together only if you are lazy or wish to be vague about the credibility
>of your calculations. How sensitive the results of certain calculations
>are to uncertainties of input is something that we don't understand
>nearly well enough, and probably never will, given the posture you
>apparently share with other superintendents of large computing facilities.
Actually, they are very closely related and, in particular, orbital
>>
>Chaotic and numerically unstable are different qualities that go
>together only if you are lazy or wish to be vague about the credibility
>of your calculations. How sensitive the results of certain calculations
>are to uncertainties of input is something that we don't understand
>nearly well enough, and probably never will, given the posture you
>apparently share with other superintendents of large computing facilities.
mechanics is very often both. We actually have a very good idea
of their sensitivities to the accuracy of their input, and it has
damn all to do with modern computation - it is a classic result
in numerical analysis.
>As it is, we can apparently do astrodynamics with enough accuracy to
>predict whether asteroids we can barely track will hit the earth in
>several years' time.
elementary forms of physics, we were taught the necessity of doing
orders of magnitude calculations and crude error analyses. If you
do either, you will see why that is a ridiculous irrelevance.
Regards,
Nick Maclaren.
Robert Myers
May 16, 2012, 1:36:20 PM5/16/12
to
On 5/16/2012 1:29 PM, nm...@cam.ac.uk wrote:
> In article<7XQsr.9942$x11....@newsfe21.iad>,
> Robert Myers<rbmye...@gmail.com> wrote:
>>>
>> Chaotic and numerically unstable are different qualities that go
>> together only if you are lazy or wish to be vague about the credibility
>> of your calculations. How sensitive the results of certain calculations
>> are to uncertainties of input is something that we don't understand
>> nearly well enough, and probably never will, given the posture you
>> apparently share with other superintendents of large computing facilities.
>
> Actually, they are very closely related and, in particular, orbital
> mechanics is very often both. We actually have a very good idea
> of their sensitivities to the accuracy of their input, and it has
> damn all to do with modern computation - it is a classic result
> in numerical analysis.
>
Yes, but there is a million dollar prize on offer for a similar answer
> In article<7XQsr.9942$x11....@newsfe21.iad>,
> Robert Myers<rbmye...@gmail.com> wrote:
>>>
>> Chaotic and numerically unstable are different qualities that go
>> together only if you are lazy or wish to be vague about the credibility
>> of your calculations. How sensitive the results of certain calculations
>> are to uncertainties of input is something that we don't understand
>> nearly well enough, and probably never will, given the posture you
>> apparently share with other superintendents of large computing facilities.
>
> Actually, they are very closely related and, in particular, orbital
> mechanics is very often both. We actually have a very good idea
> of their sensitivities to the accuracy of their input, and it has
> damn all to do with modern computation - it is a classic result
> in numerical analysis.
>
in my area of professional expertise. If you know the answer, write it
down in haste, send it to the Clay Institute, and collect your prize.
>> As it is, we can apparently do astrodynamics with enough accuracy to
>> predict whether asteroids we can barely track will hit the earth in
>> several years' time.
>
> The mind boggles. When I was just beginning to be taught the most
> elementary forms of physics, we were taught the necessity of doing
> orders of magnitude calculations and crude error analyses. If you
> do either, you will see why that is a ridiculous irrelevance.
>
Robert.
Joe keane
May 16, 2012, 5:57:41 PM5/16/12
to
In article <jot5jn$ict$1...@needham.csi.cam.ac.uk>, <nm...@cam.ac.uk> wrote:
>It was once true for many computers. Up until at least the 1970s,
>IBM System/370s' main timer operated that way. I haven't heard of
>it being done in decades.
I forgot to turn on my brain.
>It was once true for many computers. Up until at least the 1970s,
>IBM System/370s' main timer operated that way. I haven't heard of
>it being done in decades.
I should have said 'electronic device'.
e.g. alarm clock, microwave oven
My desktop is of course capable of keeping track of time during a power
outage.
unknown
May 20, 2012, 1:50:10 PM5/20/12
to
"ChrisQ" <blac...@devnull.com> ha scritto nel messaggio
news:johdkb$7ss$1...@speranza.aioe.org...
> On 05/09/12 16:02, nm...@cam.ac.uk wrote:
>
> >
> > No, they aren't, as their domain name shows - they are commercial,
> > and have been since 1995.
> >
> > The government organisation that was the NPL opposed the change
> > but were told that servants should not question their masters'
> > decision to sell their indenture.
> >
> >
> > Regards,
> > Nick Maclaren.
>
> You are probably right. My argument would be that reports on research that
> were originally funded by the taxpayer should be available at nominal
cost,
> not some vastly inflated price, effectively at the taxpayers expense.
>
> Same with some online academic research reports, where the research was
> again
> originally funded by the taxpayer. That market has been cornered by
> publishers
> who's only interest is profit, not the dissemination of knowledge for it's
> own sake , nor any sense of the common good.
>
> A not so subtle form of discrimination, in fact...
>
> Regards,
>
> Chris
0 new messages