Re: [ntp:questions] Linux : ntp-dev-4.2.7p84 : Local clock not getting synced.

[Heiko Gerstung]

Am 03.01.2011 23:24, schrieb Harlan Stenn:
> Martin wrote:
>> Those "special" 127.127.x.y addresses are somewhat sorted out when parsing
>> the configuration options and treated in a special way. I'm not sure it
>> would work, and I'm not even sure if it would be expected to work. Dave
>> Mills, Dave Hart, and Danny, what's your opinion on using IPv6-style
>> addresses to specify refclocks?
> 
> I'd vote against this because I don't see the value in it.
> 
> I'm more inclined to create a new config keyword, "refclock", and
> probably have it take x.y as its primary argument.  Then, for backward
> compatibility, we'd map "server 127.127.x.y ..." to "refclock x.y ...".

I would second that motion. I like config files that are human readable
and speak for themselves. I would even like to have the possibility to
define a refclock like this:

refclock "myGPS1" type 8 id 0 mode 135 time1 

and then would like to find it in the ntpq billboard like this:

 remote   refid  st t when poll reach   delay   offset
jitter
==
 LOCAL(0).LOCL.  12 l  15h   1600.0000.000
 0.000
*myGPS1(0)   .GPS.0 l7   16  3760.0000.000
 0.002

But I see that this might be too much to ask for at this point :-). So,
Harlan's approach to change server into refclock is something I really
would love to see!

> But I'd also want to look much harder at this, and figure out what other
> interactions there might be.

We could and should keep the old mechanism for backwards compatibility,
i.e. allow to specify a reflock with the server 127.127.x.x statement,
too. Putting up "refclock" as the primary/preferred way to configure a
refclock would be a documentation task and we could think about
obsoleting the "old" mechanism at some point in the future, if we want.

> I'm also still interested in looking in to a "refclock definition
> language", and converting *all* of our refclock .c files to this new
> format.  I think it would be a useful step forward, and it would help us
> get rid of the hardcoded and centrally-managed "refclock types"
> currently hardwired in include/ntp.h .

Yep, but I think that the SHM driver is already a good way to implement
refclock drivers that are independent of the NTP code and therefore work
with NTP versions that are older than the SHM-implementing refclock
drivers. We could maybe enhance the shared memory interface to allow the
refclock drivers to pass on more information, i.e. configuration options
from ntpd to the refclock driver process and additional status
information/variables from the refclock to ntpd.

For migration, we could either keep the old refclock drivers in the code
or create a new "legacy NTP refclock driver daemon" that runs as its own
process and translates between the SHM interface of the new ntpd and the
refclock.

Just my 2 cents.

Regards,
 Heiko

> H


-- 

Heiko Gerstung

*MEINBERG Funkuhren* GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone: +49 (0)5281 9309-25
Fax: +49 (0)5281 9309-30
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Email: heiko.gerst...@meinberg.de 
Web: www.meinberg.de 


*MEINBERG - Accurate Time Worldwide*

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

[ntp:questions] [ntp:announce] NTP 4.2.6p3 Released

[NTP Public Services Project]

