date:20110308

On Tue, Mar 8, 2011 at 1:14 PM, Uwe Klein
 wrote:

> IMHO the basic concept of your system is broken when you have
> sync to such high requirements and need external infrastructure
> to achieve this.
> this then is an extremely fickle system that lacks robustness.

I can't defend the design of CDMA cell technology.  But I'm sure a lot
of it was driven by trying to get as many calls as possible into a
limited bandwidth.  Another requirement for precision timing comes
from the need to measure the signal's speed of light delay.  They use
this to locate a phone by noting the differences in the delay to
several towers   A uS is about 1000 feet so they need to do this far
better than to a uS.

Does it lack robustness?  Some phone companies publish their system
availability statistics.  I guess we could look it up.  No need to
speculate if such a system would work or not.

Timing is actually simple and robust.   The central part is a very
stable local 10MHz oscillator.  All the timing is derived from that
local source.  Then they have A GPS receiver that outputs one pulse
per second.  Every second they measure the time from the leading edge
of the pulse to the next zero crossing of the oscillator  and
periodically adjust the oscillator frequency to keep that time a
constant.   It is robust in that if GPS goes away all that happens is
the oscillator is no longer measured.  But if it is well built, the
oscillator will run correctly for a long time without adjustment.
The system does not crash if GPS goes away.

=
Chris Albertson
Redondo Beach, California
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

2011-03-08 Thread Steve Kostecke

On 2011-03-08, Chuck Swiger  wrote:

> Seriously, each physical machine only has one RTC and crystal
> oscillator. It's useful to run one instance of ntpd in the Dom0 (or
> host ESX) context where it can actually work and keep this real
> hardware clock in sync.

NTP disciplines the system (i.e. kernel) clock, not the hardware clock
on the mother board.

> Running ntpd's in the other DomUs/guest VMs is almost entirely
> pointless; it might be useful only if Dom0->DomU time is busted,
> and even in that case, ntpd is unlikely to ever obtain good time
> synchronization running in a DomU.

That's debatable.

I have a Debian 6.0 system running as a VMWare guest. ntpd on this
system has no problem disciplining the clock.

Recent peer billboard snapshot:

steve@www:/var/log/ntpstats$ ntpq -p
remote   refid  st t when poll reach   delay   offset jitter

+ntp.my.isp  .GPS.   1 u   34 1024  377   60.6651.623 1.617
-enob... .PPS.   1 u 1041 1024  377   39.552   -8.220 2.120
*emit... .PPS.   1 u  184 1024  377   27.4043.936 1.347
+yamo... [snip]  2 u  768 1024  377   33.565   -1.757 2.256
-3snd... [snip]  2 u  102 1024  377   26.2947.261 1.179

Peerstats summary (last 10 days):

steve@www:/var/log/ntpstats$ (cat peerstats; zcat peerstats*.gz) | wc -l
2682
steve@www:/var/log/ntpstats$ (cat peerstats; zcat peerstats*.gz) | awk
-f /root/peer.awk 
identcnt mean rms  max delay dist disp

[snip]   516   -1.5021.4666.665   38.392  960.567 24.501
[snip]   535   -7.2441.5158.454   41.862  962.327 23.952
[snip]   5322.8201.7608.235   28.227  956.364 23.869
[snip]   521   -0.6731.3898.210   54.179  968.552 24.196
[snip]   5348.5651.7417.829   28.114  955.486 24.080

> You are better off running ntpdate (or sntp) periodically via cron in
> the DomUs.

Perhaps in certain cases, but not across the board.

-- 
Steve Kostecke 
NTP Public Services Project - http://support.ntp.org/

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] UK report on GPS vulnerabilities seems to overlook NTP

2011-03-08 Thread Uwe Klein


Chris Albertson wrote:

NTP simply is not good enough for use in a tower so it is not used.
And why would they use it when all towers by definition have a clear
view of the sky


IMHO the basic concept of your system is broken when you have
sync to such high requirements and need external infrastructure
to achieve this.
this then is an extremely fickle system that lacks robustness.

uwe

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] UK report on GPS vulnerabilities seems to overlook NTP

2011-03-08 Thread Harlan Stenn

Uwe wrote:
> No GPS seems to kill any CDMA mobile networks.
> GSM isn't affected at all.
> 
> How masochistic must one be to do telco infrastructure in such
> a haphazard way?

That seems more sadistic than masochistic to me...

H
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] UK report on GPS vulnerabilities seems to overlook NTP

2011-03-08 Thread Chuck Swiger

On Mar 8, 2011, at 11:28 AM, Chris Albertson wrote:
>> And exactly what is that difference? While ntp is perhaps too slow to
>> respond to local frequency changes, how do you see the difference
>> between keeping a computer's idea of local time accurate from keeping a
>> telecom's idea of local time accurate?
> 
> The telecom equipment needs to know the time with less then one
> microsecond error and to do that requires a clock that is at least 10X
> better.   NTP typicaly works at the microsecond level and has error
> 1000X more than is required.

