I find it very unlikely this will be shown to be better than existing RNG solutions.
It's clever, but clever in the way that sleep sort is clever, at least until proven to be of actual benefit.
Suppose this is running on a quiescent system with no interrupts or other tasks running. I can see it degenerating into deterministic behavior. Suppose the RTC counter and the CPU clock are from the same master clock, and the code is executing cleanly to the clock from on-chip caches.
Ultimately, the question is: is there really one bit of entropy from each call to get_bit(), and under what conditions?
I dunno Keccak, so I'll talk from a Skein perspective. If every millisecond you added the "nanoseconds" field with the Skein cryptofunction salt = mix(nanoseconds + salt + current seed + other Skein stuff), it'd be pretty darn random. (Apparently Keccak can 'sponge up' entropy somehow, but I don't know the mechanism that it does it with)
The output would at least be a crypto-secure PRNG. All that needs to be proven after that fact is whether or not enough entropy was being gathered from the real time clock.
The author really needs to cut back the grandiose claims. Projects like this are more part of the learning process, than something useful to others.