Redwood City, CA - 2011/01/03 - The NTP Public Services Project
(http://support.ntp.org/) is pleased to announce that NTP 4.2.6p3,
a Point Release of the NTP Reference Implementation from the NTP
Project, is now available at http://www.ntp.org/downloads.html and
http://support.ntp.org/download.

File-size: 4270377 bytes

MD5 sum: 59876a9009b098ff59767ee45a88ebd2 

Focus: Bug fixes and portability improvements

Severity: Medium

This is a recommended upgrade.

This release includes build infrastructure updates, code clean-ups,
minor bug fixes, fixes for a number of minor ref-clock issues, and
documentation revisions.

Portability improvements in this release affect AIX, Atari FreeMiNT,
FreeBSD4, Linux and Microsoft Windows.

New features / changes in this release:

Build system

* Use lsb_release to get information about Linux distributions.
* 'test' is in /usr/bin (instead of /bin) on some systems.
* Basic sanity checks for the ChangeLog file.
* Source certain build files with ./filename for systems without . in PATH.
* IRIX portability fix.
* Use a single copy of the "libopts" code.
* autogen/libopts upgrade.
* configure.ac m4 quoting cleanup.

ntpd

* Do not bind to IN6_IFF_ANYCAST addresses.
* Log the reason for exiting under Windows.
* Multicast fixes for Windows.
* Interpolation fixes for Windows.
* IPv4 and IPv6 Multicast fixes.
* Manycast solicitation fixes and general repairs.
* JJY refclock cleanup.
* NMEA refclock improvements.
* Oncore debug message cleanup.
* Palisade refclock now builds under Linux.
* Give RAWDCF more baudrates.
* Support Truetime Satellite clocks under Windows.
* Support Arbiter 1093C Satellite clocks under Windows.
* Make sure that the "filegen" configuration command defaults to "enable".
* Range-check the status codes (plus other cleanup) in the RIPE-NCC driver.
* Prohibit 'includefile' directive in remote configuration command.
* Fix 'nic' interface bindings.
* Fix the way we link with openssl if openssl is installed in the base
  system.

ntp-keygen

* Fix -V coredump.
* OpenSSL version display cleanup.

ntpdc

* Many counters should be treated as unsigned.

ntpdate

* Do not ignore replies with equal receive and transmit timestamps.

ntpq

* libntpq warning cleanup.

ntpsnmpd

* Correct SNMP type for "precision" and "resolution".
* Update the MIB from the draft version to RFC-5907.

sntp

* Display timezone offset when showing time for sntp in the local
  timezone.
* Pay proper attention to RATE KoD packets.
* Fix a miscalculation of the offset.
* Properly parse empty lines in the key file.
* Logging cleanup.
* Use tv_usec correctly in set_time().
* Documentation cleanup.

Please report any bugs, issues, or desired enhancements at
http://bugs.ntp.org/.

The NTP (Network Time Protocol) Public Services Project, which is
hosted by Internet Systems Consortium, Inc. (http://www.isc.org/),
provides support and additional development resources for the Reference
Implementation of NTP produced by the NTP Project (http://www.ntp.org/).
___
announce mailing list
annou...@lists.ntp.org
http://lists.ntp.org/listinfo/announce
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?

[Terje Mathisen]

Dave Hart wrote:

On Mon, Jan 3, 2011 at 16:34 PM, Martin Burnicki
  wrote:

I have configured the w32time service to start automatically, but it
does not seem to start automatically, so my system time is approximately
2 minutes behind until I run "net start w32time&&  w32tm /resync" in an
elevated (with administrative privileges) cmd.exe session.


So this is already a different problem which should be fixed. Ntpdate should
also be able to set the correct system time initially, but I'm not sure the
NTP package can even be built for Windows on IA32.


http://davehart.net/ntp/win/x86/ has a lot of evidence that should
assure you.  By the way, now would be a good time to verify the
current ntp-dev sources build on VC6 and the result works, as another
-dev ->  -stable transition is about due.  It's been just over a year
since 4.2.6 came out, and a lot of good stuff has been introduced in
4.2.7.

I am aware of no one else building NTP on Windows using a compiler
older than Visual Studio 2008 recently, despite highly duplicative and
maintenance-heavy vc6, vs2003 and vs2005 project files.  I wish there
were others with access to VC6 reporting problems sooner, but I expect
once again it will be left to you and I to ping-pong through any vc6
build issues that have crept up.


I still have my VC6 ISOs, I could load them into a VMware client machine 
(I don't expect it to be possible to install VC6 alongside VS2008?).


I have been compiling and uploading new releases of both ntp stable and 
-dev about weekly for a while now, but as you noted this has been with 
VS2008.


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] Linux : ntp-dev-4.2.7p84 : Local clock not getting synced.

[Harlan Stenn]

Martin wrote:
> Those "special" 127.127.x.y addresses are somewhat sorted out when parsing
> the configuration options and treated in a special way. I'm not sure it
> would work, and I'm not even sure if it would be expected to work. Dave
> Mills, Dave Hart, and Danny, what's your opinion on using IPv6-style
> addresses to specify refclocks?

I'd vote against this because I don't see the value in it.

I'm more inclined to create a new config keyword, "refclock", and
probably have it take x.y as its primary argument.  Then, for backward
compatibility, we'd map "server 127.127.x.y ..." to "refclock x.y ...".

But I'd also want to look much harder at this, and figure out what other
interactions there might be.

I'm also still interested in looking in to a "refclock definition
language", and converting *all* of our refclock .c files to this new
format.  I think it would be a useful step forward, and it would help us
get rid of the hardcoded and centrally-managed "refclock types"
currently hardwired in include/ntp.h .

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

Re: [ntp:questions] MSF outages

[Mr Dave Baxter]

In article , 
sn...@lordynet.org says...
> 
> Hi
> 
> I have an MSF clock from a converted Conrad DCF module
> that has been ticking for over for most of 2010. I've
> been  assembling a DIY receiver but keep hitting a brick
> wall. On looking back at logs from my Conrad module now
> see that the 'brick walls' were all at periods when MSF
> was not being received by the Conrad module either.
> 
> I can understand the service being down due to the
> severe weather but there is no indication of this on NPL
> MSF status page.
> 
> Anyone else having problems receiving MSF?
> 
> Today the modulation level appears to less than 50%
> rather than on-off modulation.
> 
> 
> David

Hi.

In an urban environment, the background noise level at 60kHz can be 
embarrasingly high at times, what with all the SMPS powered gadgets that 
litter the place, some 'phone chargers when left in a socket and 
powered, but with no load, are particularly noisy!   EM polution etc.

Many "consumer" grade MSF/DCF RX's are not much more than a tuned 
circuit and a detector, that will not reject any other noise that well, 
so you see a less than 100% on/off modulation.

I once had a synchronous MSF RX, that was extremely good at rejecting 
noise.  Wish I'd never got rid of that now.

I had a listen recently with a LF communications RX, that is spec'd to 
go down below 60k, and with bandwidths down to 200Hz, the background 
hash at my location (probably much of it is mine!) was a real eye 
opener.   Thankfully, my own NTP servers are locked to GPS, but I do 
from time to time use a 'scope triggered to a GPS/PPS signal, just to 
check the state of the MSF signal/noise levels.

When it was radiated from Rugby, no problem.  Since the move to Anthorn, 
though the signal level is within the projected spec's, the background 
noise level is now so much higher % wise, than it was before.

Oh, I'm located in North Bucks (UK)

Cheers, and Happy New Year and all that.

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

Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?

[David J Taylor]

[]

I believe so, to the extent you can load the driver at all:  Most new
Windows installations are x64, and Microsoft makes it enough of a pain
to use unsigned drivers on 64-bit versions of Windows that I suspect
it's impractical for unattended use.  I believe unsigned drivers are
still allowed in x86 installs of Vista and Win7, likely with a few
layers of Danger! popups.  This is a bit of a looming brick wall for
my serialpps.sys hack, unless some kind soul manages the unlikely feat
of getting it through WHQL driver certification and signed by
Microsoft..

Cheers,
Dave Hart


It would certainly be good to have kernel-mode timestamps in Win-64. 
Although the average jitter reduction achieved by switching from user-mode 
to kernel-mode is not great (say from 3.5 microseconds to 2.2 
microseconds), the greater consistency and freedom from jitter spikes may 
well be helpful.  Here's one observation of a PC here:


 http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#kernel

Cheers,
David 


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

Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?

[Dave Hart]

On Mon, Jan 3, 2011 at 16:34 PM, Martin Burnicki
 wrote:
>> I have configured the w32time service to start automatically, but it
>> does not seem to start automatically, so my system time is approximately
>> 2 minutes behind until I run "net start w32time && w32tm /resync" in an
>> elevated (with administrative privileges) cmd.exe session.
>
> So this is already a different problem which should be fixed. Ntpdate should
> also be able to set the correct system time initially, but I'm not sure the
> NTP package can even be built for Windows on IA32.

http://davehart.net/ntp/win/x86/ has a lot of evidence that should
assure you.  By the way, now would be a good time to verify the
current ntp-dev sources build on VC6 and the result works, as another
-dev -> -stable transition is about due.  It's been just over a year
since 4.2.6 came out, and a lot of good stuff has been introduced in
4.2.7.

I am aware of no one else building NTP on Windows using a compiler
older than Visual Studio 2008 recently, despite highly duplicative and
maintenance-heavy vc6, vs2003 and vs2005 project files.  I wish there
were others with access to VC6 reporting problems sooner, but I expect
once again it will be left to you and I to ping-pong through any vc6
build issues that have crept up.

> Hm, BTW, I don't know how I could load such a kernel driver under Windows?
> Under NT you could install non-PNP drivers like a service, and then load
> them with "net start my_kernel_driver". In current systems drivers are
> loaded by the kernel automatically, e.g. if a PCI card is detected which is
> handled by that driver. Don't know if you can still load a kernel driver
> manually.

I believe so, to the extent you can load the driver at all:  Most new
Windows installations are x64, and Microsoft makes it enough of a pain
to use unsigned drivers on 64-bit versions of Windows that I suspect
it's impractical for unattended use.  I believe unsigned drivers are
still allowed in x86 installs of Vista and Win7, likely with a few
layers of Danger! popups.  This is a bit of a looming brick wall for
my serialpps.sys hack, unless some kind soul manages the unlikely feat
of getting it through WHQL driver certification and signed by
Microsoft..

Cheers,
Dave Hart
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?

[David Woolley]

Martin Burnicki wrote:


also be able to set the correct system time initially, but I'm not sure the
NTP package can even be built for Windows on IA32.



Did you mean that?  NTP has been buildable for 32 bit Intel machines 
running Windows, since NT 3.5, and Meinberg provide an installer for 32 
bit Windows.


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

Re: [ntp:questions] Linux : ntp-dev-4.2.7p84 : Local clock not getting synced.

[Martin Burnicki]

Mike S wrote:
> At 08:44 AM 1/3/2011, Martin Burnicki wrote...
>>Mike S wrote:
>> > At 02:21 PM 1/2/2011, David Woolley wrote...
>> >>Arul Kumar Chellappan wrote:
>> >>>server  ::1
>> >>>fudge   ::1 stratum 10
>>
>>The line above tries to fudge the localhost IP address, i.e. the
>>loopback
>>interface, which indeed makes no sense.
> 
> True.
> 
> It's not quite clear what Arul was trying to achieve, but it looks like
> he was trying to define a local refclock using both IPv4 and IPv6
> terminology. It's easy to see how he may have come up with the ::1
> address, since NTP is using what look like loopback addresses. All IPv4
> 127.0.0.0/8 addresses map to IPv6 ::1.
> 
> I don't know if ::127.127.1.0 (or ::7f7f:100) would work (I suppose it
> should, if NTP has full IPv6 support).

Those "special" 127.127.x.y addresses are somewhat sorted out when parsing
the configuration options and treated in a special way. I'm not sure it
would work, and I'm not even sure if it would be expected to work. Dave
Mills, Dave Hart, and Danny, what's your opinion on using IPv6-style
addresses to specify refclocks?
 
> My response was to the original comment that "you can't fudge stratum
> on a server." "Server" in this context obviously referring to the
> "server..." configuration file section which was quoted.

I agree but just wanted to shed some light on this. Of course you need to
distinguish whether "server" refers to an upstram NTP node on the network,
or a configuration line using the "server" keyword.
 
> NTP documentation doesn't seem to define whether a refclock is
> different than a server, or just a special case. The configuration file
> commands point to the latter.

AFAIK in many cases refclocks are treated in the same way as servers, but
there are certainly also exceptions where refclocks are treated in  a
different way.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

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

Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?

[Martin Burnicki]

Brolin,

sorry for the late reply. I've been offline due to a really bad cold.

Brolin Empey wrote:
> Martin Burnicki wrote:
>> Brolin,
>>
>> Brolin Empey wrote:
>>> I run Windows 7 Professional IA-32 with RealTimeIsUniversal=1 on
>>> brolin-V13, my Dell Vostro V13 laptop. This means brolin-V13?s hardware
>>> clock (RTC) runs in UTC, as it should, instead of the local time zone,
>>> as Microsoft still uses for the completely illogical default
>>> configuration.  RealTimeIsUniversal=1 is /finally/ fixed and fully
>>> working beginning in Windows Vista SP2 + Windows 7, but there is still a
>>> problem:  When RealTimeIsUniversal=0, which is also used when the
>>> RealTimeIsUniversal key does not exist, Windows 7 writes the Windows NT
>>> system time to the hardware clock during the shut down process.  When
>>> RealTimeIsUniversal=1, though, the Windows NT system time is never
>>> written to the hardware clock.
>>
>> Hm, this sounds like a Windows bug ...
> 
> No, it is by design. :(

Hm, then this is IMO a bad design. I knew there was a registry flag telling
Windows the RTC runs on UTC instead of local time, and yet I had assumed
the OS would read UTC instead of local time from the RTC at startup, and
write UTC instead of local time to the RTC on shutdown.
 
>>> Consequently, I have to boot Ubuntu from
>>> a USB flash drive (brolin-V13 has no optical disc drive (ODD).), then
>>> use ntpdate-debian + hwclock to synchronise the Linux system clock with
>>> an NTP server on the Internet, then write the
>>> sufficiently-accurate-for-me Linux system time to the hardware clock so
>>> Windows 7 will set the Windows NT system clock from the accurate time in
>>> the hardware clock.  After some time (at least 1 week, not sure.),
>>> though, my hardware clock is approximately 2 minutes behind the correct
>>> time from an NTP server, but Windows 7 never writes the Windows NT
>>> system time to the hardware clock when RealTimeIsUniversal=1, so I have
>>> to use my Ubuntu USB flash drive again.
>>
>> Do you need correct time for the on-board RTC for a special application?
> 
> No, but I still want my clocks to have accurate time.
> 
>> As
>> far as I know this is only used to initialize the Windows system time
>> when Windows starts up, so your system time may be wrong until ntpd has a
>> chance to correct it, i.e. it can reach an NTP server.
> 
> I am using Microsoft?s w32time service, not ntpd.

OK.

> I have configured the w32time service to start automatically, but it
> does not seem to start automatically, so my system time is approximately
> 2 minutes behind until I run "net start w32time && w32tm /resync" in an
> elevated (with administrative privileges) cmd.exe session.

So this is already a different problem which should be fixed. Ntpdate should
also be able to set the correct system time initially, but I'm not sure the
NTP package can even be built for Windows on IA32.

>>> I know the proper solution is
>>> to get Microsoft to change Windows 7 so it can write the Windows NT
>>> system time to the hardware clock even when RealTimeIsUniversal=1, but
>>> that has not yet happened.  I have at least asked a Microsoft employee
>>> about it, though, so they know users (well, at least 1 user. :)) want
>>> the feature.  I can use w32time to force a synchronisation, but then I
>>> have to do that every time I boot Windows 7.  brolin-V13 travels with me
>>> between home and work, so it is not always running.  Maybe this causes
>>> the hardware clock to fall behind, but I do not think I can prevent
>>> having to shut down and boot brolin-V13 on a daily basis.  Since I do
>>> not know if Microsoft will ever enable Windows 7 to write the Windows NT
>>> system time to the hardware clock when RealTimeIsUniversal=1, the next
>>> best solution is probably to write a hwclock.exe application for Windows
>>> NT, but I am hoping someone has already implemented this functionality
>>> in an application such as an NTP client.  Googling ?hwclock.exe? returns
>>> lots of noise because some malware uses this file name, but I have not
>>> found any real hwclock.exe equivalent to hwclock used on Linux.
>>
>> During normal operation the ntpd service should not call the Windows
>> SetSystemTime() API since doing so causes a time offset offset to be
>> applied to the system time.
>>
>> As far as I know ntpd calls SetSystemTime() only when the Windows system
>> time needs to be stepped anyway, or when the ntpd service shuts down.
>>
>> Calling SetSystemTime() should also set the HW clock. If this doesn't
>> happen then the Windows bug mentioned above is probably inside that
>> Windows API call.
> 
> Again, I am using w32time, not ntpd.  The behaviour you call a bug is by
> design.  I looked up SetSystemTime on MSDN but could not find anything
> even suggesting SetSystemTime is supposed to update the hardware clock.
>   I actually could not find any official documentation on how to set the
> hardware clock from a userspace application on Windows NT

Re: [ntp:questions] Linux : ntp-dev-4.2.7p84 : Local clock not getting synced.

[Mike S]

At 08:44 AM 1/3/2011, Martin Burnicki wrote...

Mike S wrote:
> At 02:21 PM 1/2/2011, David Woolley wrote...
>>Arul Kumar Chellappan wrote:
>>>server  ::1
>>>fudge   ::1 stratum 10

The line above tries to fudge the localhost IP address, i.e. the 
loopback

interface, which indeed makes no sense.


True.

It's not quite clear what Arul was trying to achieve, but it looks like 
he was trying to define a local refclock using both IPv4 and IPv6 
terminology. It's easy to see how he may have come up with the ::1 
address, since NTP is using what look like loopback addresses. All IPv4 
127.0.0.0/8 addresses map to IPv6 ::1.


I don't know if ::127.127.1.0 (or ::7f7f:100) would work (I suppose it 
should, if NTP has full IPv6 support).


My response was to the original comment that "you can't fudge stratum 
on a server." "Server" in this context obviously referring to the 
"server..." configuration file section which was quoted.


NTP documentation doesn't seem to define whether a refclock is 
different than a server, or just a special case. The configuration file 
commands point to the latter.


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

Re: [ntp:questions] Linux : ntp-dev-4.2.7p84 : Local clock not getting synced.

[Martin Burnicki]

Mike S wrote:
> At 02:21 PM 1/2/2011, David Woolley wrote...
>>Arul Kumar Chellappan wrote:
>>>server  ::1
>>>fudge   ::1 stratum 10

The line above tries to fudge the localhost IP address, i.e. the loopback
interface, which indeed makes no sense.

>>These lines don't make sense, and not just because you can't fudge
>>stratum on a server.
> 
> How odd, since the official docs say you can :
> http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver1.html
> 
> "Fudge Factors...stratum number...Specifies the driver stratum, in
> decimal from 0 to 15, with default 3."
> 
> And the FAQ even gives an example:
> http://www.ntp.org/ntpfaq/NTP-s-refclk.htm#Q-LOCAL-CLOCK
> 
> "server 127.127.1.1 # LCL, local clock
> fudge  127.127.1.1 stratum 12   # increase stratum"

The line above fudges the stratum of the "local clock" which is something
different than the localhost IP address. See below.

> If not fudging stratum on a server, then where do you propose it's
> appropriate?

I think this is simply a misunderstanding which I've often seen with people
who are not (yet) very familiar with NTP.

::1 is the IPv6 address for localhost, i.e. the loopback network interface,
the IPv4 equivalent of which is 127.0.0.1. 

Configuring localhost (::1 or 127.0.0.1) using a "server" line in ntp.conf
makes no sense at all.

The IPv4 localhost IP 127.0.0.1 is sometimes confused with the special IP
addresses 127.127.x.y ntpd uses in general to configure hardware reference
clocks, and especially 127.127.1.0 which specifies the so-called local
clock.

The stratum of an NTP node visible on the network is always the stratum of
the selected time source (the system peer) plus 1.

If the system peer is a refclock you can fudge the stratum of the refclock,
and the resulting stratum of the NTP node is the stratum of the refclock
plus 1.

However, if the system peer is another NTP server you can not fudge the
stratum since NTP node's stratum would alsways be the stratum of system
peer, plus 1.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

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