It depends on which telecom equipment we're talking about; for example, the 
CDMA spec (IS-95, IS-2000 aka CDMA2000) requires the cell towers to be sync'ed 
to better than 10 microseconds.

Without making any special efforts (ie, just using random NTP servers from the 
pool), NTPd does typically offer around a 1 millisecond accuracy.  People who 
care a bit might configure nearby time sources and set up local peers, which 
will probably give accuracy around the +/- 100 microsecond level, and anyone 
who seriously cares about good timekeeping will find a way of using a PPS 
signal, in which case with kernel PPS_SYNC discipline, you can get accuracy 
better than microsecond level, depending on the quality of the PPS signal.

For example, PHK measured +/- 120 nanosecond accuracy using relatively 
inexpensive Soekris hardware:

  http://phk.freebsd.dk/soekris/pps/

Regards,
-- 
-Chuck

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] UK report on GPS vulnerabilities seems to overlook NTP

2011-03-08 Thread jimp

unruh  wrote:
> On 2011-03-08, j...@specsol.spam.sux.com  wrote:
>> JohnAllen  wrote:
>>> Maybe I read this too quickly, but the report published today by the
>>> UK Royal Academy of Engineering (see
>>> http://www.raeng.org.uk/news/publications/list/reports/RAoE_Global_Navigation_Systems_Report.pdf
>>> and also the BBC coverage at 
>>> http://www.bbc.co.uk/news/science-environment-12668230)
>>> seems to be saying that many organisations are vulnerable to GPS
>>> failures because their IT systems rely on GPS for precise time.
>>> 
>>> Can this be true? I would have thought that most systems are using
>>> NTP, and synchronising with diverse enough time sources that
>>> unavailable or incorrect GPS time would not cause short-term problems.
>>> 
>>> The relevant part of the report is on pages 13-14, where it says:
>>> 
>>> "GNSS timing is important for telecommunications applications.
>>> Synchronous
>>> technologies are much more efficient than asynchronous technologies
>>> but require a
>>> time source with appropriate accuracy, stability and reliability to
>>> operate effectively
>>> or at all, and GNSS can provide this. While ground-based clocks are
>>> accurate enough
>>> for this purpose (especially with the availability of chip scale
>>> atomic clocks (CSAC)),
>>> the synchronisation of many such clocks is problematic. GPS allows the
>>> derivation of
>>> synchronised UTC through resolving the signals from a number of
>>> satellites at a
>>> known position. Only a ???good guess??? of the current time is required
>>> and quartz clocks
>>> have therefore been adequate for this process making synchronous time
>>> keeping
>>> significantly more cost effective.
>>> 
>>> The use of time can be split into three clear and separate aspects:
>>> frequency
>>> control, time of day and common epoch (usually UTC) time slot
>>> alignment (also
>>> known as ???Phase???).
>>> Stability of radio communications transmission, constant digital traic
>>> low, time
>>> slot alignment and traditional services over next generation Ethernet
>>> based
>>> infrastructure are some of the features that good time and timing
>>> bring to
>>> communications networks.
>>> Financial systems increasingly need precise time stamping to
>>> prioritise trades and
>>> to provide an audit trail."
>>> 
>>> NTP is not mentioned anywhere in the report.
>>
>> Nor would I expect it to be.
>>
>> There is a big difference between keeping a computer's time of day clock
>> set to the current time (NTP) and maintaining timing or frequency control
>> in a telecom system.
> 
> And exactly what is that difference? While ntp is perhaps too slow to
> respond to local frequency changes, how do you see the difference
> between keeping a computer's idea of local time accurate from keeping a
> telecom's idea of local time accurate?

Most telecom systems care very little that it is exactly 12:34:56 Tuesday
and a lot that the leading edge of the XYZ sync pulse occurs every ABC
milliseconds and is DEF milliseconds wide, for example.

The difference is the difference between "time" and "timing".

Some systems don't care what the time of day is at all but do care about
timing.


-- 
Jim Pennino

Remove .spam.sux to reply.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] UK report on GPS vulnerabilities seems to overlook NTP

2011-03-08 Thread Uwe Klein


Jan Ceuleers wrote:

On 08/03/11 19:39, unruh wrote:


And exactly what is that difference? While ntp is perhaps too slow to
respond to local frequency changes, how do you see the difference
between keeping a computer's idea of local time accurate from keeping a
telecom's idea of local time accurate?



GPS is used not only for navigation and time-of-day synchronisation, but 
also as a source of frequency signals for use by synchronous (e.g. SDH) 
or plesiosynchronous (e.g. PDH) networks.


Jan


I was really surprised when this came up recently.

