Dotaz: NTP

[mmmnovak]

Dobrý den,

mám dotaz ohledně NTP v Debianu 64bit (nebo v Linuxu obecně).

Pokud nastavím synchronizaci času pomocí NTP v Debianu s nějakým časovým serverem, pak by se mi měl můj čas v Linuxu stále zpřesňovat a měl by se "udržovat přesný".

Nikde jsem ale nenašel, jak často dochází ke kontrole (protože většinou píší že se stále synchronizuje) a jaký datový přenos to zhruba za 1 měsíc je ...

Díky moc za odpověď.

Odpovědi

[fakenickname]

V konfiguráku ani manpage jsem nic nenašel tak jsem to alespoň zkusil změřit. Requesty (& odpovědi) byly posílány po cca desetiminutových intervalech. Poprvé 16:44, podruhé 16:53, potřetí 17:10. Odpovědi byly obdrženy po několika milisekundách. Variabilní čas requestů si vysvětluji (těžce IMHO) interním výpočtem potřeby srovnání na základě posledního rozdílu (častosti rozdílů?, rychlost tvorby rozdílů?). Každopádně velikost dat od klienta je 56 bajtů, od serveru taktéž. Dejme tomu, že se klient průměrně ptá každých deset minut což dává 144 žádostí děnně (tedy pokud bereme, že počítač stále běží. U stolního počítače nebo notebooku bych počítal tak 10h denně, tj 60 requestů). Násobek 144 × 56 bajtů dává cca 8kB upload a 8kB download, tedy 16kB denní traffic na časové srovnávání. Pokud budeme však brát velikost celého packetu (což dává větší smysl), pak mluvíme o 90 bajtech, tedy cca 13kB (12960B). Pro měsíc je to pak 30 × 13kB, tedy 390kB download, 390kB upload, tedy celý trafic za měsíc 780kB. No tak dejme tomu, že mít puštěné ntpd na trvale běžícím počítači znamená něco mezi 500kB až 2MB síťový trafic za měsíc.

[rastos]

nastavím synchronizaci času pomocí NTP v Debianu s nějakým časovým serverem

Ak to znamená, že sa spustí NTP démon, tak synchronizácia by sa mala odohrať každých 64-1024 sekúnd. Vychádzam z minpoll a maxpoll nastavení v /etc/ntp.conf. Pokiaľ máš aspoň 33.6 kbs, tak to množstvo dát nerieš.

[fakenickname]

No jestliže je 64 sekund minimum tak potom pesimistická analýza je ( ( 24 * 60 * 60 ) / 64 ) * 90 * 2 * 30 = 7 290 000 B. Ještě by se dalo započítat ztrátovost packetů. Dejme tomu, že se ztratí každý druhý (něco jako když jste na eduroam síti), takže ( ( 24 * 60 * 60 ) / 64 ) * 90 * 3 * 30 = 10 935 000 B (uh, tenhle výpočet prosím nikdo nekontrolujte radši ). Takže i v extrémně pesimistickém případě nejakých 10MB za měsíc je celkem pohoda.

[fakenickname]

Btw, ted jsem měl jeden request po 17ti minutách (cca 1024 vteřin), tedy po maximu. Reálné vytížení je asi hodně nížší než to co sem před chvilkou počítal.

[mmmnovak]

Díky za pomoc, vypadá to tedy dobře, 10MB v nejhorším případě to by se mělo snést.

Ještě jednou díky.

[cronin]

Mozno si vziat kladivo; potom kazdy problem vyzera ako klinec.

[root][~][19:27:36] crontab -l | grep ntp
*/10 * * * * /usr/sbin/ntpdate -s ntp.karpo.cz

[fakenickname]

vaše logy musí být slast pro časoprostorové cestovatele..

[Jakub Lucký]

Stačí vyhodit Crona ze syslogu ;)

[mmmnovak]

a jak se vyhodí, aby Cron nezapisoval ty nesmysly do syslog?

proč to vůbec ten cron zapisuje? je to vůbec k něčemu?

díky.

[Jakub Lucký]

Cron, jako slušně vychovaný unixový démon, informuje svého správce o všem co dělá... Tedy i o všech věcech, které spustí a pokud spouštíte crona co 10 minut, pak budou logicky logy plné jen hlášek:

Cron: spustil tento příkaz

Lze to vypnout, ale záleží na vaší distribuci a použitém syslog systému, v Debianu jde o /etc/syslog.conf

[Jendа]

dum8d0g IMHO myslel, že ntp démon neseřizuje čas skokově, ale snaží se hodiny plynule zpomalovat. S ntpdate by se mohlo stát toto:

