Empathy List Archives

CH

Christopher Hoover

Fri, Feb 17, 2017 3:38 AM

On Thu, Feb 16, 2017 at 10:42 AM, Christopher Hoover ch@murgatroid.com
wrote:

Ntp has support to pick up hardware packet timestamps from the Linux
kernel. I wrote the patch; it was merged years ago.

I'm wrong about this.

The patch I wrote added support for SO_TIMESTAMPNS (see [1]). With
SO_TIMESTAMPNS, the kernel puts the timestamp on the packet just after the
driver hands it to the receive path.

There's a newer interface, SO_TIMESTAMPING, for access to NIC hardware
timestamps. There's no support it on the ntp head for this AFAICT.
The necessary patch looks straightforward, but I don't think I have the
hardware to test it.

-- Christopher
73 de AI6KG.

[1] https://www.kernel.org/doc/Documentation/networking/timestamping.txt

-c73 de AI6KG

On Thu, Feb 16, 2017 at 9:59 AM, Denny Page denny@cococafe.com wrote:

If your Ethernet chipset (mac or phy) has timestamping capabilities, you
can use Chrony which has hardware timestamp support. This greatly improves
accuracy, and generally eliminates the CPU loading issue.

Denny

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/m
ailman/listinfo/time-nuts
and follow the instructions there.

On Thu, Feb 16, 2017 at 10:42 AM, Christopher Hoover <ch@murgatroid.com> wrote: > Ntp has support to pick up hardware packet timestamps from the Linux > kernel. I wrote the patch; it was merged years ago. > > I'm wrong about this. The patch I wrote added support for SO_TIMESTAMPNS (see [1]). With SO_TIMESTAMPNS, the kernel puts the timestamp on the packet just after the driver hands it to the receive path. There's a newer interface, SO_TIMESTAMPING, for access to NIC hardware timestamps. There's no support it on the ntp head for this AFAICT. The necessary patch looks straightforward, but I don't think I have the hardware to test it. -- Christopher 73 de AI6KG. [1] https://www.kernel.org/doc/Documentation/networking/timestamping.txt -c73 de AI6KG > > > > On Thu, Feb 16, 2017 at 9:59 AM, Denny Page <denny@cococafe.com> wrote: > >> If your Ethernet chipset (mac or phy) has timestamping capabilities, you >> can use Chrony which has hardware timestamp support. This greatly improves >> accuracy, and generally eliminates the CPU loading issue. >> >> Denny >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/m >> ailman/listinfo/time-nuts >> and follow the instructions there. >> > >

D

David

Fri, Feb 17, 2017 8:56 AM

On Tue, 14 Feb 2017 10:31:30 -0500, you wrote:

On 14/02/2017 7:26 AM, Bob Camp wrote:

A direct port might be a +/- 100 ns sort of thing most of the time and a +/-10 us
thing every so often under some OSs. Most desktop operating systems are not
designed to prioritize random pin interrupts. A dirt cheap MCU coded with a few
(hundred) lines of assembly code may be a better option than a typical desktop.
Complicating this further is the degree to which some OSs can be directly or
indirectly optimized. Install this package and it all goes nuts. Install that package
and not much happens .

Bob

Hence, wouldn't Best Practice be boxes loaded with only the bare OS and
software for the time-related tasks?
As in:

a dedicated machine/box for unencumbered acceptance of PPS, and
for systems with a business need, a dedicated NTP server/box
disciplined by the PPS source (with dedicated communication), while
maintaining internet NTP sources as backup for when the PPS source fails?
Is there a better way?
Other considerations?

Michael

When I was doing this many years ago with PC hardware the big problem
was not the OS or load on the OS but the x86 processor's SMM (system
management mode). Some motherboards and BIOS revisions were
completely unusable. It was always fun to use a low level I/O port to
monitor interrupt latency with an oscilloscope; with some practice it
was possible to identify the various peaks in the histogram at a
glance.

Eventually I gave up running real time tasks on PC hardware and moved
everything to dedicated hardware in one form or another.

On Tue, 14 Feb 2017 10:31:30 -0500, you wrote: >On 14/02/2017 7:26 AM, Bob Camp wrote: > >> A direct port might be a +/- 100 ns sort of thing most of the time and a +/-10 us >> thing every so often under some OSs. Most desktop operating systems are not >> designed to prioritize random pin interrupts. A dirt cheap MCU coded with a few >> (hundred) lines of assembly code may be a better option than a typical desktop. >> Complicating this further is the degree to which some OSs can be directly or >> indirectly optimized. Install *this* package and it all goes nuts. Install that package >> and not much happens . >> >> Bob > >Hence, wouldn't Best Practice be boxes loaded with only the bare OS and >software for the time-related tasks? >As in: >- a dedicated machine/box for unencumbered acceptance of PPS, and >- for systems with a business need, a dedicated NTP server/box >disciplined by the PPS source (with dedicated communication), while >maintaining internet NTP sources as backup for when the PPS source fails? >Is there a better way? >Other considerations? > >Michael When I was doing this many years ago with PC hardware the big problem was not the OS or load on the OS but the x86 processor's SMM (system management mode). Some motherboards and BIOS revisions were completely unusable. It was always fun to use a low level I/O port to monitor interrupt latency with an oscilloscope; with some practice it was possible to identify the various peaks in the histogram at a glance. Eventually I gave up running real time tasks on PC hardware and moved everything to dedicated hardware in one form or another.

TP

Thomas Petig

Fri, Feb 17, 2017 10:58 PM

Hi,

I was wondering whether there is some data/information available on the
claimed +/- 100 ns jitter?

Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
plotted, using some lines of Python, the time offset as attached. Just
to get an overview how it is 'worst case', i.e., user program, python,
etc. The 1PPS signal comes from a GPS rx.
Looks like a standard deviation of around 150 us.
y-axis: measured pps offset from full second (computer time) in us,
x-axis pps pulse number.