No GPS seems to kill any CDMA mobile networks.
GSM isn't affected at all.

How masochistic must one be to do telco infrastructure in such
a haphazard way?


uwe

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] UK report on GPS vulnerabilities seems to overlook NTP

2011-03-08 Thread Jan Ceuleers


On 08/03/11 19:39, unruh wrote:

And exactly what is that difference? While ntp is perhaps too slow to
respond to local frequency changes, how do you see the difference
between keeping a computer's idea of local time accurate from keeping a
telecom's idea of local time accurate?


GPS is used not only for navigation and time-of-day synchronisation, but 
also as a source of frequency signals for use by synchronous (e.g. SDH) 
or plesiosynchronous (e.g. PDH) networks.


Jan

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

On 2011-03-08, Miroslav Lichvar  wrote:
> On Tue, Mar 08, 2011 at 05:00:44PM +, unruh wrote:
>>  filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 
>>  58156.6,
>
>> Not at all sure how Mills comes into the picture. On a system where the
>> frequency fluctuates wildly, ntpd is not the right answer, nor is any
>> system. I suspect that the best you could do would be to run something
>> like ntpdate often and jump the clock around.
>
> The frequency offset in this case seems to be around 2% which is still
> well below the 10% maximum Linux can adjust. I'd try chrony before
> resorting to ntpdate, the timekeeping probably won't be very good, but
> at least the clock won't be stepped.

The problem on a VM system is that the frequency jumps around. Ie, when
the VM is running, its frequency should be very close to the fundamental
clock frequency, and when it is not running, its freq is 0. Thus the
time is a staircase, with the steps depending on how busy the VM is vs
how busy the other stuff on that computer is. This means that chrony's
frequency estimate also jumps around like mad (and means it is almost
always down around its "3data point" level in estimating frequency). Now
it certainly would be capable of adjusting a 2% frequency shift, if that
were consistant, but I am not sure how it would behave with the
inconsistant type of jumps you get in a VM. But I agree it would be
worth trying.

>

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] UK report on GPS vulnerabilities seems to overlook NTP

>> There is a big difference between keeping a computer's time of day clock
>> set to the current time (NTP) and maintaining timing or frequency control
>> in a telecom system.
>
> And exactly what is that difference? While ntp is perhaps too slow to
> respond to local frequency changes, how do you see the difference
> between keeping a computer's idea of local time accurate from keeping a
> telecom's idea of local time accurate?

The telecom equipment needs to know the time with less then one
microsecond error and to do that requires a clock that is at least 10X
better.   NTP typicaly works at the microsecond level and has error
1000X more than is required.

It's for the same reason a cloth tape measure is perfectly good for a
dress maker but useless to a machinist.

NTP simply is not good enough for use in a tower so it is not used.
And why would they use it when all towers by definition have a clear
view of the sky
=
Chris Albertson
Redondo Beach, California
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

2011-03-08 Thread Chuck Swiger

On Mar 8, 2011, at 9:13 AM, Ralph wrote:
> Well along those lines, what about creating a driver or deamon (for
> lack of something better to call it) that provides time to ntpd that
> gets that time from the host machine? 

I still haven't been able to figure out which virtualization system you are 
using, but normally it is better to run ntpd only in the "host ESX" for VMware, 
Dom0 for Xen, etc.  The strong recommendation is to only run ntpd in Dom0 using 
independent_wallclock set to 0, *unless* your DomU's then fail to keep sane 
time.  See:

  http://xen.epiuse.com/xen-faq.txt
  http://www.nabble.com/Unable-to-set-system-clock-on-domU-td22042252.html

"Q: Where does a domain get its time from?

A: Briefly, Xen reads the RTC at start of day and by default will track that 
with the precision of the periodic timer crystal. Xen's estimate of the 
wall-clock time can only be updated by domain 0. If domain 0 runs ntpdate, 
ntpd, etc. then the synchronised time will automatically be pushed down to Xen 
every minute (and written to the RTC every 11 minutes, just as normal x86 Linux 
does). All other domains always track Xen's wall-clock time: setting the date, 
or running ntpd, on these domains will not affect their wall-clock time. Note 
that the wall-clock time exported by Xen is UTC --- all domains must have 
appropriate timezone handling (i.e. a correct /etc/localtime file)."

The same thing applies to VMWare, as discussed in:

  http://www.vmware.com/pdf/vmware_timekeeping.pdf

...except it is controlled by a .vmx config option called "tools.syncTime = 
true", or possibly "vmware-guestd --cmd 'vmx.set_option synctime 1 1'" in the 
guest VM.  VMWare sometimes seems to encourage people to run ntpd in guest VMs, 
but I think that is badly flawed advice.

