pontos óra a PC-n

A hwclock csak szoftveresen tud tenni valamit, a hw az olyan, amilyen:

The Adjust Function
      The Hardware Clock is usually not very accurate. However, much of its inaccuracy is completely predictable - it gains or loses the same amount of time every day. This is called systematic drift. hwclock's --adjust function lets you apply
      systematic drift corrections to the Hardware Clock.

      It works like this: hwclock keeps a file, /etc/adjtime, that keeps some historical information. This is called the adjtime file.

      Suppose you start with no adjtime file. You issue a hwclock --set command to set the Hardware Clock to the true current time. hwclock creates the adjtime file and records in it the current time as the last time the clock was calibrated. Five
      days later, the clock has gained 10 seconds, so you issue a hwclock --set --update-drift command to set it back 10 seconds. hwclock updates the adjtime file to show the current time as the last time the clock was calibrated, and records 2
      seconds per day as the systematic drift rate. 24 hours go by, and then you issue a hwclock --adjust command. hwclock consults the adjtime file and sees that the clock gains 2 seconds per day when left alone and that it has been left alone for
      exactly one day. So it subtracts 2 seconds from the Hardware Clock. It then records the current time as the last time the clock was adjusted. Another 24 hours go by and you issue another hwclock --adjust. hwclock does the same thing: subtracts 2
      seconds and updates the adjtime file with the current time as the last time the clock was adjusted.

      When you use the --update-drift option with --set or --systohc, the systematic drift rate is (re)calculated by comparing the fully drift corrected current Hardware Clock time with the new set time, from that it derives the 24 hour drift rate
      based on the last calibrated timestamp from the adjtime file. This updated drift factor is then saved in /etc/adjtime.

      A small amount of error creeps in when the Hardware Clock is set, so --adjust refrains from making any adjustment that is less than 1 second. Later on, when you request an adjustment again, the accumulated drift will be more than 1 second and
      --adjust will make the adjustment including any fractional amount.

      hwclock --hctosys also uses the adjtime file data to compensate the value read from the Hardware Clock before using it to set the System Clock. It does not share the 1 second limitation of --adjust, and will correct sub-second drift values
      immediately. It does not change the Hardware Clock time nor the adjtime file. This may eliminate the need to use --adjust, unless something else on the system needs the Hardware Clock to be compensated.

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...

NTP daemont többfajta forrásból etetheted, nem csak netről (régen pl. GPS-t használtak ilyenre, aivel én találkoztam), a lényeg az, hogy folyamatosan állítva van szoftveresen, nem pedig egy pillanatban betolod, hogy date ez meg az és ennyi.

Ez az implementáció beírja az időjelet az RTC-be, a PPS jellel szinkronizálva, de onnan ki is kell olvasni a kijelzéshez, ami némi késést okoz. Amúgy nem tudom, hogy működik a GPS, de a rádióhullámok terjedési sebessége 300000 km/s, más szóval 300 m/us. Vagyis ha felmegyek a Gellérthegyre, akkor 1 us-mal kevesebbet fog mutatni a GPS órám, vagy hogy van ez?