On the long term it looks interesting (while measuring I played with the
NTP server on this computer)
Until ca. second 10000: ntpd synchronization via internet
Until ca. second 17000: made an additional LAN NTP server (GPS) available
Until the end: replaced ntpd with chrony (still using internet and local
servers)

Interesting points:
-It looks surprisingly bad with using the normal ntpd (especially, there
is not really an improvement having an local GPS based server
available, did I do something wrong? Only the offset changes by ca. 3
ms.)
-It looks surprisingly good with chrony. But there are continuously
outliers of up to 4500 us, is this a result of the chrony control loop?
The time is wandering around with ntpd, but has less jitter.

Conclusion:
Despite the 150 us stddev, the using PPS over USB gives some interesting
inside of what the local ntp server is actually doing. It looks to me
like it would be an improvement to use it when using ntpd, but not when
using chrony.

Best regards,
Thomas
DK6KD
SA6CID

PS:
Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
offset in us)
http://petig.eu/pps-usb.txt

On Tue, Feb 14, 2017 at 07:26:23AM -0500, Bob Camp wrote:

Hi

A direct port might be a +/- 100 ns sort of thing most of the time and a +/-10 us
thing every so often under some OS’s. Most desktop operating systems are not
designed to prioritize random pin interrupts. A dirt cheap MCU coded with a few
(hundred) lines of assembly code may be a better option than a typical desktop.
Complicating this further is the degree to which some OS’s can be directly or
indirectly optimized. Install this package and it all goes nuts. Install that package
and not much happens ….

Bob

On Feb 13, 2017, at 11:07 AM, Ruslan Nabioullin rnabioullin@gmail.com wrote:

Hi, generally speaking, what are the performance differences between the following: 1. direct RS-232 (i.e., what I believe is a standard PCI card offering RS-232---essentially UARTs interfaced more-or-less directly to the PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might also have an IRIG input or even an onboard GNSS receiver).

Thanks in advance,
Ruslan

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hi, I was wondering whether there is some data/information available on the claimed +/- 100 ns jitter? Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I plotted, using some lines of Python, the time offset as attached. Just to get an overview how it is 'worst case', i.e., user program, python, etc. The 1PPS signal comes from a GPS rx. Looks like a standard deviation of around 150 us. y-axis: measured pps offset from full second (computer time) in us, x-axis pps pulse number. On the long term it looks interesting (while measuring I played with the NTP server on this computer) Until ca. second 10000: ntpd synchronization via internet Until ca. second 17000: made an additional LAN NTP server (GPS) available Until the end: replaced ntpd with chrony (still using internet and local servers) Interesting points: -It looks surprisingly bad with using the normal ntpd (especially, there is not really an improvement having an local GPS based server available, did I do something wrong? Only the offset changes by ca. 3 ms.) -It looks surprisingly good with chrony. But there are continuously outliers of up to 4500 us, is this a result of the chrony control loop? The time is wandering around with ntpd, but has less jitter. Conclusion: Despite the 150 us stddev, the using PPS over USB gives some interesting inside of what the local ntp server is actually doing. It looks to me like it would be an improvement to use it when using ntpd, but not when using chrony. Best regards, Thomas DK6KD SA6CID PS: Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS offset in us) http://petig.eu/pps-usb.txt On Tue, Feb 14, 2017 at 07:26:23AM -0500, Bob Camp wrote: > Hi > > A direct port might be a +/- 100 ns sort of thing most of the time and a +/-10 us > thing every so often under some OS’s. Most desktop operating systems are not > designed to prioritize random pin interrupts. A dirt cheap MCU coded with a few > (hundred) lines of assembly code may be a better option than a typical desktop. > Complicating this further is the degree to which some OS’s can be directly or > indirectly optimized. Install *this* package and it all goes nuts. Install that package > and not much happens …. > > Bob > > > On Feb 13, 2017, at 11:07 AM, Ruslan Nabioullin <rnabioullin@gmail.com> wrote: > > > > Hi, generally speaking, what are the performance differences between the following: 1. direct RS-232 (i.e., what I believe is a standard PCI card offering RS-232---essentially UARTs interfaced more-or-less directly to the PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might also have an IRIG input or even an onboard GNSS receiver). > > > > Thanks in advance, > > Ruslan > > _______________________________________________ > > time-nuts mailing list -- time-nuts@febo.com > > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. >

BC

Bob Camp

Sat, Feb 18, 2017 12:48 AM

Hi

Roughly speaking, if you have a 10 MHz clock driving a timer and the pin latches data
from that timer, you get 100 ns “buckets and +/- 100 ns “jitter”. You can find MCU’s that
will do this for < $1. If you go crazy, you can spend < $10 and still get a very fancy MCU
on a board with all the support “stuff”. That would get you into > 100 MHz clocks driving
counters that might be 32 bits wide.

The Intel guys have some very fast timers flying around their cpu’s. They would laugh
at the idea of a 10 or 100 MHz clock. If you can configure the pin to grab the data off those timer, you
have way better than 100 ns at the timer. The trick is writing a driver that does that. How
easy that is to do depends a lot on your OS and the chipset you are running. It may
be trivial or it may be impossible.

At some point one might ask: Is a $1 MCU a “system” or is it a peripheral?

Bob

On Feb 17, 2017, at 5:58 PM, Thomas Petig thomas@petig.eu wrote:

Hi,

I was wondering whether there is some data/information available on the
claimed +/- 100 ns jitter?

Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
plotted, using some lines of Python, the time offset as attached. Just
to get an overview how it is 'worst case', i.e., user program, python,
etc. The 1PPS signal comes from a GPS rx.
Looks like a standard deviation of around 150 us.
y-axis: measured pps offset from full second (computer time) in us,
x-axis pps pulse number.

