Igen, lehet úgy is csinálni, amire a man hwclock utal: az RTC-t nem piszkálva hagyni úgy ahogy van, és a rendszer indításakor kiszámolni, hogy eltelt 2 nap, akkor kb 8 másodpercet kell kompenzálni.
A hőmérséklet a szobában állandó, de nem a gépházban! Ott amikor bekapcsolod a gépet emelkedik a hőmérésklet, az tuti. Az is lehetséges, hogy az RTC-nek van egy nem kiszámítható driftje is a hőmérsékletin felül. Ez is lehet simán a 4 másodperc nagyságrendben. Ugye ezek a konkrét alkatrészek adatlapjai alapján volnának elérhető adatok, meg ismerni kellene persze az áramkört is. És mivel senkit nem érdekel ez manapság, ezért egy konzumer cuccban ez mind ismeretlen specifikáció szerint működik.
Szerintem ezen a szinten mindannyiunk tapasztalati tudását túlszárnyaltad, és nem fogsz konkrét tapasztalaton alapuló választ kapni (majd valaki jön és kijavít, ha mégis). Szerintem élesben mindenki NTP-t használ. Esetleg lehet még GPS alapú órát is használni, ha valakinek nagyon pontos óra kell Internet hálózattól offline megvalósítva.
A helyedben - ha tényleg nem akarod feladni - megnézném ezeknek az eszközöknek meg a Kernelnek a forrását, hogy mit és miért csinál. Az a baj, hogy a tesztelés rendkívül időigényes, minden próbálkozás egy teljes napot igényel, vagy legalább annyi időt, amin már mérhető elmászás van. Ráadásul nem tudhatod, hogy a szerencsén múlt-e az eredmény? Ki kellene loggolni a nyers értékeket, hozzájuk kellene rendelni a "valódi" pontos időt, stb. Komoly munka egy ilyen alrendszert debuggolni. Talán QEMU-ban lehetne gyorsabban haladni, ha ott van kapcsoló arra, hogy az órát eltekergesd a host órához képest. Azzal lehetne pikk-pakk szimulálni újraindítást 1 nappal később elmászott órával. Csak ott meg nem lehetsz biztos benne, hogy ugyanaz a driver van alatta...