Seriously, each physical machine only has one RTC and crystal oscillator.  It's 
useful to run one instance of ntpd in the Dom0 (or host ESX) context where it 
can actually work and keep this real hardware clock in sync.  Running ntpd's in 
the other DomUs/guest VMs is almost entirely pointless; it might be useful only 
if Dom0->DomU time is busted, and even in that case, ntpd is unlikely to ever 
obtain good time synchronization running in a DomU.  You are better off running 
ntpdate (or sntp) periodically via cron in the DomUs.

Regards,
-- 
-Chuck

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

On Tue, Mar 8, 2011 at 9:04 AM, Ralph  wrote:
> I'm going to end this particular line of discussion because
> it is clear that this is a fruitless conversation and arguing
> back and forth about my personal ability to code a solution for
> VM time syncronization doesn't do anything for the problem at

No, the problem is not that no one can/will write the code.

Lets step away from computers and go back 300 years.  We'd have the
same problem if I had a clock that was so poor it would stop at random
times or even run backwards or instantly jump ahead.  Now I tell you
to look out the window at the big clock on the church tower and adjust
"fast/slow" lever on my poor clock.  OK so you do it as best you can
but then the clock stops for 5 minutes, so you push the lever to
full-speed fast then it catches up and over runs so you slow it again
only to find my cheap clock jumps 2 minutes ahead..   You will never
win.

We have the same EXACT problem.   If you can solve the above
mechanical clock problem then explain your solution to someone who CAN
code in C and he will be very happy to do it.   But so far most people
think that if the old clock is bad enough there is no possible
solution.

So I'll raise my hand.  I'll do it.  I right software like this all
day, every day 20+ years and counting.  You give me a fool-proof
solution to the 300 year old mechanical clock problem.   Tell me how
to adjust the fast/slow lever, prove that you are right and I'll write
the software.  We will both become heroes but I will give credit to
you.

OK there is a method that works on that old 300 year old clock.  Let
the spring wind doown so the clock stops.  Then every minute look out
the window and move the hands on my clock to match those on the clock
tower.  Yes you will keep busy but this works.   This is the method
you must use on your VM.  Just what everyone is saying -- you need to
get the time from the host OS and not try to let NTP adjust the rate
of the VM's clock as NTP will never win.

-- 
=
Chris Albertson
Redondo Beach, California
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] UK report on GPS vulnerabilities seems to overlook NTP

On 2011-03-08, j...@specsol.spam.sux.com  wrote:
> JohnAllen  wrote:
>> Maybe I read this too quickly, but the report published today by the
>> UK Royal Academy of Engineering (see
>> http://www.raeng.org.uk/news/publications/list/reports/RAoE_Global_Navigation_Systems_Report.pdf
>> and also the BBC coverage at 
>> http://www.bbc.co.uk/news/science-environment-12668230)
>> seems to be saying that many organisations are vulnerable to GPS
>> failures because their IT systems rely on GPS for precise time.
>> 
>> Can this be true? I would have thought that most systems are using
>> NTP, and synchronising with diverse enough time sources that
>> unavailable or incorrect GPS time would not cause short-term problems.
>> 
>> The relevant part of the report is on pages 13-14, where it says:
>> 
>> "GNSS timing is important for telecommunications applications.
>> Synchronous
>> technologies are much more efficient than asynchronous technologies
>> but require a
>> time source with appropriate accuracy, stability and reliability to
>> operate effectively
>> or at all, and GNSS can provide this. While ground-based clocks are
>> accurate enough
>> for this purpose (especially with the availability of chip scale
>> atomic clocks (CSAC)),
>> the synchronisation of many such clocks is problematic. GPS allows the
>> derivation of
>> synchronised UTC through resolving the signals from a number of
>> satellites at a
>> known position. Only a ???good guess??? of the current time is required
>> and quartz clocks
>> have therefore been adequate for this process making synchronous time
>> keeping
>> significantly more cost effective.
>> 
>> The use of time can be split into three clear and separate aspects:
>> frequency
>> control, time of day and common epoch (usually UTC) time slot
>> alignment (also
>> known as ???Phase???).
>> Stability of radio communications transmission, constant digital traic
>> low, time
>> slot alignment and traditional services over next generation Ethernet
>> based
>> infrastructure are some of the features that good time and timing
>> bring to
>> communications networks.
>> Financial systems increasingly need precise time stamping to
>> prioritise trades and
>> to provide an audit trail."
>> 
>> NTP is not mentioned anywhere in the report.
>
> Nor would I expect it to be.
>
> There is a big difference between keeping a computer's time of day clock
> set to the current time (NTP) and maintaining timing or frequency control
> in a telecom system.

And exactly what is that difference? While ntp is perhaps too slow to
respond to local frequency changes, how do you see the difference
between keeping a computer's idea of local time accurate from keeping a
telecom's idea of local time accurate?
>
>
>

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] UK report on GPS vulnerabilities seems to overlook NTP

2011-03-08 Thread jimp

