Monitors aren't bad, just report strange....so people get the wrong idea...my opinion

See for yourself…NTPman…

I changed from RaspberryPi (was running for 24 hours!! and tested more)…to less then 1 hour of Intel.
Then changed back to RPi.

See the Jojo starting instantly? And I took the Beta-server as it has 3 monitors, they all agree.

How much more proof does anybody needs that Intel CPU’s are causing this.
I do not know what series or all the affected ones.
But it’s a lot.

Dear @Bas,

That is one server, with two IP addresses. An IPv4, the other IPv6. I do not comment, I let you draw the conclusion.

image
image

My public page is: https://www.ntppool.org/a/vm9onk3s5v9mcxq5dc4

1 Like

Hi NTPman,

Was expecting you. Yes.
I was running IPv6 for a while too, and IPv6 was the same as you show, stable as could be.

And I know the reason for that, it’s because all IPv6 systems stamp time on a packet when it passes, IPv4 does not.
So if your did send the package with the wrong-timestamp, it doesn’t matter, it’s stamped multiple-times.

IPv4 and IPv6 do not timestamp UDP-packages the same way.
That is why IPv6 works better even when your IPv4 is messed up.

It’s hard to explain and also where it goes wrong on IPv4, but IPv4 packages are not stamped again since they left your system. IPv6 is.

Replace your system with an RaspberryPi2/3/4, see what happens…wanna bet it’s good also on IPv4?

That is already a progress. So you do not claim any more that IPv4 reply packets are not sent, just timestamped differently than IPv6. Good start to approach our opinion. I would like to know some details where is that difference in timestamping? In the UPD user data, or the difference is in the IP header?

Just look, I went back to Intel for 1 hour:

https://web.beta.grundclock.com/scores/77.109.90.72

1 hour

I do claim if time is off it will not be send, but if it’s good and the checksum is wrong it will still give the same result.
But IPv6 gives a new/corrected checksum every time it’s forwarded.
As IPv6 stamps multiple times, IPv4 does not.

It relies on the stamp given by the OS, to determine the Jitter and Offset…
In any case if the checksum is wrong the package never reaches the destination, where IPv6 corrects it and delivers.

What CPU are you using? Family and type please…as there are plenty people complaining about it.
My bad Intel is Fam6 model 60.

I have Xeon X5550 stepping 05.

From what I see…

Family:6 Model26

So try an RPi as NTP-server, then prove me wrong.

I can change between RPi and Intel all day long, with same result 24/7…Intel goes Jojo on IPv4.

Changed Kernels, changed NTP/Chrony, Changed GPS (6 times!)…what ever I do, the Intel goes bad.

I was almost right, it’s not the timestamp but the checksum the NTP-package gets.
That goes wrong on my Intel and underway the package gets dropped because of that.
IPv6 corrects the invalid checksum.

That is why you see IPv6 a solid 20 and IPv4 goes nuts.

The IPv4 checksum is generated at sending time and can’t be corrected.
IPv6 is corrected along the way.

This causes the drops of UDP packages in v4.

But why are invalid checksums inserted? It happens on my Intel but not on the RPi2.

It is not the internet that filters on ntp-packages, it happens on all UDP with invalid checksums.
Most never notice but we time-freaks do :slight_smile:

Hi,

I have the same issue on a RPi3 on IPv4, when i had IPv6 (my current ISP doesnt offer it) I had a line that stayed at 20.

Thanks Dan.

I’m going to wait another couple of hours to see if my fixes work.
I’m at a solid 20 at the beta-server and 19.8 at the main server…with the Intel i5 with GPS but no PPS.

I have not seen any Time-out. The last orange dots are because of the off-set being set wrong for this GPS, those at 9am in the morning.

It runs Time-out free ever since!!

Bas.

you very likely have a screwed up timeserver, that part seems clear. almost everything else you’ve written is speculative, unfounded, and frankly nonsense. the conclusion that your messed up machine proves that everyone else’s problems are somehow related to yours is not warranted.

5 Likes

You seem to have no clue about how UDP or NTP works.

Nor did you read any of my previous posts.

The beta-system, does prove me right all the time, and it does prove 1 monitor (Newark) to be wrong all the time.

Funny is that it’s mostly the LA monitor.

Yes that is clear as I stated as such.

So what are your suggestions to make it better? To comment is one thing, to do something is another.

Please advise.

You seem to have no clue about how UDP or NTP works.
Nor did you read any of my previous posts.

No, I read them. That’s how I got the impression that you knew just enough to be dangerous and potentially send people on wild goose chases when they read the archives in a couple of years.

So what are your suggestions to make it better? To comment is one thing, to do something is another.

My suggestion is for you to stop making sweeping assertions that everyone else is wrong and you’ve single-handedly figured out what’s causing everyone else’s problems based on a ridiculously small number of data points and limited insight into the overall system.

3 Likes

Additional information:
I made supplementary packet capture on a tapping port at the very edge of our network, beyond routers and security devices. (Unlike before, direct tcpdump inside the NTP server.) Even when the Newark production monitoring reports time-out, related to that precise monitoring moment, it is still possible to see the associated NTP reply packets leaving our network and entering directly the ISP’s edge router toward the monitoring station.

3 Likes

You are so full of yourself…again not providing any helpful data.

At least I try to make suggestions and hope it gets fixed.

You sir are nothing more then a troll, just to stir things up.

Again…where are your suggestions to make things better? You do not answer anything but put more oil on the fire.

Well done @ntppool

A good read to stop getting this discussion out of hand:

2 Likes