Sarah, David,
I've changed my Minpoll and Maxpoll settings as suggested by David and now
getting much better results (1 - 2 mS) when settled for the Meinberg Stratum
1 units. I'm also using Meinberg's version of NTP (6.2.6).
I'm still experimenting with settings, but it looks like my original post
regarding the Ethernet over Power adapters might have been a red herring.
Rob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Sarah White
Sent: 13 February 2013 01:42
To: Discussion of precise time and frequency measurement
Subject: [time-nuts] Network jitter with NTP
David,
Thanks for posting that. I'm currently doing some testing over wifi links
myself, and found that page very useful. You do a really good job
documenting your experiences with GPS-based NTP refclocks, and I appreciate
all the hard work.
I just wanted to ask though, are you compiling your own NTP now or what?
http://www.davehart.net/ntp/win/x86.please.see.http.support.ntp.org-people-h
art-win-x86/
but then under http://support.ntp.org/people/hart/win/x86/
... most recent seems to be ntp-4.2.7p310
^Basically, you were previously documenting use of dave hart's builds
(overlaid over a meinberg ntp install or otherwise)
Sorry rob, I don't have any experience with powerline adapters, but I'm
treating your experiences (which don't seem to be promising) as a data point
showing that they're no better for timing than using wifi...
I'm getting high & unpredictable jitter with NTP over wifi as well (compared
to cat 6 RJ-45 crossover cable directly between NTP servers)
1-20ms jitter for 5ghz band, 802.11n connection running with bitrate
manually limited to 6mbit/s
5-70ms jitter for the 2.4ghz band, 802.11g connection running with bitrate
auto-negotiation (up to 54mbit/s)
... My best case scenario for NTP jitter is about 0-5ms between a stratum 1
and a stratum 2 server directly connected via gigabit ethernet crossover
(and the stratum 1 itself with a connected refclock seems to be at a
baseline of 0-1ms most of the time, and rarely higher than 2ms)
Those are just rough estimates based on casual observation, and I haven't
done any long-term measurements yet like David Taylor's work...
I'm "getting there" though it's coming slowly because of my trouble with
learning curve in this area.
--Sarah
P.S. I renamed this post. The title "Possibly off topic - Jitter on Ethernet
over poweradapters" seemed silly.
Rob,
It's not quite clear which direction you are measuring. I take it
your Meinberg servers are "perfect" in NTP terms, and you are
monitoring from the house? Or vice-versa? Anyway, my first guess is
that jitter might be not dissimilar to Wi-Fi, in which case my
lightly-loaded Wi-Fi results might be a starting point:
http://www.satsignal.eu/mrtg/performance_ntp_wifi.php
Note the improvement with Windows-8 and the latest NTP (top graph, PC
Bergen), and the others are somewhat variable.
Cheers,
David
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.
Sarah, David,
I've changed my Minpoll and Maxpoll settings as suggested by David and now
getting much better results (1 - 2 mS) when settled for the Meinberg Stratum
1 units. I'm also using Meinberg's version of NTP (6.2.6).
I'm still experimenting with settings, but it looks like my original post
regarding the Ethernet over Power adapters might have been a red herring.
Rob, your previous post is likely quite valid. The power adapters, like
Wi-Fi, introduce timing uncertainties as those more expert than me have
described. The smaller poll intervals you are now using hide the problem
with Windows-7 & Vista which was fixed in 4.2.7p348 and later.
So with the latest version (4.2.7p354)
http://www.satsignal.eu/ntp/x86/
you should find improved results even with the longer poll interval. Of
course, once you are using servers on your LAN there's no need to use long
poll intervals to access them, so you might want to leave it as is (first
rule of networking: if it works, leave it!). If you need even better
timekeeping on the non-stratum-1 clients, consider Windows-8. I did say
"consider", not "you must install", BTW!
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
On 02/12/2013 08:19 PM, Mike S wrote:
On 2/10/2013 6:04 PM, Magnus Danielson wrote:
You should read "TCP/IP" as "Internet Protocols" (notice plural form
here). It points to the stack of protocols,
Actually, no. IP is Internet Protocol, singular, and is the L3 (mostly -
IP predates the ISO/OSI model layers, so IP suite protocols don't map
exactly) protocol upon which both TCP and UDP are built. It's defined by
RFC 791.
TCP/IP, simply because those are the most commonly used protocols in the
suite.
In the context it was written, it used the well spread misnomer of the
suite to be referred to TCP/IP. The protocol suite was many times
referred to as TCP/IP even if UDP was used for the particular transport
over IP. It is a confusing thing and people have become better at using
the correct terms, so in the context that "NTP used TCP/IP" is means
that NTP uses the Internet Protocol suite, not TCP over IP.
As I recall NTPv3 in RFC 1305, it only specifies UDP over IP.
The ISO/OSI model stuff is a bad fit for the IP-stack, but it got stuck
and fits the reality really bad. It's usage is discouraged.
Cheers,
Magnus
On Wed, Feb 27, 2013 at 7:02 PM, Magnus Danielson
magnus@rubidium.dyndns.org wrote:
On 02/12/2013 08:19 PM, Mike S wrote:
On 2/10/2013 6:04 PM, Magnus Danielson wrote:
You should read "TCP/IP" as "Internet Protocols" (notice plural form
No. The best way to pronouncethe slanted bar is "over".
So you say "TCP over IP"
Notice that we also many times have UDP/IP
If you what to know what al the letters are it is "Transaction Control
Protocol over Internetwork Protocol"
TCP is a way to ensure a packet gets to an end point and in the same
order they were sent. "IP" is a way to move packets. TCP makes use
of I to send packets.
"UDP" is User Datagram Protocol and it also use IP.
In turn IP can run over any number of physical networks like Ethernet,
WiFi X25, or ISDN.
Chris Albertson
Redondo Beach, California
IP can be run on a lot of different platforms.
Check out Request for Comments: 1149
http://www.ietf.org/rfc/rfc1149.txt
Dave
-----Original Message-----
From: time-nuts-bounces@febo.com
[mailto:time-nuts-bounces@febo.com] On Behalf Of Chris Albertson
Sent: Wednesday, February 27, 2013 21:31
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Possibly off topic - Jitter on
Ethernet over poweradapters
On Wed, Feb 27, 2013 at 7:02 PM, Magnus Danielson
magnus@rubidium.dyndns.org wrote:
On 02/12/2013 08:19 PM, Mike S wrote:
On 2/10/2013 6:04 PM, Magnus Danielson wrote:
You should read "TCP/IP" as "Internet Protocols" (notice
plural form
No. The best way to pronouncethe slanted bar is "over".
So you say "TCP over IP"
Notice that we also many times have UDP/IP
If you what to know what al the letters are it is "Transaction Control
Protocol over Internetwork Protocol"
TCP is a way to ensure a packet gets to an end point and in the same
order they were sent. "IP" is a way to move packets. TCP makes use
of I to send packets.
"UDP" is User Datagram Protocol and it also use IP.
In turn IP can run over any number of physical networks like Ethernet,
WiFi X25, or ISDN.
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.
On Wed, Feb 27, 2013 at 9:54 PM, DaveH info@blackmountainforge.com wrote:
IP can be run on a lot of different platforms.
Check out Request for Comments: 1149
Even better, check out the guys who actually implemented RFC1149.
This page has links.
http://www.blug.linux.no/rfc1149/
Chris Albertson
Redondo Beach, California