JohnAllen  wrote:
> Maybe I read this too quickly, but the report published today by the
> UK Royal Academy of Engineering (see
> http://www.raeng.org.uk/news/publications/list/reports/RAoE_Global_Navigation_Systems_Report.pdf
> and also the BBC coverage at 
> http://www.bbc.co.uk/news/science-environment-12668230)
> seems to be saying that many organisations are vulnerable to GPS
> failures because their IT systems rely on GPS for precise time.
> 
> Can this be true? I would have thought that most systems are using
> NTP, and synchronising with diverse enough time sources that
> unavailable or incorrect GPS time would not cause short-term problems.
> 
> The relevant part of the report is on pages 13-14, where it says:
> 
> "GNSS timing is important for telecommunications applications.
> Synchronous
> technologies are much more efficient than asynchronous technologies
> but require a
> time source with appropriate accuracy, stability and reliability to
> operate effectively
> or at all, and GNSS can provide this. While ground-based clocks are
> accurate enough
> for this purpose (especially with the availability of chip scale
> atomic clocks (CSAC)),
> the synchronisation of many such clocks is problematic. GPS allows the
> derivation of
> synchronised UTC through resolving the signals from a number of
> satellites at a
> known position. Only a ‘good guess’ of the current time is required
> and quartz clocks
> have therefore been adequate for this process making synchronous time
> keeping
> significantly more cost effective.
> 
> The use of time can be split into three clear and separate aspects:
> frequency
> control, time of day and common epoch (usually UTC) time slot
> alignment (also
> known as ‘Phase’).
> Stability of radio communications transmission, constant digital traic
> low, time
> slot alignment and traditional services over next generation Ethernet
> based
> infrastructure are some of the features that good time and timing
> bring to
> communications networks.
> Financial systems increasingly need precise time stamping to
> prioritise trades and
> to provide an audit trail."
> 
> NTP is not mentioned anywhere in the report.

Nor would I expect it to be.

There is a big difference between keeping a computer's time of day clock
set to the current time (NTP) and maintaining timing or frequency control
in a telecom system.



-- 
Jim Pennino

Remove .spam.sux to reply.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

On 2011-03-08, Ralph  wrote:
> Well along those lines, what about creating a driver or deamon (for
> lack of something better to call it) that provides time to ntpd that
> gets that time from the host machine?  Similar to the local clock
> setting but somehow trusting the host.  Or would that still have the
> problems with high jitter where ntpd would reject the time source?

Yes. the virtual clock is not a very good clock. Instead when the
virtual OS reads the clock, it should be asking the underlying OS what
the time is, rather than reading its own clock.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

2011-03-08 Thread Miroslav Lichvar

On Tue, Mar 08, 2011 at 05:00:44PM +, unruh wrote:
>  filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 
>  58156.6,

> Not at all sure how Mills comes into the picture. On a system where the
> frequency fluctuates wildly, ntpd is not the right answer, nor is any
> system. I suspect that the best you could do would be to run something
> like ntpdate often and jump the clock around.

The frequency offset in this case seems to be around 2% which is still
well below the 10% maximum Linux can adjust. I'd try chrony before
resorting to ntpdate, the timekeeping probably won't be very good, but
at least the clock won't be stepped.

-- 
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

Well along those lines, what about creating a driver or deamon (for
lack of something better to call it) that provides time to ntpd that
gets that time from the host machine?  Similar to the local clock
setting but somehow trusting the host.  Or would that still have the
problems with high jitter where ntpd would reject the time source?

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] UK report on GPS vulnerabilities seems to overlook NTP

2011-03-08 Thread Terje Mathisen


JohnAllen wrote:

