This is not a contact point of the official Mikrotik support, this is a forum of fellow users, so there is no guarantee that anyone will ever
reply, especially for an issue like this which requires on-site runtime analysis, not just an answer to a "how do I set up xxx" question or analysis of a static configuration to find a mistake.
What you write sounds like some kind of issue with MTU and jumbo frames - a 64000 byte ping must be sliced into multiple Ethernet frames, so fragmented on IP level, even if jumbo frames are supported on all devices on the path. But there can be also other causes to it. So starting from the simplest things,
- check whether /interface ethernet print stats on the CCR shows no errors,
- use /tool profile on the CCR to see whether it's not glowing red under the load (so dropping packets and thus getting even more of them as the TCP sessions retransmit lost packets),
- use /tool sniffer on the client-facing and server-facing physical interfaces of the CCR to sniff into a file while doing the ping test, and then download the file and use Wireshark to see where the issue comes from - lost fragments, late arp response somewhere (so the first ping doesn't get through within the wait-for-response timeout) etc.
Don't believe what packet capturing done on the client or server machines tells you - the network card drivers do a lot of work between the wire and the capturing API, so they may show you 64-kbyte ethernet frames which do not actually exist.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.