Here's some data on 4.4.7. I'm running 160Mhz and my crusader server in this case is limited to 1Gb.
These are another few runs still at 160Mhz with the crusader server running on the same AP to which I'm connected (though this is not ideal) so I can push beyond the 1Gb limitation:
Here's some more data on 4.4.7. In these I'm running 80Mhz and my crusader server in this case is limited to 1Gb.
Here are another few runs still at 80Mhz with the crusader server running on the same AP to which I'm connected (though this is not ideal) so I can push beyond the 1Gb limitation:
I didn't find a solution and upgraded to 4.5.22 again.
so which is better 4.4.6 or 4.4.7? btw can't find 4.4.7.
Just add a virtual package named "ip" via apk.
apk add --virtual ip
Then it should work. Busybox has ip built in, so there's no need for the package.
I think for newer builds (snapshots) this workaround won't be needed as autoconf and automake have been fixed.
I wonder if the server pools you're using have false pingers in some of the pools...
For testing - maybe try the google public NTP servers...
IIRC - most of the builds mentioned are running busybox's NTP client, rather than a full NTP client, so it can have challenges...
example below - note also that we disable the DHCP advertised servers...
config timeserver 'ntp'
list server 'time4.google.com'
list server 'time3.google.com'
list server 'time1.google.com'
list server 'time2.google.com'
option use_dhcp '0'
I've already explained.. my issue was not NTP or NTPD related.. it's the clock of the CPU is slowing or slow.. I only used NTP to see how often it had to re-align the clock
See this comment from @quarky - MT6000 custom build with LuCi and some optimization - kernel 6.6.x - #2050 by quarky
Now with the my latest build based on the latest branch next-r4.5.27.rss.mtk from pesa1234.. it seems it's now stable.. but one thing weird is if nothing is connected on the wifi and no usual internet even through the LAN, it happens randomly after 12hrs onwards after boot.. It feels like the Flint 2 has some kind of power saving mode hahahaha
Intalled latest 4.5.27 but im receiving "Segmentation fault" during apk update, please help (the problem is somehow linked with this file "https://raw.githubusercontent.com/pesa1234/MT6000_cust_build/refs/heads/main/2025-02-24_r29270-5f40289754_next-r4.5.27.rss.mtk.5g/targets/mediatek/filogic/packages/packages.adb" which is not available)
If you compile by yourself as I tell you on github it is better to compile and include on the build or compile and install manually.
@Gingernut
No it is not this issue.
It will search for packages online on that link posted by @jagga but it can not find because I have not upload.
same here
Fri Feb 28 17:56:54 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.050124
Fri Feb 28 17:56:59 2025 user.notice ntpd: Stratum change, stratum=2 interval=32 offset=0.048659
If you are not being flooded with that then it's normal. But if it's happening like a lot in a span of few minutes then it's a clock issue.
What build are you using?
I only had the issue with one build on a specific branch. But of course I don't test or try every branch that comes out from pesa1234.
On the latest r4.5.27.rss.mtk the clock is stable. And it's so stable that I haven't seen even a single NTP clock alignment for more than 24hrs hahaha.
But one thing weird, I tested the build without actually using the router but just monitoring the logs (not even accessing luci). And after more than 12hrs I get those in a span of few mins (like 3-5 times every minute, and goes on for 3-5mins) then stops. The interval between this types of events are random but when they start it happens for a couple of mins. But once you use the router even just opening up logging into luci, those ntp clock re-alignment stops for a couple of hours hahahaha
I tested the above scenario twice, and it's the same both test run.
NTP stratum changes are not unusual when working with pools... and in your log snippets, the offsets aren't unexpected...
I acknowledge that you're seeing some kind of clock drift, and what you're seeing is odd enough - esp since changing SW seems to have cleared the problem. It might be a bug with pesa's builds perhaps, but still it's pretty odd that time would drift that much if what you have observed is consistent.
Who knows - maybe you have a device that is slightly out of calibration... most platforms have a calibration routine at the factory, as every crystal, TCXO, etc, they all have some small variance +/- the specified frequency - we calibrate the offsets so that things like wifi timing, etc, are within spec - normally parts per million over time...
I'm doing my own builds cloned from pesa1234 branches with very minor changes to some packages that I use. Might be that pesa hasn't finished pulling changes from openwrt main when I pulled from his branch (forgot which branch) because after a re-pull from the said branch a day or two after, the next build didn't have such issue.
Right now clock is so stable that it's been 48hrs since last restart and I only seen the NTP stratum logs on boot and like 1 or 2 times since then hahahaha. I also do manual checking via ssh the routers date and time and it's still aligned.
Just note that the stratum level changes are upstream, not local... red herring, IMHO
If you're seeing drift, NTP is responding to it...
Working directly off master here - pesa's fork is a bit of a silo, and perhaps out of sync both upstream and not...
Hello,Reverted to master couple of weeks ago and want to know what's the status of the project @pesa1234 @_FailSafe .. Seems everything went silent.
updated 13h ago
I don't know if you can do an upgrade? next-r4.5.28.rss.mtk