Maybe I read this too quickly, but the report published today by the
UK Royal Academy of Engineering (see
http://www.raeng.org.uk/news/publications/list/reports/RAoE_Global_Navigation_Systems_Report.pdf
and also the BBC coverage at 
http://www.bbc.co.uk/news/science-environment-12668230)
seems to be saying that many organisations are vulnerable to GPS
failures because their IT systems rely on GPS for precise time.

Can this be true? I would have thought that most systems are using
NTP, and synchronising with diverse enough time sources that
unavailable or incorrect GPS time would not cause short-term problems.


Most corporate ntp setups are probably using only network sources, and 
most of those lead to a gps as the S1 reference.


There are however alternative clock sources, and many of the pool 
servers use multiple references.


When GPS is temporarily unavailable, large parts of the ntp network will 
drop down one or two stratum levels, but we won't get too many orphaned 
islands.


My corporate setup with 3 Oncore gps clocks use both pool servers and 
configured internet sources, I know that a couple of these use radio 
clocks, so my internal network will drop from S2 to S4 or so.


Terje

--
- 
"almost all programming can be viewed as an exercise in caching"

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

On 2011-03-08, Richard B. Gilbert  wrote:
> On 3/8/2011 4:16 AM, Miroslav Lichvar wrote:
>> On Sun, Mar 06, 2011 at 11:22:34AM +, David Woolley wrote:
>>> Ralph wrote:
>>>
 filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 
 58156.6,
>>>
>>> Your frequency error is way outside any reasonable bounds, which is
>>> reflecting in a very high jitter, which is probably the ultimate
>>> cause of rejection.
>>>
>>> This system is not savable by NTP.
>>
>> This seems to be a common problem and with virtual machines getting
>> everywhere it will probably only get worse. I'm wondering how hard it
>> would be for ntpd to detect that the clock frequency is outside the
>> acceptable range and write a "your clock is broken" message to syslog?
>>
>
> NTP should be able to detect the problem without to much trouble.
>
> Fixing the problem will most likely prove to be more difficult.
>
> The political issues are likely to be most difficult of all.  I wouldn't 
> want to be the one to persuade Dave Mills to permit the necessary 
> modifications to the code.

Not at all sure how Mills comes into the picture. On a system where the
frequency fluctuates wildly, ntpd is not the right answer, nor is any
system. I suspect that the best you could do would be to run something
like ntpdate often and jump the clock around. At least it would probably
always jump in a positive direction, since the clock is most liable to
loose, not gain. And these frequency jumps ( which ntpd handles
particularly badly) are not gaussian at all. 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

I'm going to end this particular line of discussion because
it is clear that this is a fruitless conversation and arguing
back and forth about my personal ability to code a solution for
VM time syncronization doesn't do anything for the problem at
hand.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

On 2011-03-08, Ralph  wrote:
> Host OS is windows (2008 if we want to get specific)
>
> nose and corkskrew is nessecary because frankly I'm not
> accustomed to there being any difference between a guest
> OS and a physical OS in most cases and even when there is
> it hasn't been relevant what the host OS is.

It is when the underlying os has only a vague grasp on reality as far as
timing is concerned, and what you want is timing. Time is not something
ammenable to software control. It is an external. Isn't it good that you
have learned something, that there are some things where the underlying
OS does make a difference?

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

On 2011-03-08, Ralph  wrote:
>
>  
>> When are you going to start working on it?
>>  ... or are you asking others to do free programming
>>   for you, to work around your unique problem?
>  
> Maybe I deserve that flame for having ranted a bit, but
> I hardly think the problem of clock time that won't behave
> within a linux guest VM is 'unique'.  Do a google search on
> it, I'm clearly not the only one with this problem.

Of course it is not unique. It is also unsolveable. A VM simply does not
run in a way that it can keep accurate time. the only way to do it is to
have the underlying OS that runs the VM keep accurate time and to have
the VM gets its time from there. think about it-- there is no clock tha
tthe VM can discipline to keep accurate time. Clocks based on CPU cannot
work because the VM can be interrupted at will and stopped. Clocks based
on hardware cannot work because you would run into the problem of 5
different VM all fighting over the same hardware and constantly changing
what the other had done. 

>
> And are you saying that the mentality of the open source
> world ought to be one of 'no one is allowed to complain about
> anything because they ought to code the fix themselves'?  I've

No. It is because you believe that there is a solution-- so impliment
it. People have thought about it, and come to the conclusion that it is
really hard to do. You walk in and state it is not. Prove it-- or was
that just hot air. 

> participated in many open source projects and I enjoy contirbuting
> to the community, but I don't think that one ought to have to 
> be a contributor to be a user.  If open source isn't supposed to
> have consumers that aren't contributors from a coding perspective, 
> then it is most certainly a doomed concept - and I sincerly hope that
> is not the case.

But it also means that you have to put up with what others have done,
and you then should not sit there ranting about what they have not done. 
And you are ranting again. 

>
>
>> If you have never had a problem, what are you complaining about?
>
> I've never had a problem with a Windows guest.  I'm complaining about
> it being so difficult to find the answer to getting a properly running
> clock with a linux guest.
>
>> Nothing that can't be fixed by the VM ware vendors, I'm sure.
>
> And if they gave a flying flip about the many different flavor of linux, I'm
> sure the world would be a better place.  But in the meantime, since I'm not
> running one of the very few flavors that they actually support, I have
> to find other solutions.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] UK report on GPS vulnerabilities seems to overlook NTP

2011-03-08 Thread JohnAllen