Jan  3 11:20:29 paranoid acpid: client connected from 13855[0:0]
Jan  3 13:17:01 paranoid ntpdate[23382]: adjust time server yakumo.nat offset -55.388892 sec
Jan  3 13:16:25 paranoid hald: unmounted /dev/sda1 from '/media/disk' on behalf of uid 1000

[mmmnovak]

aha, tak to jsem nepochopil ...

jinak právě kvůli této funkci ( že hodiny se postupně přibližují, nikoli skokově ke správnému času ) miluju NTP ... je to skvělá věc ... ve windows by asi toto nešlo udělat ... nevíte?

[cronin]

Z manualu ntpdate(8) pod FreeBSD 6.4:

     -B      Force the time to always be slewed using the adjtime(2) system
             call, even if the measured offset is greater than +-128 ms.  The
             default is to step the time using settimeofday(2) if the offset
             is greater than +-128 ms.  Note that, if the offset is much
             greater than +-128 ms in this case, it can take a long time
             (hours) to slew the clock to the correct value.  During this
             time, the host should not be used to synchronize clients.

     -b      Force the time to be stepped using the settimeofday(2) system
             call, rather than slewed (default) using the adjtime(2) system
             call.  This option should be used when called from a startup file
             at boot time.

Takze, ak sa ten ntpdate cronom spusta dost casto na to, aby odchylka nebola vacsia ako 128ms, ziadne casopriestorove skoky sa nekonaju. U mna je pri desatminutovom intervale synchronizacie odchylka 12 az 15 milisekund.

[Jendа]

No jo, když nevypínáš. Mě to přes noc (s2disk) udělá 0,5 sekundy.

[cronin]

A vtedy prvy update urobi skok ... by design:

     -b      Force the time to be stepped using the settimeofday(2) system
             call, rather than slewed (default) using the adjtime(2) system
             call.  This option should be used when called from a startup file
             at boot time.

Staci ho spustit hned pri boote, necakat na prve spustenie cronom. Bootovacie skripty FreeBSD tuto funkcionalitu obsahuju by default, staci aby to admin povolil a nastavil NTP server:

[root][~][20:52:02] grep ntpdate /etc/defaults/rc.conf
ntpdate_enable="NO"             # Run ntpdate to sync time on boot (or NO).
ntpdate_program="/usr/sbin/ntpdate"     # path to ntpdate, if you want a different one.
ntpdate_flags="-b"              # Flags to ntpdate (if enabled).
ntpdate_config="/etc/ntp.conf"  # ntpdate(8) configuration file
ntpdate_hosts=""                # Whitespace-separated list of ntpdate(8) servers.

Co sa tyka Linuxu, nemozem sluzit. Ale typujem, ze tam to bude zavisle od distribucie (ako v Linuxe takmer vsetko), a osobne si myslim, ze to tam skor nebude ako bude, nakolko vela distribucii NTP-related programy by default neinstaluje.

[fakenickname]

jj, myslel sem to tak ze ntpdate udela jednotkovy skok a ntpd zarucuje zadne zaporne casy. ale nebyl sem si tim tak uplne jisty tak sem to nechtel moc rozmazavat...

[mmmnovak]

a nevíte jestli lze rozchodit na platformě Windows synchronizaci času tak, aby nikdy nedošlo k přeskoku, ale aby se postupně zrychlovaly příp. zpomalovaly hodiny až by se dosáhlo správného času?

Díky za opodvěď.

[fakenickname]

windows maji imho nejaky vlastni integrovany synchronizator .. a mozna se mu i dokonce da nastavit casovy server.. i kdyz se mi to mozna jenom zdalo..

[mmmnovak]

to se dá samozřejmě nastavit (casovy server), ale zda existuje nějaká možnost, aby nedocházelo k přeskoku času, ale aby se postupně vyrovnál ...

integrovaná synchronizace času funguje skokově ...

[fakenickname]

zkusil bych to na jinem portalu.. pokud jde o windows tak jsme tu povetsinou tezke lamy

[mmmnovak]

Mohu ještě poprosit o radu, jak lze vypnout zobrazování provádění Cronu  v syslogu?

Hledal jsem to v /etc/syslog.conf ...  ale tam nevím jak co změnit ... poradíme mi prosím?

 

Děkuji.

[Josef Kufner]

Až budeš hledat, co se podělalo, budeš rád, že je tam máš. Pokud to zabírá příliš místa na disku, uprav nastavení logrotate.

[rich]

co říká ntpstat ?

u mě to vypadá takto:

[richard@mao ~]$ ntpstat
synchronised to NTP server (81.0.239.181) at stratum 3
   time correct to within 57 ms
   polling server every 256 s