Elindítottam az ntpclient mellett az ntpserver daemont. Azóta mintha jó lenne, végre van drift fájl is. De akkor mire jó az ntpclient? Erről sehol nem találtam infót.

Az az LFS.

Ebben a topicban 3 ember is gentoozik valamilyen szinten.

Jó, de az nem disztribúció.

Akkor rajtam kívül van kettő. YAY, alapítsunk pártot!

Remélem most magadat nem számoltad bele, mr. Macmester

Ki a többi amúgy? Vagy ebbe bele van számolva a PH is? Mert szervereken is ugye gentoo fut.

Az ntpclient nem tudom, hogy mit takar*, de az, hogy megjelent a drift fájl, határozott pozitívum, mert az azt jelenti, hogy a háttérben folyamatosan fut már az ntpd folyamata, és ebbe a fájlba rögzíti a szerver órájának csúszását a beállított NTP szerverekhez képest (talán egyértelműbb lenne jitternek nevezni), amely adatok alapján később magától is tud majd korrigálni.

A minél pontosabb idő kulcsa olyan NTP szerverek használata időszinkronizálásra, amelyeknél a stratum a lehető legalacsonyabb (stratum 2 az elvi minimum forrásra NTP-nél, hacsak nincsen kéznél egy atomóra), ennek érdekében érdemes forrásként több UTC(k) szervert beállítani, innen válassz ki pár európai szervert, ezek mindegyike egy folyamatosan monitorozott pontosságú hardveres forrásra (annál a párnál, amit megnéztem, ott éppen céziumos atomóra volt) épít.

* az ntp.org platformfüggetlen referenciaimplementációját ismerem csak működés közben (és azt is csak Windows alatt), ott ilyen nevű segédprogram nem létezik, ntpq, ntpdate és ntpdc ellenben igen idő helyi/távoli lekérdezésére/beállítására

Te, a Gyula, meg az Ottó, a Tóth Ottó...

Gentoo-n van külön ntp-client és ntpd service. Már minden szart megnéztem, de ezek szerint az ntp-client elindítása nem elég, pedig ugye logika szerint ugye én csak kliensként akarom működtetni, nem kell a szerver funkció, hogy másokat kiszolgáljon. Drift fájl nekem is tök fura volt, hogy nincs.

Többi infót köszi.

Egy "alapos" NTP kliens és szerver között csak annyi a különbség, hogy az utóbbi figyel a 123-as TCP és UDP porton is, maga az időszinkronizálás megegyezik, ebbe olyasmi tartozik bele, mint
* több beállított NTP forrásszerverrel való rendszeres kommunikáció (pár másodpercenként)
* a hibásnak tűnő (többiektől nagy eltérést mutató) forrás átmeneti kizárása a pontos idő meghatározásából
* a belső óra pontosságának monitorozása, az óra frekvenciahibáinak rögzítése drift fájlba
* a fentiek (kapott idő, drift fájl) alapján a rendszeróra rendszeres tekergetése, vagy ha az OS lehetőséget ad rá megfelelő kernel API formájában (a Linux és Windows igen), akkor a rendszeróra ritkán történő tekergetése, mellette az API-n keresztül az óra pontosságáról rendszeresen információ szolgáltatása a kernel számára, ami az alkalmazások számára már az eltéréssel korrigált pontos időt adja vissza.

Ez egy eléggé egyszerű kliens, egyetlen forrásszervert támogat, az óra pontosságát nem ellenőrzi, időnként lekérdezi a szervert, és amit kap azt vakon elhiszi és beállítja (legalább támogatja a kernel API-s finomhangolást). Nem tudom, nézted-e a naplóit, hogy sikeres volt.-e a lekérdezés/óra beállítása (nem túl sok ellenőrzés van a kódban), milyen NTP forrásszervert használtál és milyen gyakorisággal ment a lekérdezés.

A másik csomag mögött az NTP referenciaimplementáció van, szóval bár a beállított NTP forrásokat még átnézném a helyedben, mostantól kezdve valószínűleg nem lesz probléma a PH órájával.

Ha van 1-2 óra elégetésre szánt időd, akkor itt van egy rövid leírás az NTP működéséről (bár tartalmaz elavult információt, mint például a Windows támogatottságról, ami ma már teljesnek nevezhető).

Nem azt a kis fos klienst használom, hanem a rendes ntp csomagot. Az idő azért mászik el, mert virtuálizálva vannak a gépek. Amúgy ismerem az ntp-t, tudom hogy működik. Csak a service név megtévesztő, mert kiderült az ntpclient csak egy kis semmiség ami egy ntp_date parancsot hív a konfigurációban megadott paraméterekkel, s ennyi. Rá kellett volna néznem erre korábban, nem bízni a "client" szóban. Vagy legalább próbálkozni, hátha az ntpd csodát művel-e.

[ Szerkesztve ]