My hex is sending out an ntp packet every 8 seconds despite being synchronized. Anyone else experience no chill in their ntp with this version?

Try changing ntp server.
Most likely it is NOT in sync (hence why it polls so frequently, I think).

What is output for /system ntp client print ?

On my device (also Hex) it looks like this:

Mine looks like this (ntp server is local). I have tried using ntp.org servers that worked on routerOS 6 as well, output looks the same just with servers added in. I'll give yours a shot and see what happens.

[@MikroTik] > /system ntp client print
enabled: yes
mode: unicast
servers:
vrf: main
freq-drift: -10.345 PPM
status: synchronized
synced-server: 192.168.88.1
synced-stratum: 1
system-offset: -3.784 ms
[@MikroTik] >

Here is the output with the servers that are working for you-
[@MikroTik] > /system ntp client print
enabled: yes
mode: unicast
servers: 94.224.67.24,be.pool.ntp.org
vrf: main
freq-drift: -10.345 PPM
status: synchronized
synced-server: 192.168.88.1
synced-stratum: 1
system-offset: -15.118 ms
[@MikroTik] >

I'll keep digging.

pool.ntp.org is a worldwide available ntp service.
Replace "be" with country code of your liking.

servers:
synced-server: 192.168.88.1
synced-stratum: 1

This is extremely suspicious: none of servers are configured, but then 192.168.88.1 is used (ok, could come from DHCP lease). Additionally, to have router running at stratum 1 (i.e. connected directly to reference time source, such as GPS receiver ... with PPS signal ... impossible if router is Mikrotik) is highly improbable. Same (imposter) NTP server is used even if you configure some good NTP servers so that's the problem you have to solve.

So do check DHCP server settings (to verify it's including ntp-server option) and configuration of NTP server on 192.168.88.1 (so that it doesn't present fake high-stratum number when using internal clock as source ... v7 NTP server has settable property local-clock-stratum which should be set to value higher than 5 (real internet NTP servers with decent time stability have stratum values between 1 and 3) and lower than 12 or 13 (15 is maximum possible value but clients will ignore servers with stratum 15) so that it will only be used as backup time source.

N.b., lower NTP stratum numbers mean higher stratum ... it actually represents distance from high accuracy reference clock. GPS receiver (or atomic clock or WWVB or DCF ... receiver) is considered stratum 0 but those don't run NTP servers directly. Machine, connected to one of those receivers using high-precision connection (such as PPS line), running NTP service is then stratum 1. Ntp clients, synchronizing to stratum 1 servers, are stratum 2 as they are two hops away from reference clock. Etc.
Servers that use (low quality) local clock as time source, should be set to low steatum (high stratum number) not to mess with NTP network accuracy. Ideally each NTP client should use 3-5 independent NTP servers as time source to rule out one rogue NTP server. If that's not practical or possible, one has to make absolutely sure that all involved servers are configured correctly.

Another thing: proper[*] NTP clients implement exponential backoff of interval length between queries. Reference implementation is to start with 64 second interval between queries, after time sync is obtained (usually that's after 8 sequential successful timestamp receptions from same server) and frequency drift stabilizes, the interval prolongs by factor of 2 and (after a day or so) reaches interval of 1024 seconds. The min/max values are configurable, could be MT configured min value to 8 seconds (IIRC this is minimum value in reference implementation) ... but if time sync is acquired, the interval should prolong in a few hours.

[*]some gadgets, including ROS v6 without optional ntp package installed, implement SNTP clients, which behave differently. They don't implement interval length backoff, they use same interval. Protocol used to query NTP servers is slightly different. All in all it provides lower accuracy which is most of times enough for local use in low time precision uses (such as log timestamping or time-dependant encryption and authentication schemes) ... it somehow replaces manusl time setting using wrist watch as source. Due to inaccuracy those devices don't offer NTP service to other devices.

Still no matter what ntp servers I use, or how many- I get a packet sent every eight seconds.

I have rules in my firewall that capture them specifically (allow in/out udp port 123) or I would never know this.

Although it is possible I am not remembering this correctly I believe this did not occur in version 6 of routerOS.

For now I will continue to use a local ntp server and that is working fine other than the frequent packets.

Thanks for all the advice guys!


****A netinstall and reconfiguration of routerOS 7.4 seems to have fixed the issue.