Maybe I read this too quickly, but the report published today by the
UK Royal Academy of Engineering (see
http://www.raeng.org.uk/news/publications/list/reports/RAoE_Global_Navigation_Systems_Report.pdf
and also the BBC coverage at
http://www.bbc.co.uk/news/science-environment-12668230)
seems to be saying that many organisations are vulnerable to GPS
failures because their IT systems rely on GPS for precise time.

Can this be true? I would have thought that most systems are using
NTP, and synchronising with diverse enough time sources that
unavailable or incorrect GPS time would not cause short-term problems.

The relevant part of the report is on pages 13-14, where it says:

"GNSS timing is important for telecommunications applications.
Synchronous
technologies are much more efficient than asynchronous technologies
but require a
time source with appropriate accuracy, stability and reliability to
operate effectively
or at all, and GNSS can provide this. While ground-based clocks are
accurate enough
for this purpose (especially with the availability of chip scale
atomic clocks (CSAC)),
the synchronisation of many such clocks is problematic. GPS allows the
derivation of
synchronised UTC through resolving the signals from a number of
satellites at a
known position. Only a ‘good guess’ of the current time is required
and quartz clocks
have therefore been adequate for this process making synchronous time
keeping
significantly more cost effective.

The use of time can be split into three clear and separate aspects:
frequency
control, time of day and common epoch (usually UTC) time slot
alignment (also
known as ‘Phase’).
Stability of radio communications transmission, constant digital traic
low, time
slot alignment and traditional services over next generation Ethernet
based
infrastructure are some of the features that good time and timing
bring to
communications networks.
Financial systems increasingly need precise time stamping to
prioritise trades and
to provide an audit trail."

NTP is not mentioned anywhere in the report.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Beginner needs help...

On Mon, Mar 7, 2011 at 10:32 PM, Terje Mathisen <"terje.mathisen at
tmsw.no"@ntp.org> wrote:

>> The problem is that on an isolated island of N servers you want to
>> automatically select the one server that has the "best" clock even
>> when some computers are not running.  I think "orphan" handles this.
>
> A RAIG (Redundant Array of Inexpensive GPSs) setup solves that problem as
> well. :-)

Yes, I know,  good timing GPSes are being dumped on ebay for as low as
$15 and really good ones for $50.  But, I think there will always be
cases of isolated networks.   Here at work for example some of the
labs have to disconnect from the outside world when processing
sensitive information.  Many other cases of unavoidable "island
networks"

-- 
=
Chris Albertson
Redondo Beach, California
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

On Tue, Mar 8, 2011 at 1:16 AM, Miroslav Lichvar  wrote:
> On Sun, Mar 06, 2011 at 11:22:34AM +, David Woolley wrote:

> This seems to be a common problem and with virtual machines getting
> everywhere it will probably only get worse. I'm wondering how hard it
> would be for ntpd to detect that the clock frequency is outside the
> acceptable range and write a "your clock is broken" message to syslog?

It's the old joke again:  Man who has one clock knows what time it is.
 A man with two clocks is not sure.   How is ntpd to know the PCs
clock is not good unless there are enough clocks that it can apply
something like it's clock selection algorithm.   You need a minimum of
two lus the PC's

ntpd would need to see a set of servers that track each other well but
as a group "bounce around". Then it could deduce that it was bouncing,
not the set.
-- 
=
Chris Albertson
Redondo Beach, California
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

2011-03-08 Thread Richard B. Gilbert


On 3/8/2011 4:16 AM, Miroslav Lichvar wrote:

On Sun, Mar 06, 2011 at 11:22:34AM +, David Woolley wrote:

Ralph wrote:


filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 58156.6,


Your frequency error is way outside any reasonable bounds, which is
reflecting in a very high jitter, which is probably the ultimate
cause of rejection.

This system is not savable by NTP.


This seems to be a common problem and with virtual machines getting
everywhere it will probably only get worse. I'm wondering how hard it
would be for ntpd to detect that the clock frequency is outside the
acceptable range and write a "your clock is broken" message to syslog?



NTP should be able to detect the problem without to much trouble.

Fixing the problem will most likely prove to be more difficult.

The political issues are likely to be most difficult of all.  I wouldn't 
want to be the one to persuade Dave Mills to permit the necessary 
modifications to the code.


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy


"Rob"  wrote in message []

VMware advises to run ntpd in the guest.


Thanks, Rob.  I wonder whether this is a change from their earlier 
suggestions?  I see that they now do suggest this as one route (as well as 
providing their own time synchronisation program as another option).  Are 
the recommendations they make on page 18, in the paragraph: "Using NTP in 
Linux and Other Guests"  sensible ones for today's NTP?


 http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf

As I've noted before, using Windows as a host you might want to tie the 
timekeeping rather more closely to a local reference with the appropriate 
minpoll and maxpoll values, and find a good server on the LAN to use.


Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

2011-03-08 Thread Uwe Klein


Ralph wrote:

Host OS is windows (2008 if we want to get specific)

nose and corkskrew is nessecary because frankly I'm not
accustomed to there being any difference between a guest
OS and a physical OS in most cases and even when there is
it hasn't been relevant what the host OS is.


Hi Ralph,

You are talking about windows as host OS. imho broken by design.

Linux on occasion changes too fast for ntp, a known issue.

But Windows seems to be a constantly changing but unimprooving PITA
going by what percolated through this ng.