On the long term it looks interesting (while measuring I played with the
NTP server on this computer)
Until ca. second 10000: ntpd synchronization via internet
Until ca. second 17000: made an additional LAN NTP server (GPS) available
Until the end: replaced ntpd with chrony (still using internet and local
servers)

Interesting points:
-It looks surprisingly bad with using the normal ntpd (especially, there
is not really an improvement having an local GPS based server
available, did I do something wrong? Only the offset changes by ca. 3
ms.)
-It looks surprisingly good with chrony. But there are continuously
outliers of up to 4500 us, is this a result of the chrony control loop?
The time is wandering around with ntpd, but has less jitter.

Conclusion:
Despite the 150 us stddev, the using PPS over USB gives some interesting
inside of what the local ntp server is actually doing. It looks to me
like it would be an improvement to use it when using ntpd, but not when
using chrony.

Best regards,
Thomas
DK6KD
SA6CID

PS:
Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
offset in us)
http://petig.eu/pps-usb.txt

On Tue, Feb 14, 2017 at 07:26:23AM -0500, Bob Camp wrote:

Hi

A direct port might be a +/- 100 ns sort of thing most of the time and a +/-10 us
thing every so often under some OS’s. Most desktop operating systems are not
designed to prioritize random pin interrupts. A dirt cheap MCU coded with a few
(hundred) lines of assembly code may be a better option than a typical desktop.
Complicating this further is the degree to which some OS’s can be directly or
indirectly optimized. Install this package and it all goes nuts. Install that package
and not much happens ….

Bob

On Feb 13, 2017, at 11:07 AM, Ruslan Nabioullin rnabioullin@gmail.com wrote:

Hi, generally speaking, what are the performance differences between the following: 1. direct RS-232 (i.e., what I believe is a standard PCI card offering RS-232---essentially UARTs interfaced more-or-less directly to the PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might also have an IRIG input or even an onboard GNSS receiver).

Thanks in advance,
Ruslan

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

<overall.jpg><zoom.jpg>_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hi Roughly speaking, if you have a 10 MHz clock driving a timer and the pin latches data from that timer, you get 100 ns “buckets and +/- 100 ns “jitter”. You can find MCU’s that will do this for < $1. If you go crazy, you can spend < $10 and still get a very fancy MCU on a board with all the support “stuff”. That would get you into > 100 MHz clocks driving counters that might be 32 bits wide. The Intel guys have some *very* fast timers flying around their cpu’s. They would laugh at the idea of a 10 or 100 MHz clock. If you can configure the pin to grab the data off those timer, you have way better than 100 ns at the timer. The trick is writing a driver that does that. How easy that is to do depends a *lot* on your OS and the chipset you are running. It may be trivial or it may be impossible. At some point one might ask: Is a $1 MCU a “system” or is it a peripheral? Bob > On Feb 17, 2017, at 5:58 PM, Thomas Petig <thomas@petig.eu> wrote: > > Hi, > > I was wondering whether there is some data/information available on the > claimed +/- 100 ns jitter? > > Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I > plotted, using some lines of Python, the time offset as attached. Just > to get an overview how it is 'worst case', i.e., user program, python, > etc. The 1PPS signal comes from a GPS rx. > Looks like a standard deviation of around 150 us. > y-axis: measured pps offset from full second (computer time) in us, > x-axis pps pulse number. > > On the long term it looks interesting (while measuring I played with the > NTP server on this computer) > Until ca. second 10000: ntpd synchronization via internet > Until ca. second 17000: made an additional LAN NTP server (GPS) available > Until the end: replaced ntpd with chrony (still using internet and local > servers) > > Interesting points: > -It looks surprisingly bad with using the normal ntpd (especially, there > is not really an improvement having an local GPS based server > available, did I do something wrong? Only the offset changes by ca. 3 > ms.) > -It looks surprisingly good with chrony. But there are continuously > outliers of up to 4500 us, is this a result of the chrony control loop? > The time is wandering around with ntpd, but has less jitter. > > Conclusion: > Despite the 150 us stddev, the using PPS over USB gives some interesting > inside of what the local ntp server is actually doing. It looks to me > like it would be an improvement to use it when using ntpd, but not when > using chrony. > > Best regards, > Thomas > DK6KD > SA6CID > > PS: > Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS > offset in us) > http://petig.eu/pps-usb.txt > > On Tue, Feb 14, 2017 at 07:26:23AM -0500, Bob Camp wrote: >> Hi >> >> A direct port might be a +/- 100 ns sort of thing most of the time and a +/-10 us >> thing every so often under some OS’s. Most desktop operating systems are not >> designed to prioritize random pin interrupts. A dirt cheap MCU coded with a few >> (hundred) lines of assembly code may be a better option than a typical desktop. >> Complicating this further is the degree to which some OS’s can be directly or >> indirectly optimized. Install *this* package and it all goes nuts. Install that package >> and not much happens …. >> >> Bob >> >>> On Feb 13, 2017, at 11:07 AM, Ruslan Nabioullin <rnabioullin@gmail.com> wrote: >>> >>> Hi, generally speaking, what are the performance differences between the following: 1. direct RS-232 (i.e., what I believe is a standard PCI card offering RS-232---essentially UARTs interfaced more-or-less directly to the PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might also have an IRIG input or even an onboard GNSS receiver). >>> >>> Thanks in advance, >>> Ruslan >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts@febo.com >>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> > <overall.jpg><zoom.jpg>_______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

CH

Christopher Hoover

Sat, Feb 18, 2017 4:51 AM

The Intel guys have some very fast timers flying around their cpu’s.
They would laugh
at the idea of a 10 or 100 MHz clock. If you can configure the pin to grab
the data off those timer, you
have way better than 100 ns at the timer.

We're most certainly getting off topic, but the errata on TSC [1] and HPET
[2] are long and mostly not public. There be dragons with DVFS [3] and
power/idle states.

