Martin Burnicki martin.burni...@meinberg.de wrote:
This sounds good. I think we'd have to distinguish some basic cases a
few of which immediately come to my mind:
It looks good.
What is important for my box (but maybe only for mine...) is that there
is some method to feed OK/FAULT status to
William Unruh un...@invalid.ca wrote:
On 2014-07-31, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
On 2014-07-31, Martin Burnicki martin.burni...@meinberg.de wrote:
Unlike otherwise stated in this thread I don't think it's a good idea to
leave the 1 PPS signal alone
Harlan Stenn st...@ntp.org wrote:
Rob writes:
A reboot is a restart and on a restart you need an external source for
the seconds.
Why? The time is copied to the CMOS clock regularly, and one could
expect that during the short reboot the CMOS would not drift away so
much that the time
William Unruh un...@invalid.ca wrote:
Why? The time is copied to the CMOS clock regularly, and one could
expect that during the short reboot the CMOS would not drift away so
much that the time could not be synced to the PPS unambiguously.
Sure it could. And how does the system know what a
William Unruh un...@invalid.ca wrote:
I think you need to read up on the cmos clock. As I said, it reports
only the seconds, but is settable and readable to microseconds.
The CMOS clock is running off a 32768Hz crystal, so no way it can be
more accurately set than 30us.
Even it could be
William Unruh un...@invalid.ca wrote:
On 2014-07-30, Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2014-07-29 21:32, Paul wrote:
On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis
brian.ing...@systematicsw.ab.ca wrote:
These statuses show the same issue with local clock reach, implying
mike cook michael.c...@sfr.fr wrote:
Paradoxically , the LCL clock is fine when there are no refclocks. That is,
when you don't need or want it.
remote refid st t when poll reach delay offset jitter
I while ago I discussed the problem with an ntpd server that has to
be synchronized to a GPSDO that provides PPS but no absolute time.
After the usual discussion about you should not want that, a solution
was finally found using the following tricky workaround:
# PPS via ATOM
server 127.127.22.0
William Unruh un...@invalid.ca wrote:
On 2014-07-29, Rob nom...@example.com wrote:
I while ago I discussed the problem with an ntpd server that has to
be synchronized to a GPSDO that provides PPS but no absolute time.
After the usual discussion about you should not want that, a solution
mike cook michael.c...@sfr.fr wrote:
Rob,
Looks like a bug anterior to your version. I see the same issue with
version=ntpd 4.2.6p5@1.2349-o whether or not there is a preferred local
clock or not, and whether or not there are other active server associations.
One for Harlen if it has
A C agcarver+...@acarver.net wrote:
On 2014-07-29 11:33, William Unruh wrote:
On 2014-07-29, Rob nom...@example.com wrote:
The reasoning is that once the time is locked to PPS, it should remain
close enough for the local clock to be trusted as an absolute time
source (this system is rarely
Martin Burnicki martin.burni...@meinberg.de wrote:
Except what I've mentioned before I have had rare cases where the
Windows timekeeping was generally broken due to some drivers.
If I remember correctly then one case was a hard disk driver, and a some
latency checker program was used to
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2014-07-15 05:07, Nick wrote:
This machine dual boots Mint 17 x64 and Win 7 SP1 x64.
I have set the hardware clock to UTC.
Mint 17 and Win 7 run on local time.
I need reasonable time sync for WSJTX 1 second.
On Mint 17 ntp from the
vothanhhun...@gmail.com vothanhhun...@gmail.com wrote:
Hi David,
I have reinstalled ntp again and do the same as the guide above and I want to
know if I can configure the sync interval to test if the program is working
correctly. So I put the minpool parameter with value 9 and wait but
Hi there
Rob van der Putten wrote:
Cut
A lot of people however, by an embedded system, hook op a GPS receiver,
find that PPS doesn't work and then just give up.
Apparently GPSD supports PPS on CTS.
So if you already have got an embedded system and a GPS receiver and
your 232 cape supports
Harlan Stenn st...@ntp.org wrote:
Jason Rabel writes:
There are two obvious ways to go for an embedded client.
One way would be to use the sntp code as the base.
The other would be to either use the current NTP codebase and use the
configure options to disable all the refclocks and
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Jan Ceuleers jan.ceule...@computer.org wrote:
I recommend providing motivation for the undesired clients to stop using
the server, by the server sending a regular response indicating that it
is not synchronised or replying in some other way
.
It would be nice to have a comprehensive overview of embedded PPS
implementations.
Regards,
Rob
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Jan Ceuleers jan.ceule...@computer.org wrote:
I recommend providing motivation for the undesired clients to stop using
the server, by the server sending a regular response indicating
detha de...@foad.co.za wrote:
There are some differences between open SMTP relays and networks not
implementing BCP38. TCP versus UDP, and to quote Paul Vixie from
https://queue.acm.org/detail.cfm?id=2578510
] ... but the big reason why SAV isn't the default is: SAV benefits only
] other
Danny Mayer ma...@ntp.org wrote:
On 7/6/2014 2:42 AM, Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to, do not support
PPS is not available.
and the
Wandboard (both ARM platforms),
Same problem.
but have not had any success with them.
There are stories stories of people who have done it with Soekris
hardware (x86), but that's much more expensive.
AFAIK Soekris has a 'regular' serial port.
Regards,
Rob
Magnus Danielson mag...@rubidium.dyndns.org wrote:
On 07/07/2014 04:10 PM, Danny Mayer wrote:
The experience with blocking has actually being negative and we have
seen traffic actually INCREASE after it is blocked because the client,
not having received a response, tries more often. This
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to, do not support it.
In real life it has either no effect at all, or it even has a
Jan Ceuleers jan.ceule...@computer.org wrote:
I recommend providing motivation for the undesired clients to stop using
the server, by the server sending a regular response indicating that it
is not synchronised or replying in some other way that has no
timekeeping value to the offending
detha de...@foad.co.za wrote:
Maybe. For the moment I think it is sufficient if we provide a mechanism
by which offenders gets reported to *some* system. We *could* also provide
a method by which white/black-list can be dynamically set from an external
source, so enough hooks exists, but I do
Op maandag 23 juni 2014 15:54:13 UTC+2 schreef David Woolley:
On 23/06/14 13:12, Miroslav Lichvar wrote:
I think it all depends on the VM implementation and what clocksource
is used in the guest. If the guest is using tsc (i.e. its frequency is
independent of the host clock), it will need
William Unruh un...@invalid.ca wrote:
You canrun ntp on the machine that runs the virtual hardware, and tell
the virutal machines to get their time from the real system.
This is not possible on real virtual machine systems.
You can do it on your Linux box at home where you virtualize some
William Unruh un...@invalid.ca wrote:
On 2014-06-24, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
You canrun ntp on the machine that runs the virtual hardware, and tell
the virutal machines to get their time from the real system.
This is not possible on real virtual
Paul tik-...@bodosom.net wrote:
On Tue, Jun 24, 2014 at 9:34 AM, William Unruh un...@invalid.ca wrote:
On 2014-06-24, Rob nom...@example.com wrote:
It is not possible to run programs on the bare hardware.
Since the whole VM is a set of programs running on the bare hardware,
this is clearly
Jochen Bern jochen.b...@linworks.de wrote:
While I may have started from the same setting, I *did* try to put
myself into the shoes of astronomers and people operating satellite
systems (which, ironically, includes the popular stratum 0 of GPS).
Note that while those people would like to keep
Jochen Bern jochen.b...@linworks.de wrote:
While I may have started from the same setting, I *did* try to put
myself into the shoes of astronomers and people operating satellite
systems (which, ironically, includes the popular stratum 0 of GPS).
Note that the GPS system does not use UTC.
GPS
Hi,
Why are NTP Servers running on virtualized hardware (vmware) unsuitable to
serve time to clients?
I've read this statement several times but can't find a good motivation. I've
searched the official documentation, FAQ, the NTP support wiki, this news
group, google search.
I found this in
David Woolley david@ex.djwhome.demon.invalid wrote:
On 23/06/14 13:12, Miroslav Lichvar wrote:
I think it all depends on the VM implementation and what clocksource
is used in the guest. If the guest is using tsc (i.e. its frequency is
independent of the host clock), it will need to run its own
Paul tik-...@bodosom.net wrote:
On Sun, Jun 15, 2014 at 12:11 PM, Rob nom...@example.com wrote:
Did you put prefer on the PPS and not on another source?
That was the complete output of ntpq. The local clock is marked prefer; it
can reliably number the seconds. This is just a demonstration
jthul...@gmail.com jthul...@gmail.com wrote:
Hello,
I'm looking for a way to speed up the ntp convergence of a system which would
be restarted after several days being off. Does the use of PPS improve this
convergence time ?
This is local configuration, with one LAN and one NTP server, with
jthul...@gmail.com jthul...@gmail.com wrote:
Hi,
the PPS signal comes from one GPS clock.
At the cold start the drift could be several seconds, so we plan to perform a
ntpdate before launching the ntp client.
The sync accuracy we want to achieve for this particular system is below 3ms
jthul...@gmail.com jthul...@gmail.com wrote:
PPS makes the final convergence a lot faster, because it is usually being
run at a high sample rate (once every 16 seconds).
Watch your 'minpoll' and 'maxpoll' values.
Does it mean that if I set the minpoll and maxpoll values to 4, I will have
Jochen Bern jochen.b...@linworks.de wrote:
On -10.01.-28163 20:59, jthul...@gmail.com wrote:
I'm looking for a way to speed up the ntp convergence of a system
which would be restarted after several days being off.
Since you seem concerned about additional frequency offset while the
system
Martin Burnicki martin.burni...@meinberg.de wrote:
Hi,
sorry for stepping in so late, but I've been on vacation with limited
internet access.
garrettbrian1...@gmail.com schrieb:
I have been trying to install the Meinberg NTP build for Windows and
the install is going through, yet NTP
Paul tik-...@bodosom.net wrote:
On Mon, Jun 16, 2014 at 3:26 AM, Rob nom...@example.com wrote:
Note that we do not have a local clock, only PPS.
I'm starting to wonder if you simply refuse to read the documentation or
you're just trolling to cause trouble.
To avoid further confusion, I
A C agcarver+...@acarver.net wrote:
On 2014-06-14 12:57, Rob wrote:
A C agcarver+...@acarver.net wrote:
I actually disliked having to use a prefer peer for PPS as well. So I
modified the source code to remove that requirement. As long as there's
a source that is acceptable to the selection
Brian Inglis brian.ing...@shaw.ca wrote:
On 2014-06-14 12:03, Rob wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
I see no problem, really no problem, in this configuration and I wonder
why the software makers do see a problem in it and want me to make a
configuration decision
Paul tik-...@bodosom.net wrote:
On Sat, Jun 14, 2014 at 2:03 PM, Rob nom...@example.com wrote:
Everyone seems to think that GPS equates NMEA. Wrong.
...
It apparently assumes anyone who has a PPS signal also has a
device that provides date and time information, which is wrong
Paul tik-...@bodosom.net wrote:
On Sat, Jun 14, 2014 at 12:42 PM, Brian Inglis
brian.ing...@systematicsw.ab.ca wrote:
There may be no problem with time only messages: the NMEA driver page,
shows support of GLL and GGA which provide only time.
Other drivers may allow similarly limited
brian.cun...@gmail.com brian.cun...@gmail.com wrote:
Hi All,
Is there a suggested way to rate-limit queries by broken clients?
There isn't any. In fact, many methods to do that are likely to make
the problem worse.
For example, people suggest to limit the number of queries answered
or even
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2014-06-13 10:17, Rob wrote:
I installed the ntp-dev package for Debian as recommended here to get
better resolution for the offset and jitter values.
The service was started with a local PPS clock (ATOM) and a couple of
low-stratum
mike cook michael.c...@sfr.fr wrote:
Le 14 juin 2014 à 10:27, Rob a écrit :
The PPS source is a GPSDO which provides 1PPS, 10 MHz and status on
a serial port, but no date information (it does provide time, but that
is not very useful without date).
So I choose not to use the time info
David Lord sn...@lordynet.org wrote:
NetBSD seems to require a reboot to get PPS working. Once up
it stays synced until GPS signal is lost which happens here
several times a year.
/etc/ntp.conf
# Sure GPS
server 127.127.20.2 mode 18 prefer
fudge 127.127.20.2 stratum 7 time2 0.407 flag1 0
Paul tik-...@bodosom.net wrote:
On Sat, Jun 14, 2014 at 8:15 AM, Rob nom...@example.com wrote:
It is a strange feature.
You must have some method of numbering the PPS delimited seconds.
Why can't 5 agreeing network servers be that method?
I am always looking for solutions that are stable
mike cook michael.c...@sfr.fr wrote:
Le 14 juin 2014 à 16:56, Rob a écrit :
By the way, you can have more than one server marked prefer.
So the solution is to mark everything but the PPS server marked prefer?
What is the value of that?
The documentation, although a bit long in the tooth
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
I see no problem, really no problem, in this configuration and I wonder
why the software makers do see a problem in it and want me to make a
configuration decision that introduces yet more problems.
There may be no problem with time only
A C agcarver+...@acarver.net wrote:
I actually disliked having to use a prefer peer for PPS as well. So I
modified the source code to remove that requirement. As long as there's
a source that is acceptable to the selection algorithm (and marked with
the *) then PPS turns on. No perfer peer
Steve Kostecke st...@kostecke.net wrote:
On 2014-06-12, Rob nom...@example.com wrote:
One problem: confusion of the service name. The service is called
ntp-dev instead of ntp, it creates a file /etc/default/ntp-dev during
installation, but that file is never read. Instead, it reads the file
I installed the ntp-dev package for Debian as recommended here to get
better resolution for the offset and jitter values.
The service was started with a local PPS clock (ATOM) and a couple of
low-stratum external servers. The PPS was not available when ntpd
started, but was connected about 12
Paul tik-...@bodosom.net wrote:
On Fri, Jun 13, 2014 at 12:17 PM, Rob nom...@example.com wrote:
Why is it so picky?
Why is your jitter so high?
High? 0.001 is 1us. That is not high, isn't it?
___
questions mailing list
questions
Rob nom...@example.com wrote:
Rob nom...@example.com wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2014-06-10 03:38, Rob wrote:
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 10/06/2014 08:58, Rob wrote:
[]
Well, I now see that the readvar packet returns
Steve Kostecke st...@kostecke.net wrote:
On 2014-06-10, Rob nom...@example.com wrote:
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 10/06/2014 17:03, Rob wrote:
[]
Ok that looks good.
What is the impact of The ntp-dev* packages do not utilize any of the
Debian distribution
Rob nom...@example.com wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2014-06-10 03:38, Rob wrote:
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 10/06/2014 08:58, Rob wrote:
[]
Well, I now see that the readvar packet returns the data in the same
format
Rob nom...@example.com wrote:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
I am trying to monitor NTP servers with nagios.
I use the standard plugin check_ntp_peer.
It appears that it is only checking the offset and jitter of the
currently selected peer. When I run check_ntp_peer
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 10/06/2014 08:58, Rob wrote:
[]
Well, I now see that the readvar packet returns the data in the same
format (as ASCII string), not as a fixed point value. And I realize
that ntpd operates in units of a microsecond anyway
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2014-06-10 03:38, Rob wrote:
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 10/06/2014 08:58, Rob wrote:
[]
Well, I now see that the readvar packet returns the data in the same
format (as ASCII string), not as a fixed point
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
development version.
Is there a Debian source package available for that?
http://packages.ntp.org/debian/
Ok that looks good.
What is the impact of The ntp-dev* packages do not utilize
I am trying to monitor NTP servers with nagios.
I use the standard plugin check_ntp_peer.
It appears that it is only checking the offset and jitter of the
currently selected peer. When I run check_ntp_peer with some threshold
it returns the same values as present on the ntpq output line with *
Harlan Stenn st...@ntp.org wrote:
Rob writes:
I am trying to monitor NTP servers with nagios.
I use the standard plugin check_ntp_peer.
It appears that it is only checking the offset and jitter of the
currently selected peer. When I run check_ntp_peer with some threshold
it returns
mike cook michael.c...@sfr.fr wrote:
If I keep pinging different pools,
I can find another NTP server which replies.
Seems strange, that would imply that the server 130.88.200.4
(or their ISP) is blocking your client?
I regularly get inaccessible servers returned by pool
Antonio Marcheselli pu...@me.la wrote:
You can try traceroute -U -p 123 ip.ad.dr.es to see where it is being
blocked, and if it is nearby to your ISP complain to your ISP about it.
Hi,
Here is a standard traceroute
xxx-2:~# traceroute 130.88.200.4
traceroute to 130.88.200.4
David Woolley david@ex.djwhome.demon.invalid wrote:
On 30/04/14 10:22, Maximilian Brehm wrote:
On 2014-04-30, William Unruh wrote:
On 2014-04-30, Maximilian
Brehm wrote:Hey, for my application (external to ntpd)
I would like to extract the reference times of the peers ntpd
be
Maximilian Brehm maximilian.br...@tu-ilmenau.de wrote:
This is related to another questions by me a few weeks ago. I wrote a
reference clock driver that uses a clock that only provides timestamps
relative to its starting point. It works well when setting its offset to
the system clock via
Martin Burnicki martin.burni...@meinberg.de wrote:
David Taylor schrieb:
On 29/04/2014 15:35, Rob wrote:
[]
But with a modular approach you would not need to rebuild to add
a standard refclock, that would just be the installation of another
package containing the precompiled refclock
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 26/04/2014 05:05, Harlan Stenn wrote:
William Unruh writes:
[]
More recent ntpd combine server and client in one program.
Not sure when that was.
It's been the case for at least 20 years' time.
This is something that may be
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
For Rob, I would suggest that each TX have a GPS/PPS reference with sky
view, and that each PC was identical (e.g. all Raspberry Pi cards), and
then getting them synced to with 12 microseconds should be easy. I
Of course
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 29/04/2014 14:40, Paul wrote:
[]
Sure or you just recognize that only one system in a million needs refclock
support and assume anyone running a refclock needs to be smart enough to
build ntpd with the requisite driver.
However,
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
Unfortunately that is not the same as performing some task like outputting
audio at an accuracy of 12us, but that is the next challenge :-)
Indeed, and you will likely want to look at very matched systems (PCs
and transmitters - the
William Unruh un...@invalid.ca wrote:
The problem is not the electronics, it is the response of the system to
the interrupt. That interrupt processing time is in the usec range.
This does not really matter when it is constant.
And my experience is that the jitter on the PPS refclock is usually
William Unruh un...@invalid.ca wrote:
On 2014-04-29, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
The problem is not the electronics, it is the response of the system to
the interrupt. That interrupt processing time is in the usec range.
This does not really matter
William Unruh un...@invalid.ca wrote:
On 2014-04-27, Rob nom...@example.com wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
The listeners should enjoy a smooth reception while driving around.
So of course there should be no time lag between the modulation signals
David Woolley david@ex.djwhome.demon.invalid wrote:
On 27/04/14 19:20, j...@specsol.spam.sux.com wrote:
The goal is not to have 12us difference in arrival time, but to be
within 12us for transmission time.
But it is the difference in arrival time that will affect the quality of
the audio
William Unruh un...@invalid.ca wrote:
All in all it is funny to read all the that cannot be done-like comments
by several persons on a ntp newsgroup while systems like this have been in
use since the seventies, and in fact have already been build by amateurs
and are in operation today. So I
mike cook michael.c...@sfr.fr wrote:
If you look at those, they are included because the API does not ( or
didn't ) exist in the OSs whereas it does for Linux so responsibility should
reside there.
IIRC, the OP was a heads up which IS useful, but complaints should go to
the
Paul tik-...@bodosom.net wrote:
On Sat, Apr 26, 2014 at 6:30 PM, Rob nom...@example.com wrote:
Can't they add just one simple package to that?
Well pps-tools is clearly special. E.g. it's no longer advertised for 12.04
Well, it is for Ubuntu 14.04 LTS
Paul tik-...@bodosom.net wrote:
I don't know what terribly accurate might be to you but in the real world
sufficient accuracy depends on the circumstance.
Someone should conduct an experiment.
I am in a group that works on a project that needs synchronous audio
on geographically distributed
mike cook michael.c...@sfr.fr wrote:
Le 27 avr. 2014 à 12:28, Rob a écrit :
mike cook michael.c...@sfr.fr wrote:
If you look at those, they are included because the API does not ( or
didn't ) exist in the OSs whereas it does for Linux so responsibility
should reside there.
IIRC, the OP
Jochen Bern jochen.b...@linworks.de wrote:
On -10.01.-28163 20:59, Rob wrote:
Apparently there is unresolved discussion whether a .h describing a
PPS API belongs in the set of kernel include files or in a separate
package.
There is? Can't say I've ever dealt with PPS, but *if* this .h
William Unruh un...@invalid.ca wrote:
But those modules give timing to one a few (5-10) usec. because of
interrupt handling issues. Your shm solution would seem to me to be more
than adequate for any timing requirements if they can be solved with an
interrupt driven pps.
Well, the kernel PPS
Jochen Bern jochen.b...@linworks.de wrote:
On -10.01.-28163 20:59, Rob wrote:
What I mean is that for building packages they need not only building
tools but also -dev packages for many libraries that are going to be
used by the packages being built. There is a long list of packages that
one
William Unruh un...@invalid.ca wrote:
The next problem is to send output to a soundcard and making it send
a sample at the sampling clock edge closest to a specified time.
(48kHz sampling rate corresponds to a sampling clock period of 20.8us)
It will certainly depend on the sound card. AFAIK
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
The listeners should enjoy a smooth reception while driving around.
So of course there should be no time lag between the modulation signals
of the different transmitters. Experts in the field tell us we should
be within 12us.
Unless
David Woolley david@ex.djwhome.demon.invalid wrote:
On 27/04/14 17:28, Rob wrote:
We are setting up a co-channel diversity network. That means multiple
FM transmitters that are transmitting the same signal on the same
frequency on different sites, where the receive areas partly overlap
William Unruh un...@invalid.ca wrote:
On 2014-04-27, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
But those modules give timing to one a few (5-10) usec. because of
interrupt handling issues. Your shm solution would seem to me to be more
than adequate for any timing
Jochen Bern jochen.b...@linworks.de wrote:
[Resend to list, rather than non-working(?) sender e-mail address]
On -10.01.-28163 20:59, Rob wrote:
We are setting up a co-channel diversity network. That means multiple
FM transmitters that are transmitting the same signal on the same
frequency
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
Your transmitters will have to be contained within a circle of 3.6km,
reduced by the timing errors in the modulation at 0.3km/microsecond.
This turns out to be not the case. Networks like this have been operating
for decades, only
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
Rob nom...@example.com wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
The listeners should enjoy a smooth reception while driving around.
So of course there should be no time lag between the modulation signals
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
Rob nom...@example.com wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
Rob nom...@example.com wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
The listeners should enjoy a smooth reception while
Harlan Stenn st...@ntp.org wrote:
William Unruh writes:
On 2014-04-25, Paul tik-...@bodosom.net wrote:
On Fri, Apr 25, 2014 at 4:36 PM, William Unruh un...@invalid.ca wrote:
Why shoul dit ship with no refclocks? ... DO you have the same opinion for
serial
port or parallel ports, or
On a Linux system we ran into the problem that port 123 has been blocked
for incoming traffic (probably as a general countermeasure against
abuse of badly configured servers, this server was configured correctly).
As it is not possible to change the source port number in ntpd, I
translated the
Paul tik-...@bodosom.net wrote:
On Sat, Apr 26, 2014 at 3:33 AM, Rob nom...@example.com wrote:
The point is that the program is compiled
with a fixed set of refclocks that is unneccessarily limited because
the environment it was compiled in was not complete.
Are you saying that the ntpd
Jason Rabel ja...@extremeoverclocking.com wrote:
I am saying that the ntpd that ships with Ubuntu 14.04 is limited because
it was built on a system where timepps.h was not present, and thus the
ATOM and JUPITER (and a couple other) refclocks were not included in the
binary. Even though PPS
William Unruh un...@invalid.ca wrote:
On 2014-04-26, Jason Rabel ja...@extremeoverclocking.com wrote:
I am saying that the ntpd that ships with Ubuntu 14.04 is limited because
it was built on a system where timepps.h was not present, and thus the
ATOM and JUPITER (and a couple other) refclocks
Jan Ceuleers jan.ceule...@computer.org wrote:
On 04/24/2014 09:31 PM, Rob wrote:
all that is required to get PPS working is to fetch the source
package of ntpd for the distribution and recompile it while that
single file has been added. e.g. on Ubuntu that file is present
in the package pps
201 - 300 of 858 matches
Mail list logo
