Fwd: Re: [LinuxPPS] still the strangeness

[Bernhard Schiffner]

----------  Weitergeleitete Nachricht  ----------

Subject: Re: [LinuxPPS] still the strangeness
Date: Mittwoch, 20. Dezember 2006 09:09
From: Bernhard Schiffner <bernhard at schiffner-limbach.de>
To: Udo van den Heuvel <udovdh at xs4all.nl>

Am Dienstag, 19. Dezember 2006 19:30 schrieb Udo van den Heuvel:

First of all: I think others have interest in things happen here. Can you
forward this mail to the ml please? (I'll forward this too.)

...
OK so far.
(ntpd with 2.6.19.1 takes long time to stabilize.)

> > 5.) give me the ping-time to this peer for information please.
>
> [root at epia etc]# ping ntp1.ptb.de
> PING ptbtime1.ptb.de (192.53.103.108) 56(84) bytes of data.
> 64 bytes from ptbtime1.ptb.de (192.53.103.108): icmp_seq=1 ttl=50
> time=30.6 ms

This means the maximum error (not jitter) ist 30.6 ms / 2 = 15 ms.
See ntp documentation for this.
(1ms is roughly 300 km in vacuum, copper and glass less, delay in routers
too.)

> > 6.) report please what's on with your other peers with ntpdate -b -q
> > x.y.z.a && ntpq -c pe
>
> [root at epia etc]# ntpdate -b -q ntp.xs4all.nl && ntpq -c pe
> server 194.109.22.18, stratum 2, offset -0.000546, delay 0.03229
> 19 Dec 19:28:21 ntpdate[7479]: step time server 194.109.22.18 offset
> -0.000546 sec

0,5 ms offset over your network is good and indicates that your ntpd is

adjusted to an other reliable source:
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ===========================================================================
>=== *LOCAL(0)        .LOCL.          10 l    8   64  377    0.000    0.000
> 0.001
> xGPS_NMEA(0)     .GPS.            8 l    7   16  377    0.000  -173.62
>  1.508
> xptbtime1.ptb.de .PTB.            1 u  795 1024  377   29.703   -1.195
>  1.337

Here we are: 1,2 ms in ntpd operation is also good shape. (2.6.19!)
With this value you confirmed, that ntp.xs4all.nl does something reliable.

Your NMEA receiver needs fudge offset 172.000 until it fits to the others.
This is ok for pure NMEA-messages.

Why:
PPS  ------|--------|--
ttyS* ---------||||-----

The datagram regarding the [next|previous] full second is sent bewteen the
full-second-slope. Now it depends of your 8250-setting when interrupt occurs.
Common:
a) buffer full (12/16 bytes)
b) 3 charakter-times after last received charakter if buffer is not full.
These times are registered and depend cleary from other things (firmware,
bitrate)

> > 8.) cat /proc/pps/0*/* to see the timing of assert and clear events
>
> [root at epia etc]# cat /proc/pps/0*/*
> 0.000000000 #0
> 0.000000000 #0
> 0.000000000 #0
> 0.000000000 #0
> 0.000000000 #0
> 0.000000000 #0
> 0.000000000 #0
> 0.000000000 #0
>
> No changes there. No output.

Very bad. Seems something in Hardware.
First (not meaningfull):
Do you really have 8 serial devices? (konfig-option kernel)

Second:
You must ensure, that the DCD-pin is working and read out by pps-software.
This becomes hardware resarch:

With a meter:
measure on the receivers side of the cable between pin 5 (ground) and pin 1
(DCD), while the receiver is running. If everything works you must notice
a "flicker" every second.
Check: pin 5-2 (Received Data): more flicker, if your receiver sends
 datagrams This confirms that your receiver sends a pps-signal.

With a female SUB-D:
connect
3+1 (TxD DCD)
7+8 (RTS CTS)
4+6 (DTR DSR)
put this into your computer.
Start minicom, type in some charakter. If you cat /proc/pps/0*/* you should
see "crazy" values, because every slope of every bit of every charakter you
send should be recorded there.
With this you see that DCD is workable. May be on EPIA boards there is no DCD
connected internal.


Bernhard

-------------------------------------------------------