On Linux you can tell what you have available and what you are using by
looking in /sys/devices/system/clocksource/clocksource0, e.g.

ch@asus-ch:~$ cat
/sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet
acpi_pm ch@asus-ch:~$ cat
/sys/devices/system/clocksource/clocksource0/current_clocksource tsc
ch@asus-ch:~$

Linux usually disqualifies egregiously bad clock soureces.

-christopher
73 de AI6KG

[1] https://en.wikipedia.org/wiki/Time_Stamp_Counter
[2] https://en.wikipedia.org/wiki/High_Precision_Event_Timer
[3] https://en.wikipedia.org/wiki/Dynamic_voltage_scaling

On Fri, Feb 17, 2017 at 4:48 PM, Bob Camp kb8tq@n1k.org wrote:

Hi

Roughly speaking, if you have a 10 MHz clock driving a timer and the pin
latches data
from that timer, you get 100 ns “buckets and +/- 100 ns “jitter”. You can
find MCU’s that
will do this for < $1. If you go crazy, you can spend < $10 and still get
a very fancy MCU
on a board with all the support “stuff”. That would get you into > 100 MHz
clocks driving
counters that might be 32 bits wide.

The Intel guys have some very fast timers flying around their cpu’s.
They would laugh
at the idea of a 10 or 100 MHz clock. If you can configure the pin to grab
the data off those timer, you
have way better than 100 ns at the timer. The trick is writing a driver
that does that. How
easy that is to do depends a lot on your OS and the chipset you are
running. It may
be trivial or it may be impossible.

At some point one might ask: Is a $1 MCU a “system” or is it a peripheral?

Bob

On Feb 17, 2017, at 5:58 PM, Thomas Petig thomas@petig.eu wrote:

Hi,

I was wondering whether there is some data/information available on the
claimed +/- 100 ns jitter?

Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
plotted, using some lines of Python, the time offset as attached. Just
to get an overview how it is 'worst case', i.e., user program, python,
etc. The 1PPS signal comes from a GPS rx.
Looks like a standard deviation of around 150 us.
y-axis: measured pps offset from full second (computer time) in us,
x-axis pps pulse number.

On the long term it looks interesting (while measuring I played with the
NTP server on this computer)
Until ca. second 10000: ntpd synchronization via internet
Until ca. second 17000: made an additional LAN NTP server (GPS) available
Until the end: replaced ntpd with chrony (still using internet and local
servers)

Interesting points:
-It looks surprisingly bad with using the normal ntpd (especially, there
is not really an improvement having an local GPS based server
available, did I do something wrong? Only the offset changes by ca. 3
ms.)
-It looks surprisingly good with chrony. But there are continuously
outliers of up to 4500 us, is this a result of the chrony control loop?
The time is wandering around with ntpd, but has less jitter.

Conclusion:
Despite the 150 us stddev, the using PPS over USB gives some interesting
inside of what the local ntp server is actually doing. It looks to me
like it would be an improvement to use it when using ntpd, but not when
using chrony.

Best regards,
Thomas
DK6KD
SA6CID

PS:
Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
offset in us)
http://petig.eu/pps-usb.txt

On Tue, Feb 14, 2017 at 07:26:23AM -0500, Bob Camp wrote:

Hi

A direct port might be a +/- 100 ns sort of thing most of the time and

a +/-10 us

thing every so often under some OS’s. Most desktop operating systems

are not

designed to prioritize random pin interrupts. A dirt cheap MCU coded

with a few

(hundred) lines of assembly code may be a better option than a typical

desktop.

Complicating this further is the degree to which some OS’s can be

directly or

indirectly optimized. Install this package and it all goes nuts.

Install that package

and not much happens ….

Bob

On Feb 13, 2017, at 11:07 AM, Ruslan Nabioullin rnabioullin@gmail.com

wrote:

Hi, generally speaking, what are the performance differences between

the following: 1. direct RS-232 (i.e., what I believe is a standard PCI
card offering RS-232---essentially UARTs interfaced more-or-less directly
to the PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might
also have an IRIG input or even an onboard GNSS receiver).

Thanks in advance,
Ruslan

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/

mailman/listinfo/time-nuts

and follow the instructions there.

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/

mailman/listinfo/time-nuts

and follow the instructions there.

<overall.jpg><zoom.jpg>_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/

mailman/listinfo/time-nuts

and follow the instructions there.

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.

