Hi
On most “normal” home connections to the internet, your trip
time “up” to something will be much longer than your trip time
“back” from the same destination. Part of this is simply a reflection
of download speed being much better than upload speed. However
as noted in other posts, there is a
In modern IP/MPLS routing, forward and backward paths is indivudally
routed and becomes re-routed do spread traffic load or overcome loss of
links. Analyzing it makes much more sense in this form. You can draw the
same conclusion from the wedge-plot of TE vs RTT, but it may be less
clear, so
Good idea. Doing so reveals the expected outcome from the wedge plot:
variable forward path delay, shifted in the positive direction, and a
pretty stable negative path delay. Is this the norm for consumer grade
connection? It seems to be for me.
On Wed, Dec 15, 2021 at 10:53 AM Magnus Danielson
Hi
One really big thing that has changed is the number of folks doing this
sort of thing via a dsl or cable modem that has > 20 ms of asymmetry.
You will not find many NTP papers studying that sort of network connection.
Bob
> On Dec 15, 2021, at 11:30 AM, Lux, Jim wrote:
>
> On 12/15/21
On 12/15/21 7:53 AM, Magnus Danielson via time-nuts wrote:
Hi,
Expect network routes to be more dispersed these days, as it is needed.
While the wedge plot is a classic for NTP, it may be interesting to
plot forward and backward path histograms independently.
Cheers,
Magnus
I assume
On 12/15/21 7:53 AM, Magnus Danielson via time-nuts wrote:
Hi,
Expect network routes to be more dispersed these days, as it is needed.
While the wedge plot is a classic for NTP, it may be interesting to
plot forward and backward path histograms independently.
Cheers,
Magnus
I assume
Hi,
Expect network routes to be more dispersed these days, as it is needed.
While the wedge plot is a classic for NTP, it may be interesting to plot
forward and backward path histograms independently.
Cheers,
Magnus
On 2021-12-15 16:25, Adam Space wrote:
Yeah I think it is localized.
Yeah I think it is localized. Network paths have been quite variable for
me. Every once in a while I start getting massive delays from the NIST
servers to my system, resulting in results like yours.
Interestingly though, time-e-g was one of the only servers that didn't have
this problem for me.
> The hardware are done by the network PHY and need 1588 support in the
driver, which is not common.
PTP HW timestamping is thankfully a bit more common than NTP one. From
which you can deduce that it's unlikely you'll get HW timestamping in NTP
context.
However, new Chrony has support for
> results are awful for time-e-g.nist.gov
That box is busted/sick. The IPv6 address is horrible.
If you want to discuss reasonably-normal operations, pick another system.
--
Nothing is ever totally useless.
It can always serve as a bad example.
--
These are my opinions. I hate spam.
On Tue, Dec 14, 2021 at 2:21 PM Hal Murray wrote:
>
> > I've seen cards (ethtool) that support several time options - what are they
> > and how do I use them?
>
> I'm not sure which options you are referring to.
Probably the flags from ethtool -T output:
Time stamping parameters for eth0:
On 12/14/21 5:23 PM, Hal Murray wrote:
Out of curiosity, since you monitor NIST Gaithersburg, if you were to average
over the offsets for a whole month, what kind of value would you get? Surely
it is close to zero but I am curious how close. Within 1ms?
It depends. Mostly on the routing
> Out of curiosity, since you monitor NIST Gaithersburg, if you were to average
> over the offsets for a whole month, what kind of value would you get? Surely
> it is close to zero but I am curious how close. Within 1ms?
It depends. Mostly on the routing between you and NIST. If you are
> Is it ALWAYS there?
No. You have to ask for it with setsockopt.
> Also cmsg doesn't make it clear what these auxiliary headers might actually
> be, so that doesn't really leave me able to use this?
The type of the cmsg block will be the same as the option you turned on with
setsockopt.
If
Hi,
On 2021-12-14 17:26, Steven Sommars wrote:
The Gaithersburg servers are accurate. This plot shows Gaithersburg
time-e-g.nist.gov for the current month.
[image: image.png]
My monitoring client is located near Chicago and is Stratum-1 GPS sync'd.
Typical round-trip time to Gaithersburg is
Okay so "man cmsg"
I've seen cards (ethtool) that support several time options - what are
they and how do I use them?
Also cmsg doesn't make it clear what these auxiliary headers might
actually be, so that doesn't really leave me able to use this?
Is it ALWAYS there? What about receive
a...@unifiedmathematics.com said:
> I've seen SO_TIMESTAMP and friends in ethtool but I have no idea what it is
> or how it works, can you point me in the right direction please?
man 7 socket on a Linux box. Then man recvmsg and man cmsg
There are several variations on various OSes.
The
Hi
If you are on something like a cable modem (or similar), your network delays
will not average out to zero over any period of time. Sorting out delays on
“your end” from “their end” can be difficult.
Bob
> On Dec 14, 2021, at 12:56 PM, Adam Space wrote:
>
> Thanks for your response and for
I've seen SO_TIMESTAMP and friends in ethtool but I have no idea what it
is or how it works, can you point me in the right direction please?
Alec
---
On 2021-12-14 18:12, Steven Sommars wrote:
On Tue, Dec 14, 2021 at 11:40 AM Michael Rothwell
wrote:
I see some high offsets on my local
Thanks for your response and for your paper link. It is very interesting: I
enjoyed looking it over and learned a lot. And you are definitely right, it
is surely asymmetric network delay that is causing this problem.
Out of curiosity, since you monitor NIST Gaithersburg, if you were to
average
On Tue, Dec 14, 2021 at 11:40 AM Michael Rothwell
wrote:
> I see some high offsets on my local monitoring (synced to time.google.com
> ).
> Especially time-e-b on ipv6.
>
This observation is correct and is caused by queuing delay on the NIST
server. NIST NTP mode 3 requests
are apparently
The Gaithersburg servers are accurate. This plot shows Gaithersburg
time-e-g.nist.gov for the current month.
[image: image.png]
My monitoring client is located near Chicago and is Stratum-1 GPS sync'd.
Typical round-trip time to Gaithersburg is ~27 msec.
On 2021-12-07 a few monitoring polls saw
Hi,
On 2021-12-14 02:26, Adam Space wrote:
I'm not sure if anyone else uses the NIST's NTP servers, but I've noticed
that the offsets I'm getting from Gaithersburg servers seem to be
really far off, like 40-50 ms off. This is pretty odd since they usually
have a 2 - 3 ms accuracy at worst.
It
--
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane
On Tue, Dec 14, 2021 at 5:41 PM Adam Space wrote:
> I'm not sure if anyone else uses the NIST's NTP servers, but I've noticed
> that the offsets I'm getting from Gaithersburg servers seem to be
> really far off, like 40-50 ms
24 matches
Mail list logo
