I suggest to deploy Chrony NTP Server on Mikrotik RouterOS. right now, it has NTP Server, but it not base on chrony.
What device are you using, a new one you can build it in a container.
no, in Mikrotik routerboard such as RB450G or any such.
NTP is NTP... lol why want to change it to chrony on mkt device ?
ntpd is pretty much the standard . . . not sure why anyone would want anything else, esp. on a *nix based device where it has been native for decades.
???
Maybe someone has insight into how Chrony runs, so they can inject bad code. 
Can't find any new CVE.
SPAM, by any other name.
RouterOS does not allow installation of arbitrary packages. When you want that, install OpenWRT.
What that change would solve?
Better DNS service would be much more needed.
I agree. If the device delivers the result through the right protocol, then that is more or less as good as it gets. The only issue is if chrony is easier to set up or manage. But no case has been made for that, so for me, the Mikrotik default is adequate.
chrony has many options to control. also, in a network, some devices (ESXi Host or something) has problem to sync time with NTP-Server (build-in) but it does not had problem with Linux + chrony NTP Server.
I've never heard or used Chrony, but anyone can google the differences of chrony vs classic ntpd. So I don't understand the bashing.
You should consider an NTP function in a router to be for basic time synchronization. It will normally work OK when everything is properly configured. When you have an issue with some particular client you can try to do a packet capture (and probably supout file) and send it to support. There sometimes are picky clients that check certain fields closely and they may be unacceptable values in some server.
In our ESXi servers (we have abandoned it now and switched to Proxmox) there never was a sync issue.
One (probably major) problem with "full featured" services is that they require quite a lot of storage space (compared to trimmed-down versions shipped with ROS). E.g. chrony package for debian 13 for arm64 architecture is 760kB (installed size) ... and probably depends on quite a few system libraries. Those 0.75MB might seem tiny on normal computers (desktops and servers), but it's relatively huge for some (or rather: many) MT devices with storage sizes of 16MB.
And then there are considerations about particular service (NTP) on MT hardware: they don't have RTC built in which means they need external source to even get clock approximately right ... which can take a few tens of seconds after reboot (yes, that might be a non-issue since routers are meant to run 24/7 anyway). Which IMO makes MT routers unsuitable to provide serious NTP sync service.
And my personal opinion is that if one needs some service on "professional level", then it's worth to run it on "professional grade" hardware/OS. You're mentioning ESXi hosts ... what's stopping you from spinning up a VM, dedicated to running chrony (which can then provide precise timing to physical host as well, nothing is stopping you from configuring NTP client on ESXi to connect to VM running on same hardware), just remember to disable "time synchronization with host" on that particular VM.
Yes, when you have strict requirements it could be a better idea to buy an NTP appliance.
Unfortunately it seems that some of the cheap ones (Ubiquiti, Chinese) are rubbish. I have good experience with the LeoNTP.
Second this. Time sync is one of those pesky things that can cause a lot of problems. It's well worth buying a proper time appliance.
For various reasons, running an ntp service on a vm for any serious purpose is ill advised.
Just for additional fun: it's very easy to build a circular dependency, where e.g. your esxi doesn't consider itself properly initialized until it's clock is synced so won't start vms, including the one that would run Chrony...
In all my years using CHR on ESX, I've never had issues with NTP time syncing. Not on Linux VMs, not on Windows VMs, not on CHR VMs.
It is wrong to rely on single source for NTP for various reasons (temporary unavailability of some soervers is one of them). So ideally, in a professional setup with number of devices exceeding only a few, one would run a few internal NTP servers, all on different hardware, synced to multiple NTP sources (a NTP receiver can be one of them, but not the only one). Yes, MT router might be one of those many internal NTP servers ... but as already established ROS makes a poor NTP server (along to being poor server for many other services, such as DNS, RP, proxy and others).
Proper NTP appliances are quite expensive, but if you don't mind some hardware hacking, it is possible to roll your own from a low power Linux box with GPS receiver. One example - https://blog.dan.drown.org/apu2-ntp-server-2/ - this one (using chrony) has very good timing accuracy as it makes use of the Intel NIC with hardware timestamping of the 1PPS signal. I've also seen some i210AT based PCIe cards where the SDP pins are conveniently available on a pin header, so no soldering of fine wires required. Another option is to use a Raspberry PI, preferably 4 or 5 is these have proper non-USB gigabit ethernet. Though it would be nice if a future routerboard had proper 1PPS hardware support, or perhaps some already do but not yet used by RouterOS?