Hi so I've got my Pi running between my ONT and Router , network all works fine etc except battle net I've checked router logs shows a time sync issue , when setting up the PI I provided a NTP server and I manually even adjusted the time to set . How can I fix this ? I have heard that installing chrony and locking CPU frequency to performance will fix this ?
Is the Pi running OpenWrt? Is it able to connect to the internet and NTP servers correctly? If so, it should perform periodic NTP syncs to correct for drift. Off hand, I'm not sure how often the sync is supposed to happen, but it should be frequent enough that the clock isn't drifting by too much.
Also, how much drift are you talking about?
Please post exact log message and which time server you have installed.
daemon.err cli.lua[4202]: [WARNING]: ct 3eefdbe1: time went backwards!
daemon.err cli.lua[4202]: [WARNING]: ct 3eefdbe1: time went backwards!
daemon.err cli.lua[4202]: [WARNING]: ct 22432032: time went backwards!
Fri Oct 17 2025 18:48:29
daemon.err cli.lua[4202]: [WARNING]: ct a674ddc9: time went backwards!
Fri Oct 17 2025 18:48:15
daemon.info procd: Instance datahistory::instance2 s in a crash loop 6 crashes, 56 seconds since last crash
I haven’t installed any time server , I only provided a NTP server that was my LAN when configuring.
Yes so this is my bridge I am talking about running SQM, its running openwrt , internet is working , on rest of my network .
Drift is very small amount sub ms but my battle net isnt working I suspect due to this its causing small delay not resulting me to be able to connect to the servers etc not sure though
I doubt that time drift is the issue here since it's a bridge.
Does the problem resolve when you actively sync time?
Chrony has much bigger tolerances for bad clocks and broken time servers.
Doesn’t work even when time is synced so I believe there’s a drift issue once SQM shapes traffic it adds a small delay also.
I will try to change CPU frequency to stay on performance as potentially the CPU isn’t working fast enough to shape traffic as on the PI it uses dynamic frequency scaling so if I set to performance mode constantly it should shape traffic at a fast enough rate where I dont see jitter and timestamp issues. Let me start with this lets see how it goes
If that's the case, the problem is not time based.
If you've 'just' sync'd the time, the clock drift will be vanishingly small and will not impact the traffic as it's flowing through. Specifically, the traffic is passing though a bridge. There are no operations that are time based that could impact this traffic. For example, if the clock on your computer (where an SSL/TLS connection might terminate) is off by a large amount, secure connections will fail because the time is an essential part of the encryption methods (this is to prevent "replay" attacks). However, underlying devices -- even routers themselves -- can have clocks that are wildly out of sync and it will still pass the data because they are simply forwarding/routing traffic, not encrypting/decrypting the data streams. And a bridge (i.e. a switch) doesn't need a clock at all.
The problem is not time drift. The problem is that your approach (still) doesn't work properly.
The problem is that your approach (still) doesn't work properly.? What do you mean by this as I've clearly shown my SQM bridge working with results after I was told it wasn’t possible ?
I know entirely it isnt a time issue with the clock I meant CPU being dynamically scaled probably causes the timestamp issues delaying by couple ms that result in anomalies so setting the frequency to constantly run on performance should solve the time delay caused by the CPU . I’ve checked and services like battle net rely on precise timestamps otherwise it wouldn’t work .
Nothing to do with timekeeping, modern CPUs have steady TSC, evn in deep sleep modes.
Question is if chrony manages to stabilize time towards flaky timesources.
Agreed — TSC stability itself isn’t the issue. I’m not referring to timekeeping drift but to CPU frequency scaling affecting real-time packet processing latency this affects timestamps . When the Pi scales down and suddenly has to shape near line-rate traffic, it can introduce slight processing delays before ramping back up.
IF the CPU isn’t running at full speed and traffic spikes,
packets arrives CAKE tries to enqueue them and schedule transmissions at the proper spacing but if the CPU is at a lower frequency, it physically takes longer to classify, enqueue, and dequeue those packets. The queue backs up , and timestamps of when the packet should have left vs. when it actually left drift slightly. Once CPU ramps up and starts processing faster, newer packets may be handled out of expected order relative to their original timestamps I’m trying to address by locking the CPU to performance. Once that’s consistent, timestamp anomalies and jitter should disappear.
I am telling you to replace time server with chronyd which handles such perturbations better.
ntp.org ntpd has less tolerances, but either of 2 shows significantly better timers diagnostics.
This may or may not be the issue or solution, but the RP5 does have a real time clock where the RP4 did not. However, you need to connect a little battery to it for it to keep time between power cycles.
https://www.amazon.com/KODASW-RTCBattery-Include-Battery-Picture/dp/B0CRKQ2MG1
You can make one cheaper. Battery itself is .99 bucks.
I went for speed and convenience. The CR2032 batteries are so common and this little device just sticks to the top of the case and battery replacement is straightforward.