so it would have ben a nice thing to have started your initial
post with :

Running
ntv v4.2
on  Mandriva $mversion linux kernel 2.6...
in aVM from $vendor
hosted on $windows_version.

from my vantage point having "new" problems inside a VM
has a good chance of being caused by the VM and nothing else.

uwe

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

"Ralph"  wrote in message 
news:d695207e-04ec-4664-8580-35bc25806...@glegroupsg2000goo.googlegroups.com...

Well it started out as NTP's problem because apparently the
clock instability makes it so NTP can't run right on the guest.
I understand this isn't so much an NTP problem if the expectation
is that NTP can't run on a guest OS, but since everyone seemed to
state so matter of factly that the guest should be able get the
time from the host, I thought someone here might be able to provide
a lead on how that is achieved.


I think you need to as the VM vendor about that.
Did the VMWare paper help at all?

Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

2011-03-08 Thread Rob

David J Taylor  wrote:
> "Ralph"  wrote in message 
> news:d695207e-04ec-4664-8580-35bc25806...@glegroupsg2000goo.googlegroups.com...
>> Well it started out as NTP's problem because apparently the
>> clock instability makes it so NTP can't run right on the guest.
>> I understand this isn't so much an NTP problem if the expectation
>> is that NTP can't run on a guest OS, but since everyone seemed to
>> state so matter of factly that the guest should be able get the
>> time from the host, I thought someone here might be able to provide
>> a lead on how that is achieved.
>
> I think you need to as the VM vendor about that.
> Did the VMWare paper help at all?

VMware advises to run ntpd in the guest.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Beginner needs help...

"Terje Mathisen" <"terje.mathisen at tmsw.no"> wrote in message 
news:54vg48-ttp2@ntp6.tmsw.no...

[]
A RAIG (Redundant Array of Inexpensive GPSs) setup solves that problem 
as well. :-)


I.e. as I wrote I have 3 Oncores as well.

Terje


3 GPS for about US $100 and a little soldering:

 http://www.sureelectronics.net/goods.php?id=99

Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy


Sorry if the formatting is bad.
I don't have a local newsfeed (ISPs seems to have abonded providing 
that)
so I have to post via google.  I wraps fine on their editor but I can 
see

where it might not format well in the newsfeed.


Ralph,

You may be able to use one of the free news services instead, for example:

 http://www.eternal-september.org/

David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

Host OS is windows (2008 if we want to get specific)

nose and corkskrew is nessecary because frankly I'm not
accustomed to there being any difference between a guest
OS and a physical OS in most cases and even when there is
it hasn't been relevant what the host OS is.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

"Ralph"  wrote in message 
news:c5b90638-395f-4e77-8761-f99c25343...@glegroupsg2000goo.googlegroups.com...

Ok. The host OS time is fine so I'd have no problem using that
as the source for my linux guest.

What no one has provided yet is an answer to 'how' to get the
linux guest VM to get the proper time from the host?


How is that NTP's problem?  I would have thought the task should be 
performed by the virtual machine you are using, and you would not need to 
run NTP on the guest OS.


Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

Well it started out as NTP's problem because apparently the
clock instability makes it so NTP can't run right on the guest.
I understand this isn't so much an NTP problem if the expectation
is that NTP can't run on a guest OS, but since everyone seemed to
state so matter of factly that the guest should be able get the
time from the host, I thought someone here might be able to provide
a lead on how that is achieved.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy


 
> When are you going to start working on it?
>  ... or are you asking others to do free programming
>   for you, to work around your unique problem?
 
Maybe I deserve that flame for having ranted a bit, but
I hardly think the problem of clock time that won't behave
within a linux guest VM is 'unique'.  Do a google search on
it, I'm clearly not the only one with this problem.

And are you saying that the mentality of the open source
world ought to be one of 'no one is allowed to complain about
anything because they ought to code the fix themselves'?  I've
participated in many open source projects and I enjoy contirbuting
to the community, but I don't think that one ought to have to 
be a contributor to be a user.  If open source isn't supposed to
have consumers that aren't contributors from a coding perspective, 
then it is most certainly a doomed concept - and I sincerly hope that
is not the case.


> If you have never had a problem, what are you complaining about?

I've never had a problem with a Windows guest.  I'm complaining about
it being so difficult to find the answer to getting a properly running
clock with a linux guest.

> Nothing that can't be fixed by the VM ware vendors, I'm sure.

And if they gave a flying flip about the many different flavor of linux, I'm
sure the world would be a better place.  But in the meantime, since I'm not
running one of the very few flavors that they actually support, I have
to find other solutions.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

Sorry if the formatting is bad.
I don't have a local newsfeed (ISPs seems to have abonded providing that)
so I have to post via google.  I wraps fine on their editor but I can see 
where it might not format well in the newsfeed.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy