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?
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 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
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.
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.
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.
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.