> > The Intel guys have some *very* fast timers flying around their cpu’s. > They would laugh > at the idea of a 10 or 100 MHz clock. If you can configure the pin to grab > the data off those timer, you > have way better than 100 ns at the timer. We're most certainly getting off topic, but the errata on TSC [1] and HPET [2] are long and mostly not public. There be dragons with DVFS [3] and power/idle states. On Linux you can tell what you have available and what you are using by looking in /sys/devices/system/clocksource/clocksource0, e.g. ch@asus-ch:~$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm ch@asus-ch:~$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc ch@asus-ch:~$ Linux usually disqualifies egregiously bad clock soureces. -christopher 73 de AI6KG [1] https://en.wikipedia.org/wiki/Time_Stamp_Counter [2] https://en.wikipedia.org/wiki/High_Precision_Event_Timer [3] https://en.wikipedia.org/wiki/Dynamic_voltage_scaling On Fri, Feb 17, 2017 at 4:48 PM, Bob Camp <kb8tq@n1k.org> wrote: > Hi > > Roughly speaking, if you have a 10 MHz clock driving a timer and the pin > latches data > from that timer, you get 100 ns “buckets and +/- 100 ns “jitter”. You can > find MCU’s that > will do this for < $1. If you go crazy, you can spend < $10 and still get > a very fancy MCU > on a board with all the support “stuff”. That would get you into > 100 MHz > clocks driving > counters that might be 32 bits wide. > > The Intel guys have some *very* fast timers flying around their cpu’s. > They would laugh > at the idea of a 10 or 100 MHz clock. If you can configure the pin to grab > the data off those timer, you > have way better than 100 ns at the timer. The trick is writing a driver > that does that. How > easy that is to do depends a *lot* on your OS and the chipset you are > running. It may > be trivial or it may be impossible. > > At some point one might ask: Is a $1 MCU a “system” or is it a peripheral? > > Bob > > > > On Feb 17, 2017, at 5:58 PM, Thomas Petig <thomas@petig.eu> wrote: > > > > Hi, > > > > I was wondering whether there is some data/information available on the > > claimed +/- 100 ns jitter? > > > > Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I > > plotted, using some lines of Python, the time offset as attached. Just > > to get an overview how it is 'worst case', i.e., user program, python, > > etc. The 1PPS signal comes from a GPS rx. > > Looks like a standard deviation of around 150 us. > > y-axis: measured pps offset from full second (computer time) in us, > > x-axis pps pulse number. > > > > On the long term it looks interesting (while measuring I played with the > > NTP server on this computer) > > Until ca. second 10000: ntpd synchronization via internet > > Until ca. second 17000: made an additional LAN NTP server (GPS) available > > Until the end: replaced ntpd with chrony (still using internet and local > > servers) > > > > Interesting points: > > -It looks surprisingly bad with using the normal ntpd (especially, there > > is not really an improvement having an local GPS based server > > available, did I do something wrong? Only the offset changes by ca. 3 > > ms.) > > -It looks surprisingly good with chrony. But there are continuously > > outliers of up to 4500 us, is this a result of the chrony control loop? > > The time is wandering around with ntpd, but has less jitter. > > > > Conclusion: > > Despite the 150 us stddev, the using PPS over USB gives some interesting > > inside of what the local ntp server is actually doing. It looks to me > > like it would be an improvement to use it when using ntpd, but not when > > using chrony. > > > > Best regards, > > Thomas > > DK6KD > > SA6CID > > > > PS: > > Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS > > offset in us) > > http://petig.eu/pps-usb.txt > > > > On Tue, Feb 14, 2017 at 07:26:23AM -0500, Bob Camp wrote: > >> Hi > >> > >> A direct port might be a +/- 100 ns sort of thing most of the time and > a +/-10 us > >> thing every so often under some OS’s. Most desktop operating systems > are not > >> designed to prioritize random pin interrupts. A dirt cheap MCU coded > with a few > >> (hundred) lines of assembly code may be a better option than a typical > desktop. > >> Complicating this further is the degree to which some OS’s can be > directly or > >> indirectly optimized. Install *this* package and it all goes nuts. > Install that package > >> and not much happens …. > >> > >> Bob > >> > >>> On Feb 13, 2017, at 11:07 AM, Ruslan Nabioullin <rnabioullin@gmail.com> > wrote: > >>> > >>> Hi, generally speaking, what are the performance differences between > the following: 1. direct RS-232 (i.e., what I believe is a standard PCI > card offering RS-232---essentially UARTs interfaced more-or-less directly > to the PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might > also have an IRIG input or even an onboard GNSS receiver). > >>> > >>> Thanks in advance, > >>> Ruslan > >>> _______________________________________________ > >>> time-nuts mailing list -- time-nuts@febo.com > >>> To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > >>> and follow the instructions there. > >> > >> _______________________________________________ > >> time-nuts mailing list -- time-nuts@febo.com > >> To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > >> and follow the instructions there. > >> > > <overall.jpg><zoom.jpg>_______________________________________________ > > time-nuts mailing list -- time-nuts@febo.com > > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > > and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. >

T

timenut@metachaos.net

Sat, Feb 18, 2017 5:57 AM

I have finally ordered a GPSDO (probably get here in April). In the meantime,
I have the GPS antenna (Luctel, 26Db). I picked up a 20' solid section of 1 1/4"
copper pipe at the plumbing store with the intention of mounting it to my
chimney.

My question is about the stability of that mounting. I expect that 16 or 17
feet of the pipe will be above the chimney. The weight of the GPS antenna is
trivial. The effective cross section area of the pipe is very small as well,
so I would think that wind effects would be pretty small even for a good
breeze.

Will that be sufficiently stable, or will I need to include guy wires? If so,
are there any recommendations in that area. I don't really have any experience
putting up antennas. I know that TV antennas are much heavier and, even though
not mounted as high, still 10' or so is common without guy wires.

Thanks.

Michael

I have finally ordered a GPSDO (probably get here in April). In the meantime, I have the GPS antenna (Luctel, 26Db). I picked up a 20' solid section of 1 1/4" copper pipe at the plumbing store with the intention of mounting it to my chimney. My question is about the stability of that mounting. I expect that 16 or 17 feet of the pipe will be above the chimney. The weight of the GPS antenna is trivial. The effective cross section area of the pipe is very small as well, so I would think that wind effects would be pretty small even for a good breeze. Will that be sufficiently stable, or will I need to include guy wires? If so, are there any recommendations in that area. I don't really have any experience putting up antennas. I know that TV antennas are much heavier and, even though not mounted as high, still 10' or so is common without guy wires. Thanks. Michael

CA

Chris Albertson

Sat, Feb 18, 2017 7:41 AM

Copper? What an expensive material to use. Galvanized iron pipe is
cheaper and very strong. But even the thinner "type M" copper pipe
is strong enough if it is 1 1/4" diameter.

You should not need guy wires on such a short mast. You will need
likely the proper threaded adaptor to fit the antenna mount. Run the
coax antenna lead down the center of the pipe. Also be sure and
ground the pipe to a ground rod. The ground wire needs to be (from
memory) #8 or larger. You don't want a 20 foot tall ungrounded
lightening rod up on the roof. Electric code requires the ground.

