Steve Kostecke wrote:
[]
> The NTP wiki (i.e. http://support.ntp.org/support) is the logical
> place to start such a list. If for no other reason than the fact that
> everyone is able to contribute their little bit of information.
>
> Of course this requires that someone or, better yet, a group of
On 2007-11-11, Wesley J. Landaker <[EMAIL PROTECTED]> wrote:
> Also, is there any place online that keeps an up-to-date list of
> [inexpensive OEM GPS units] ? The NTP wiki seemed like a likely spot,
> but there wasn't much info about actual hardware.
The NTP wiki (i.e. http://support.ntp.org/sup
Can anyone give me some suggestions on inexpensive (< $100) OEM GPS
units that support NMEA and 1PPS for use with NTP? Or any non-GPS
hardware clock sources that anyone can suggest?
I am already aware of the Garmin GPS 18 LVC, which seems the most
promising, but I'd like to know about other option
Adam Bolte wrote:
> Howdy all,
>
> I've got a problem that has been driving me nuts. Hopefully, somebody can
> give me a clue.
>
> I've been requested to configure an NTP server (192.168.2.1) for the local
> subnets that I'm responsible for. Unfortunately, firewall rules prevent me
> from accessi
Hi all,
The GPS receiver is from an Indian Company ACCORD. It has a custom
NMEA data with GPS time and is validity. It also sends standard NMEA
data including GPGGA, GPGLL with UTC time at 9600 baudrate. It also
generates 1 PPS pulse.
For more information visit http://www.accord-products.com/g
>> On Linux, a simpler way can be to look at /proc/interrupts - e.g.
>> (probably Linux-version- and possibly config-specific):
>>
>> $ (cat /proc/interrupts; sleep 10; cat /proc/interrupts) | \
>> awk '/timer/{prev=now; now=$2} END{printf "%dHz\n", int((now-prev)/10)}'
>
>This yields 41Hz on m
Maarten Wiltink wrote:
> "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> [...]
>
>>This suggests that a robust configuration should use a number and
>>variety of servers that cannot all be wiped out in the same disaster.
>
>
> Robustness is relative. If that
"Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
[...]
> This suggests that a robust configuration should use a number and
> variety of servers that cannot all be wiped out in the same disaster.
Robustness is relative. If that disaster is likely to wipe _you_ out,
t
In article <[EMAIL PROTECTED]> Jan Ceuleers
<[EMAIL PROTECTED]> writes:
>Jan Ceuleers wrote:
>> Per Hedeland wrote:
>>> On Linux, a simpler way can be to look at /proc/interrupts - e.g.
>>> (probably Linux-version- and possibly config-specific):
>>>
>>> $ (cat /proc/interrupts; sleep 10; cat /proc/
In article <[EMAIL PROTECTED]>,
Jan Ceuleers <[EMAIL PROTECTED]> wrote:
> In other words, this method doesn't seem to be entirely reliable,
> possibly as a side effect of frequency scaling.
I'm not familiar with frequency scaling, but I would suggest that if
the kernel interrupt rates are not co
Per Hedeland wrote:
> On Linux, a simpler way can be to look at /proc/interrupts - e.g.
> (probably Linux-version- and possibly config-specific):
>
> $ (cat /proc/interrupts; sleep 10; cat /proc/interrupts) | \
> awk '/timer/{prev=now; now=$2} END{printf "%dHz\n", int((now-prev)/10)}'
This yiel
Jan Ceuleers wrote:
> Per Hedeland wrote:
>> On Linux, a simpler way can be to look at /proc/interrupts - e.g.
>> (probably Linux-version- and possibly config-specific):
>>
>> $ (cat /proc/interrupts; sleep 10; cat /proc/interrupts) | \
>> awk '/timer/{prev=now; now=$2} END{printf "%dHz\n",
>> i
12 matches
Mail list logo
