Is the link working now?
Yup!
No idea how frame delay works, but run ahead was made toncompensate any input lag that naturally comes with emulators. The main problem is that its setup is complicated and requires frame by frame analysis for each core
There is no 'natural delay that comes with emulators', each and every case is a delay chain that can be explained taking into account the hardware/game that's emulated, then what's used for generating video and the options for sync. The issue with run-ahead isn't that it's not capable but rather that it doesn't mind any of that and is therefore often misused.
It gets much more complicated with arcades emulation where the many game's inherent lag figures aren't known (you won't find a reliable database with measurements, just random statements) and even more so when RetroArch is involved because of its several features other than run-ahead that can each play a part. Compared to Groovy that means many added variables, some people combine run-ahead (or try to) with other features like hard gpu sync, RA's own frame_delay, some even disable all vsync, some use Vulkan, etc etc.
Add to that the general confusion of it's massive pool of users and you know lag reduction with RetroArch works but is a complete black hole of a mess in terms of accuracy, if oomek starts measuring lag in RA then good luck to him taking all that into account.
Features like frame_delay however (at least as its implemented in Groovy) or FreeSync, are better known quantities - and even more so now thanks to oomek's work - that guarantee to not hamper accuracy at the very least (they eliminate lag that's on top of the emulated games, working on things like video sync buffer frames or inputs polling, not the game's inherent/natural delay which remains untouched)
I was under the impression that runahead compensates for input lag that is naturally occuring in the game itself, not the emulator.
As I've worded just up there, it completely depends on the (too-many in RA) settings that have an influence on the matter, run-ahead can either eliminate only the superfluous/eyesore delay, or be pushed further to eliminate the game's legit delay too.
If RA had a 'delay accuracy safeguard' optional program that takes everything into account, its choices for lag reduction wouldn't be so controversial.
Problem is a portion of the RA demographics argues that it's okay to eliminate even the legit delay (some go as far as deny it even exists), I guess that somehow supports the libretro devs into leaving things as they are...