One thing, because you used copper pipe use either copper wire for the
ground or if using aluminum wire use the special fittings/clamps
designed for connecting aluminum to copper.

I assume this is an unused chimney?

On Fri, Feb 17, 2017 at 9:57 PM, timenut@metachaos.net wrote:

I have finally ordered a GPSDO (probably get here in April). In the meantime,
I have the GPS antenna (Luctel, 26Db). I picked up a 20' solid section of 1 1/4"
copper pipe at the plumbing store with the intention of mounting it to my
chimney.

My question is about the stability of that mounting. I expect that 16 or 17
feet of the pipe will be above the chimney. The weight of the GPS antenna is
trivial. The effective cross section area of the pipe is very small as well,
so I would think that wind effects would be pretty small even for a good
breeze.

Will that be sufficiently stable, or will I need to include guy wires? If so,
are there any recommendations in that area. I don't really have any experience
putting up antennas. I know that TV antennas are much heavier and, even though
not mounted as high, still 10' or so is common without guy wires.

Thanks.

Michael

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

--

Chris Albertson
Redondo Beach, California

Copper? What an expensive material to use. Galvanized iron pipe is cheaper and very strong. But even the thinner "type M" copper pipe is strong enough if it is 1 1/4" diameter. You should not need guy wires on such a short mast. You will need likely the proper threaded adaptor to fit the antenna mount. Run the coax antenna lead down the center of the pipe. Also be sure and ground the pipe to a ground rod. The ground wire needs to be (from memory) #8 or larger. You don't want a 20 foot tall ungrounded lightening rod up on the roof. Electric code requires the ground. One thing, because you used copper pipe use either copper wire for the ground or if using aluminum wire use the special fittings/clamps designed for connecting aluminum to copper. I assume this is an unused chimney? On Fri, Feb 17, 2017 at 9:57 PM, <timenut@metachaos.net> wrote: > I have finally ordered a GPSDO (probably get here in April). In the meantime, > I have the GPS antenna (Luctel, 26Db). I picked up a 20' solid section of 1 1/4" > copper pipe at the plumbing store with the intention of mounting it to my > chimney. > > My question is about the stability of that mounting. I expect that 16 or 17 > feet of the pipe will be above the chimney. The weight of the GPS antenna is > trivial. The effective cross section area of the pipe is very small as well, > so I would think that wind effects would be pretty small even for a good > breeze. > > Will that be sufficiently stable, or will I need to include guy wires? If so, > are there any recommendations in that area. I don't really have any experience > putting up antennas. I know that TV antennas are much heavier and, even though > not mounted as high, still 10' or so is common without guy wires. > > Thanks. > > Michael > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. -- Chris Albertson Redondo Beach, California

DJ

David J Taylor

Sat, Feb 18, 2017 9:53 AM

Hi,

I was wondering whether there is some data/information available on the
claimed +/- 100 ns jitter?

Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
plotted, using some lines of Python, the time offset as attached. Just
to get an overview how it is 'worst case', i.e., user program, python,
etc. The 1PPS signal comes from a GPS rx.
Looks like a standard deviation of around 150 us.
y-axis: measured pps offset from full second (computer time) in us,
x-axis pps pulse number.

On the long term it looks interesting (while measuring I played with the
NTP server on this computer)
Until ca. second 10000: ntpd synchronization via internet
Until ca. second 17000: made an additional LAN NTP server (GPS) available
Until the end: replaced ntpd with chrony (still using internet and local
servers)

Interesting points:
-It looks surprisingly bad with using the normal ntpd (especially, there
is not really an improvement having an local GPS based server
available, did I do something wrong? Only the offset changes by ca. 3
ms.)
-It looks surprisingly good with chrony. But there are continuously
outliers of up to 4500 us, is this a result of the chrony control loop?
The time is wandering around with ntpd, but has less jitter.

Conclusion:
Despite the 150 us stddev, the using PPS over USB gives some interesting
inside of what the local ntp server is actually doing. It looks to me
like it would be an improvement to use it when using ntpd, but not when
using chrony.

Best regards,
Thomas
DK6KD
SA6CID

PS:
Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
offset in us)
http://petig.eu/pps-usb.txt

---================

Thomas,

I've done some tests with PPS over USB with Windows some time back, which
showed that PPS?USB could be better than LAN-sync alone, but that also
included a reduction of the poll interval from possibly 64 seconds for LAN
sync to 16 seconds for PPS sync, which may have influenced the results.

<pet-peeve>It would be helpful to have some units on the axes - 10000 what?
I'm guessing microseconds....</pet-peeve>

For comparison, here is a Raspberry Pi running NTP, with the reported offset
plotted against time.

http://www.satsignal.eu/mrtg/raspi14_ntp_3.html

This Raspberry Pi (running a seismic detector) is using an Ethernet
connection via Power-line Ethernet (yes, I know, QRM etc. etc.), and a
couple of switches to a very good stratum-1 server. I would estimate from
your graph that the jitter in offset is about 1 millisecond peak-to-peak,
but it seems that I get less than that - perhaps 100 microseconds
peak-to-peak with occasional excursions outside that. This is with the
latest reference version of NTP.

 remote           refid      st t when poll reach   delay   offset

jitter

---============
*192.168.0.20 .GPS. 1 u 17 32 377 12.351 0.000
0.428
+192.168.0.11 .uPPS. 1 u 2 32 377 12.432 -0.106
0.824
-192.168.0.3 .kPPS. 1 u 13 32 377 21.366 -4.524
0.804
+192.168.0.83 .kPPS. 1 u 27 32 377 21.614 -4.511
1.206
uk.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000
0.001
-193.150.34.2 133.150.251.233 3 u 38 64 137 32.343 2.738
1.477
-80.87.128.17 94.125.129.7 3 u 30 64 375 53.337 -1.225
1.516
-192.146.137.13 82.148.230.254 2 u 56 64 377 46.089 2.220
2.535
-129.250.35.250 249.224.99.213 2 u 169 64 214 42.499 -3.015
12.507
-213.130.44.252 145.238.203.14 2 u 487 64 200 37.210 -0.725
13.232

