On Thursday, February 28, 2013 3:53:22 PM UTC+10, unruh wrote:
> On 2013-02-28, ramadog wrote:
> > Up to that 8us point it is the same behaviour I have been seeing since 2008.
> > I did this graph April 11 2008 http://users.on.net/~boddingt/irq-pps.png
> > Blue line is a time stamp taken at the beg
On Thursday, February 28, 2013 5:37:30 PM UTC+10, David Taylor wrote:
> What processor and what speed is this being run on, please? I'm trying
A dell gx1 with a p3-600 coppermine. Have another computer with a celeron 1300
and used to get similar results with it. Everything else I have that is mo
On 28/02/2013 08:05, rama...@gmail.com wrote:
On Thursday, February 28, 2013 5:37:30 PM UTC+10, David Taylor wrote:
What processor and what speed is this being run on, please? I'm trying
A dell gx1 with a p3-600 coppermine. Have another computer with a celeron 1300
and used to get similar res
Has anybody *two* GPIO PPS devices on different GPIO
pins on their Raspberry Pi? Would a setup like this
enable the ntpd to check the devices against eachother
(or probably more likely give an idea of interrupt
handling capabilities)?
Or does more than one PPS device confuse ntpd?
/ralph
__
The main problem of this config is that you won't be able to connect
specific PPS with specific GPS.
Some GPS devices output PPS'es even if they don't have position fix.
Sometime it can be tuned but not always.
Imagine what will happen if such device will produce PPS'es without
position fix and an
On 2013-02-28, Edward T. Mischanko wrote:
> When ntpd loads via rc.d at system start-up it just locks-up.
> It doesn't finish loading what is in the rc.conf or give me a login prompt.
> I have to control c out of it to regain control of the computer, but that
> terminates ntpd. Any help would be
On 2013-02-28, Ralph Aichinger wrote:
> Has anybody *two* GPIO PPS devices on different GPIO
> pins on their Raspberry Pi? Would a setup like this
> enable the ntpd to check the devices against eachother
> (or probably more likely give an idea of interrupt
> handling capabilities)?
Yes, it is fa
On 2013-02-28, rama...@gmail.com wrote:
> On Thursday, February 28, 2013 3:53:22 PM UTC+10, unruh wrote:
>> On 2013-02-28, ramadog wrote:
>> > Up to that 8us point it is the same behaviour I have been seeing since
>> > 2008.
>> > I did this graph April 11 2008 http://users.on.net/~boddingt/irq-pp
I split the gps+pps (20) into gps and pps (20 & 22) and that solved the problem.
I do wish I knew what happened.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
"Edward T. Mischanko" writes:
> The command I am running is /usr/local/sbin/ntpd -gnN
> I should correct my post also. The session locks-up;
> I can start a telnet session once I get inetd loaded.
> The console session stays locked-up though.
> Is this a FreeBSD 8.3 problem or an NTP problem?
Nei
"Edward T. Mischanko" writes:
> Thanks, Harlan. Taking the -n flag off solved the problem.
> I don't know what the -n flag is used for then.
% ntpd --help | grep -- -n
-n no nofork Do not fork
%
H
___
questions mailing list
questions@lists.n
Once upon a time, Ralph Aichinger said:
>Has anybody *two* GPIO PPS devices on different GPIO
>pins on their Raspberry Pi? Would a setup like this
>enable the ntpd to check the devices against eachother
>(or probably more likely give an idea of interrupt
>handling capabilities)?
Remember: a man
On 2013-02-28, Chris Adams wrote:
> Once upon a time, Ralph Aichinger said:
>>Has anybody *two* GPIO PPS devices on different GPIO
>>pins on their Raspberry Pi? Would a setup like this
>>enable the ntpd to check the devices against eachother
>>(or probably more likely give an idea of interrupt
On 2/28/2013 6:03 PM, Chris Adams wrote:
Once upon a time, Ralph Aichinger said:
Has anybody *two* GPIO PPS devices on different GPIO
pins on their Raspberry Pi? Would a setup like this
enable the ntpd to check the devices against eachother
(or probably more likely give an idea of interrupt
ha
On Thursday, February 28, 2013 6:44:38 PM UTC+10, David Taylor wrote:
> By the way: do check your motherboards - many still have the 10-pin
> serial port header even if there's no COM port on the back. This was
> still true on a PC bought a few weeks ago (admittedly, using a Gigabyte
Good call
On 01/03/2013 03:45, rama...@gmail.com wrote:
[]
Good call. The manual I have for 1 of my Gigabyte mother boards is useless.
Managed to find the relevant information. Now have a 3.16GHz core2duo fed with
a pps. A getnstimeofday() early in the irq code and a 2nd just before the
normal pps time sta
16 matches
Mail list logo
