j...@specsol.spam.sux.com wrote:
Richard B. Gilbert wrote:
Didn't I just see an announcement that GPS was going to be jammed in
order to test something or other?
Yeah, it happens quite often on a scheduled basis in limited areas.
Hmm, it should not be all that difficult to set up a limit
Bruce Lilly wrote:
On Fri, 18 Mar 2011 03:16:38 +, Dave Hart wrote:
On Fri, Mar 18, 2011 at 01:44 UTC, Bruce Lilly
wrote:
4. Assuming specific sizes for an integer is a really bad idea... "(64
bits making up the) clockTimeStamp* and receiveTimeStamp* fields"
Actually nailing down the
Bruce Lilly wrote:
> On Fri, 18 Mar 2011 03:16:38 +, Dave Hart wrote:
>
>> On Fri, Mar 18, 2011 at 01:44 UTC, Bruce Lilly
>> wrote:
>>> 4. Assuming specific sizes for an integer is a really bad idea... "(64
>>> bits making up the) clockTimeStamp* and receiveTimeStamp* fields"
>>
>> Actually
Rob wrote:
Bruce Lilly wrote:
Endianness (and more generally byte order) are of concern for precisely
the same reasons.
This is not relevant in the case of shared memory, as long as the
memory is not shared between processors of different endianess.
For the scope of this driver, we can safe
Bruce & Co.,
You may not be aware that all Spectracom devices are supported with one
driver, all TrueTime devices are supported with one driver, all
telephone modem services are supported with one driver, all Austron
devices are supported with one driver, all Heath devices are supported
with
Uwe Klein wrote:
> j...@specsol.spam.sux.com wrote:
>> Richard B. Gilbert wrote:
>
>>>Didn't I just see an announcement that GPS was going to be jammed in
>>>order to test something or other?
>>
>>
>> Yeah, it happens quite often on a scheduled basis in limited areas.
>>
> Hmm, it should not
On 03/26/2011 08:46 AM, Dave Hart wrote:
You probably want iburst on each of those server lines, to sync the
clock in under 15 seconds instead of a few minutes.
I thought that was frowned upon, to use iburst with public servers?
(I do use iburst, from all the other machines to the internal NT
On 03/26/2011 03:36 AM, Rob wrote:
Florin Andrei wrote:
restrict 0.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 1.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 2.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 3.us.pool.ntp
David L. Mills wrote:
> Bruce & Co.,
>
> You may not be aware that all Spectracom devices are supported with one
> driver, all TrueTime devices are supported with one driver, all
> telephone modem services are supported with one driver, all Austron
> devices are supported with one driver, all H
j...@specsol.spam.sux.com wrote:
At that point they start slowly changing the time to something else.
Meanwhile, inside the building where NTP was set up by someone with a clue
if you go by the questions placed here on occasion that assumption is not a
given ;-)
that bothered to read the doc
Let's assume I upgrade to a newer version that accepts the "source"
keyword. Then how about this config?
Is there are risk of too many internal servers picking other internal
servers to sync their time - and not enough servers using external
sources? Should I skew the selection using "prefer"
Uwe Klein wrote:
> j...@specsol.spam.sux.com wrote:
>> At that point they start slowly changing the time to something else.
>>
>> Meanwhile, inside the building where NTP was set up by someone with a clue
> if you go by the questions placed here on occasion that assumption is not a
> given ;-)
>
On Mon, Mar 28, 2011 at 8:56 AM, wrote:
>
> OK, so the bad guy sets up the stuff for a GPS spoofer and parks it next
> to the targeted building where high dollar value stuff goes on in hopes
> of tweeking their system clocks and stealing a fortune.
The best application of GPS signal spoofing wo
On Mon, Mar 28, 2011 at 6:47 PM, Florin Andrei wrote:
>
> Let's assume I upgrade to a newer version that accepts the
> "source" keyword. Then how about this config?
>
> Is there are risk of too many internal servers picking other
> internal servers to sync their time - and not enough servers
> usi
Florin Andrei wrote:
On 03/26/2011 08:46 AM, Dave Hart wrote:
You probably want iburst on each of those server lines, to sync the
clock in under 15 seconds instead of a few minutes.
I thought that was frowned upon, to use iburst with public servers?
(I do use iburst, from all the other machi
On 2011-03-28, Florin Andrei wrote:
> On 03/26/2011 08:46 AM, Dave Hart wrote:
>
>> You probably want iburst on each of those server lines, to sync the
>> clock in under 15 seconds instead of a few minutes.
>
> I thought that was frowned upon, to use iburst with public servers?
>
> (I do use ibur
On 2011-03-25, Florin Andrei wrote:
> Two groups of machines in two datacenters, VPN line in between.
A VPN will introduce jitter into any associations between your two data
centers. An unencrypted UDP connection would be better.
> Two NTP servers in each datacenter, sync'ing to public servers.
On 3/28/2011 1:16 PM, Florin Andrei wrote:
On 03/26/2011 08:46 AM, Dave Hart wrote:
You probably want iburst on each of those server lines, to sync the
clock in under 15 seconds instead of a few minutes.
I thought that was frowned upon, to use iburst with public servers?
(I do use iburst, fr
Florin Andrei wrote:
On 03/26/2011 08:46 AM, Dave Hart wrote:
You probably want iburst on each of those server lines, to sync the
clock in under 15 seconds instead of a few minutes.
I thought that was frowned upon, to use iburst with public servers?
(I do use iburst, from all the other machi
Chris Albertson wrote:
> On Mon, Mar 28, 2011 at 8:56 AM, wrote:
>
>>
>> OK, so the bad guy sets up the stuff for a GPS spoofer and parks it next
>> to the targeted building where high dollar value stuff goes on in hopes
>> of tweeking their system clocks and stealing a fortune.
>
> The best a
http://support.ntp.org/bin/view/Support/ConfiguringAutokey
For ntpd 4.2.4 and earlier, Steve Kostecke patiently worked out
step-by-step instructions, and refined them over time heping people to
use them, as seen on the page referenced above.
For 4.2.6 ntp-keygen and autokey got an overhaul which
Dave,
When all else fails, read the documentation. There were good reasons to
change the configuration in minor ways.
1. There was a huge vulnerability if the identity file was specified by
the server, but the correct file was not specified by the client. The
scheme devolved to TC with no wa
On Tue, Mar 29, 2011 at 12:53 AM, David L. Mills wrote:
> I sent you a message requesting to test this before deployment.
>
>
I was referring to docs galore as I thrashed about earlier. I don't doubt
each of your changes was an improvement, but each one also made Steve's
4.2.4 step-by-step guide
23 matches
Mail list logo