73,
David GM8ARV

SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv

Hi, I was wondering whether there is some data/information available on the claimed +/- 100 ns jitter? Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I plotted, using some lines of Python, the time offset as attached. Just to get an overview how it is 'worst case', i.e., user program, python, etc. The 1PPS signal comes from a GPS rx. Looks like a standard deviation of around 150 us. y-axis: measured pps offset from full second (computer time) in us, x-axis pps pulse number. On the long term it looks interesting (while measuring I played with the NTP server on this computer) Until ca. second 10000: ntpd synchronization via internet Until ca. second 17000: made an additional LAN NTP server (GPS) available Until the end: replaced ntpd with chrony (still using internet and local servers) Interesting points: -It looks surprisingly bad with using the normal ntpd (especially, there is not really an improvement having an local GPS based server available, did I do something wrong? Only the offset changes by ca. 3 ms.) -It looks surprisingly good with chrony. But there are continuously outliers of up to 4500 us, is this a result of the chrony control loop? The time is wandering around with ntpd, but has less jitter. Conclusion: Despite the 150 us stddev, the using PPS over USB gives some interesting inside of what the local ntp server is actually doing. It looks to me like it would be an improvement to use it when using ntpd, but not when using chrony. Best regards, Thomas DK6KD SA6CID PS: Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS offset in us) http://petig.eu/pps-usb.txt ================================================= Thomas, I've done some tests with PPS over USB with Windows some time back, which showed that PPS?USB could be better than LAN-sync alone, but that also included a reduction of the poll interval from possibly 64 seconds for LAN sync to 16 seconds for PPS sync, which may have influenced the results. <pet-peeve>It would be helpful to have some units on the axes - 10000 what? I'm guessing microseconds....</pet-peeve> For comparison, here is a Raspberry Pi running NTP, with the reported offset plotted against time. http://www.satsignal.eu/mrtg/raspi14_ntp_3.html This Raspberry Pi (running a seismic detector) is using an Ethernet connection via Power-line Ethernet (yes, I know, QRM etc. etc.), and a couple of switches to a very good stratum-1 server. I would estimate from your graph that the jitter in offset is about 1 millisecond peak-to-peak, but it seems that I get less than that - perhaps 100 microseconds peak-to-peak with occasional excursions outside that. This is with the latest reference version of NTP. remote refid st t when poll reach delay offset jitter ============================================================================== *192.168.0.20 .GPS. 1 u 17 32 377 12.351 0.000 0.428 +192.168.0.11 .uPPS. 1 u 2 32 377 12.432 -0.106 0.824 -192.168.0.3 .kPPS. 1 u 13 32 377 21.366 -4.524 0.804 +192.168.0.83 .kPPS. 1 u 27 32 377 21.614 -4.511 1.206 uk.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.001 -193.150.34.2 133.150.251.233 3 u 38 64 137 32.343 2.738 1.477 -80.87.128.17 94.125.129.7 3 u 30 64 375 53.337 -1.225 1.516 -192.146.137.13 82.148.230.254 2 u 56 64 377 46.089 2.220 2.535 -129.250.35.250 249.224.99.213 2 u 169 64 214 42.499 -3.015 12.507 -213.130.44.252 145.238.203.14 2 u 487 64 200 37.210 -0.725 13.232 73, David GM8ARV -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-taylor@blueyonder.co.uk Twitter: @gm8arv

PL

Pete Lancashire

Sat, Feb 18, 2017 12:33 PM

I pretty much agree on the fittings, only ones designed for outdoor
and contact with copper. Stainless steel, bronze etc.

I disagree about guy wires, Are you in a area that gets winds and
gusts > 30 mph ? Then I would guy it no matter what, it may even be
code.

Ever get below freezing where you are, that pipe could end up easily
having 10 lbs of ice per foot, thats 200 lbs and then a 5x increase in
wind resistance.

=pete

On Fri, Feb 17, 2017 at 11:41 PM, Chris Albertson
albertson.chris@gmail.com wrote:

Copper? What an expensive material to use. Galvanized iron pipe is
cheaper and very strong. But even the thinner "type M" copper pipe
is strong enough if it is 1 1/4" diameter.

You should not need guy wires on such a short mast. You will need
likely the proper threaded adaptor to fit the antenna mount. Run the
coax antenna lead down the center of the pipe. Also be sure and
ground the pipe to a ground rod. The ground wire needs to be (from
memory) #8 or larger. You don't want a 20 foot tall ungrounded
lightening rod up on the roof. Electric code requires the ground.

One thing, because you used copper pipe use either copper wire for the
ground or if using aluminum wire use the special fittings/clamps
designed for connecting aluminum to copper.

I assume this is an unused chimney?

On Fri, Feb 17, 2017 at 9:57 PM, timenut@metachaos.net wrote:

I have finally ordered a GPSDO (probably get here in April). In the meantime,
I have the GPS antenna (Luctel, 26Db). I picked up a 20' solid section of 1 1/4"
copper pipe at the plumbing store with the intention of mounting it to my
chimney.

My question is about the stability of that mounting. I expect that 16 or 17
feet of the pipe will be above the chimney. The weight of the GPS antenna is
trivial. The effective cross section area of the pipe is very small as well,
so I would think that wind effects would be pretty small even for a good
breeze.

Will that be sufficiently stable, or will I need to include guy wires? If so,
are there any recommendations in that area. I don't really have any experience
putting up antennas. I know that TV antennas are much heavier and, even though
not mounted as high, still 10' or so is common without guy wires.

Thanks.

Michael

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

--

Chris Albertson
Redondo Beach, California

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

I pretty much agree on the fittings, only ones designed for outdoor and contact with copper. Stainless steel, bronze etc. I disagree about guy wires, Are you in a area that gets winds and gusts > 30 mph ? Then I would guy it no matter what, it may even be code. Ever get below freezing where you are, that pipe could end up easily having 10 lbs of ice per foot, thats 200 lbs and then a 5x increase in wind resistance. =pete On Fri, Feb 17, 2017 at 11:41 PM, Chris Albertson <albertson.chris@gmail.com> wrote: > Copper? What an expensive material to use. Galvanized iron pipe is > cheaper and very strong. But even the thinner "type M" copper pipe > is strong enough if it is 1 1/4" diameter. > > You should not need guy wires on such a short mast. You will need > likely the proper threaded adaptor to fit the antenna mount. Run the > coax antenna lead down the center of the pipe. Also be sure and > ground the pipe to a ground rod. The ground wire needs to be (from > memory) #8 or larger. You don't want a 20 foot tall ungrounded > lightening rod up on the roof. Electric code requires the ground. > > One thing, because you used copper pipe use either copper wire for the > ground or if using aluminum wire use the special fittings/clamps > designed for connecting aluminum to copper. > > I assume this is an unused chimney? > > On Fri, Feb 17, 2017 at 9:57 PM, <timenut@metachaos.net> wrote: >> I have finally ordered a GPSDO (probably get here in April). In the meantime, >> I have the GPS antenna (Luctel, 26Db). I picked up a 20' solid section of 1 1/4" >> copper pipe at the plumbing store with the intention of mounting it to my >> chimney. >> >> My question is about the stability of that mounting. I expect that 16 or 17 >> feet of the pipe will be above the chimney. The weight of the GPS antenna is >> trivial. The effective cross section area of the pipe is very small as well, >> so I would think that wind effects would be pretty small even for a good >> breeze. >> >> Will that be sufficiently stable, or will I need to include guy wires? If so, >> are there any recommendations in that area. I don't really have any experience >> putting up antennas. I know that TV antennas are much heavier and, even though >> not mounted as high, still 10' or so is common without guy wires. >> >> Thanks. >> >> Michael >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > > > -- > > Chris Albertson > Redondo Beach, California > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

BC

Bob Camp

Sat, Feb 18, 2017 1:32 PM

Hi

Let’s back off a bit here.

If the chimney is above the rest of the house, simply putting the antenna a foot or
two above the chimney will get you past the immediate issues of the house blocking
or reflecting stuff.

If the top of the chimney has a view to the south down to about 10 degrees off the
horizon and it maintains that for most of a +/- 100 degree arc, that is doing fine.

If the application is just timing, having a mount that does not move around a lot
is a really good idea.

With any antenna, putting it up higher than needed simply makes it a better lightning
target (you will have proper grounding and suppression on this antenna, it still
is not perfect).

On a GPSDO with a good sky view, you may well set the elevation mask to something
like 20 or even 30 degrees to improve the timing performance. When you do, all
the effort to get a sky view down to 10 degrees becomes a bit less worthwhile.

=====

So: what is the reason for getting the antenna 15 feet above the chimney?

Bob

On Feb 18, 2017, at 12:57 AM, timenut@metachaos.net wrote:

I have finally ordered a GPSDO (probably get here in April). In the meantime,
I have the GPS antenna (Luctel, 26Db). I picked up a 20' solid section of 1 1/4"
copper pipe at the plumbing store with the intention of mounting it to my
chimney.

My question is about the stability of that mounting. I expect that 16 or 17
feet of the pipe will be above the chimney. The weight of the GPS antenna is
trivial. The effective cross section area of the pipe is very small as well,
so I would think that wind effects would be pretty small even for a good
breeze.

Will that be sufficiently stable, or will I need to include guy wires? If so,
are there any recommendations in that area. I don't really have any experience
putting up antennas. I know that TV antennas are much heavier and, even though
not mounted as high, still 10' or so is common without guy wires.

Thanks.

Michael

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hi Let’s back off a bit here. If the chimney is above the rest of the house, simply putting the antenna a foot or two above the chimney will get you past the immediate issues of the house blocking or reflecting stuff. If the top of the chimney has a view to the south down to about 10 degrees off the horizon *and* it maintains that for most of a +/- 100 degree arc, that is doing fine. If the application is just timing, having a mount that does not move around a lot is a really good idea. With any antenna, putting it up higher than needed simply makes it a better lightning target (you *will* have proper grounding and suppression on this antenna, it still is not perfect). On a GPSDO with a good sky view, you may well set the elevation mask to something like 20 or even 30 degrees to improve the timing performance. When you do, all the effort to get a sky view down to 10 degrees becomes a bit less worthwhile. ===== So: what is the reason for getting the antenna 15 feet above the chimney? Bob > On Feb 18, 2017, at 12:57 AM, timenut@metachaos.net wrote: > > I have finally ordered a GPSDO (probably get here in April). In the meantime, > I have the GPS antenna (Luctel, 26Db). I picked up a 20' solid section of 1 1/4" > copper pipe at the plumbing store with the intention of mounting it to my > chimney. > > My question is about the stability of that mounting. I expect that 16 or 17 > feet of the pipe will be above the chimney. The weight of the GPS antenna is > trivial. The effective cross section area of the pipe is very small as well, > so I would think that wind effects would be pretty small even for a good > breeze. > > Will that be sufficiently stable, or will I need to include guy wires? If so, > are there any recommendations in that area. I don't really have any experience > putting up antennas. I know that TV antennas are much heavier and, even though > not mounted as high, still 10' or so is common without guy wires. > > Thanks. > > Michael > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

time-nuts@lists.febo.com

``direct'' RS-232 vs. RS-232 via USB vs. PPS decoding cards

73,
David GM8ARV