Fórum Root.cz
Hlavní témata => Windows a jiné systémy => Téma založeno: ZAJDAN 06. 03. 2018, 08:34:26
-
Ahoj...
na doménovém serveru jsem nastavil čas synchronizací z veřejných serverů:
1) net stop w32time
2) w32tm /config /syncfromflags:manual /manualpeerlist:”tik.cesnet.cz, tak.cesnet.cz”
3) w32tm /config /reliable:yes
4) net start w32time
5) w32tm /query /configuration
zkracený výstup:
[Configuration]
......
[TimeProviders]
....
Type: NTP (Local)
NtpServer: tik.cesnet.cz, tak.cesnet.cz (Local)
....
VMICTimeProvider (Local)
DllName: C:\Windows\System32\vmictimeprovider.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
NtpServer (Local)
DllName: C:\Windows\system32\w32time.DLL (Local)
Enabled: 1 (Local)
InputProvider: 0 (Local)
AllowNonstandardModeCombinations: 1 (Local)
....
na jednom z klientů v doméně jsem pustil:
net time \\server.moje-domena.work /set /y
čas se zesynchronizoval, ale během půl hodiny se na klientovi rozhodí až o 2 minuty!
poradil by někdo jak korektně zadrátovat klienty k synchronizaci na server?
díky
-
Protože tím manuálním net time jsi to možná celé rozbil....
Pokud je windows počítač členem AD domény, provádí automaticky pomocí podepsaného NTP synchonizaci proti doménevému řadiči, co najde a hlásí stav, že je reliable (první instalovaný PDC si reliable nahodí automaticky sám), pokud jsi manuálně nesahal do konfigurace w32tm na klientech.
Takže bych se podíval na klientovi, zda si odněkud bere čas: w32tm /query /status
Tím se dozvíš, odkud bere aktuálně čas kdy ho vzal naposledy, s jakou chybou, jak často se dotazuje, ...
Případně aktuální stav času proti všem řadičům (chvíli trvá): w32tm /monitor
-
nevidím jedinej duvod proc bych to mel robít, pokud si šáhnu na čas ke stejnému zdroji, ale i tak provedl jsem restart klienta zavolal na něm:
net time \\LOCALHOST
Current time at \\LOCALHOST is 3/6/2018 10:12:29 AM
The command completed successfully.
net time /DOMAIN:moje-domena.work
Current time at \\SERVER is 3/6/2018 10:10:08 AM
The command completed successfully.
w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0625000s
Root Dispersion: 8.0479121s
ReferenceId: 0xC0A80106 (source IP: 192.168.1.6)
Last Successful Sync Time: 3/6/2018 10:09:33 AM
Source: server.moje-domena.work
Poll Interval: 10 (1024s)
w32tm /query /source
server.moje-domena.work
w32tm /monitor
Getting AD DC list for default domain...
Analyzing server.moje-domena.work (1 of 1)...
delayoffset from server.moje-domena.work
Stratum: 2
Warning:
Reverse name resolution is best effort. It may not be
correct since RefID field in time packets differs across
NTP implementations and may not be using IP addresses.
server.moje-domena.work *** PDC ***[192.168.1.6:123]:
ICMP: 2ms
NTP: +0.0000000s RefID: tak.cesnet.cz [195.113.144.238]
proč se tedy čas i po restartu, časový zdroj správně, liší o 2 minuty?
-
Protože w32tm běžící nějakým způsobem zpomalí/zrychlí běh lokálního času, pokud mu do toho sáhneš skokovou změnou net time, tak to zblbne.
A jak sed ta chyba vyvíjí v čase?
Obecně, pokud je při startu Win klienta čas serveru pozadu do 2 minut, tak klient zpomalí svůj čas tak, aby ty 2 minuty cca dorovnal za 20 minut, pokud je odchylka víc jak 2 minuty, měl by to skokově dorovnat po startu a prvotním kontaktu serveru.
Má na to případně dost vliv, zda server nebo klient je virtuál.
Jak se to vyvíjí v čase se dá pozorovat pomocí w32tm /stripchart /computer:192.168.1.6
-
Není ten stroj náhodou virtualizovaný? Ve výchozím stavu se přebírá čas z "podhoubí" a pak se to tluče.
-
Není ten stroj náhodou virtualizovaný? Ve výchozím stavu se přebírá čas z "podhoubí" a pak se to tluče.
ano jsou virtualy oba, ale jak zminoval M on se ten cas postupne spravuje, ja bych ocekavl, ze si to spis checkne cas a jednim uderem ho spraví
ale prikaz vise co jsem uvedl jasne ukazal ze klient si cas bere ze spravneho serveru, debilni je jen to ze si to srovnava plynule a ne jednou jebou
-
a ted jsem si vsiml, ze jiny klient(nativni na zeleze) ve stejne domene co uz bezi vice jak den si nebyl schopnej cas srovnat, pricemz status ukazuje ze ma spravny zdroj k serizeni casu a to domenovy server...nevim...zacinam si myslet ze v tech windows to nefunguje uplne v poradku
-
Ano, w32tm je taková specifická implementace S/NTP (když to beru z pohledu, že řešívám spíše nutnost jednotného času a frekvence na nanosekundy), ale pro běžnou kancelařinu OK, pokud mi nevadí chyba do cca 1 sekundy (od 2016 serveru je podpora pro přesnější časy v ms měřítku).
Pokud to jsou virtuály a navíc VM hostitel případně do času uvnitř virtuálu štouchá vlastníma postupy, tak to bude pořád nějak plavat. Ohledně počáteční sync platí, co jsem psal, pokud je klient 0 až 2 min před serverem, dojde k plynulému dorovnání času jeho zpomalením na klientu, v ostantích případech se dorovná při startu skokem.
Pokud ten nativní klient běžel ještě před tím, než jsi aktivoval a korektně syncnul ten server, tak pokud tím čas na serveru nečekaně někam poskočil o minuty, tak klient jej bude již ignorovat, protože jej vyhodnotil jako nespolehlivý. Skokově dorovná až po rebootu nebo možná w32tm /resync, který mu vymaže statistiky.
-
Ano, w32tm je taková specifická implementace S/NTP (když to beru z pohledu, že řešívám spíše nutnost jednotného času a frekvence na nanosekundy), ale pro běžnou kancelařinu OK, pokud mi nevadí chyba do cca 1 sekundy (od 2016 serveru je podpora pro přesnější časy v ms měřítku).
Pokud to jsou virtuály a navíc VM hostitel případně do času uvnitř virtuálu štouchá vlastníma postupy, tak to bude pořád nějak plavat.
ja stále nechápu jak host do guesta muze šťouchat, když přeci sam guest ukazuje jaký má zdroj času viz:
w32tm /monitor
Getting AD DC list for default domain...
Analyzing server.moje-domena.work (1 of 1)...
delayoffset from server.moje-domena.work
Stratum: 2
Warning:
Reverse name resolution is best effort. It may not be
correct since RefID field in time packets differs across
NTP implementations and may not be using IP addresses.
server.moje-domena.work *** PDC ***[192.168.1.6:123]:
ICMP: 2ms
NTP: +0.0000000s RefID: tak.cesnet.cz [195.113.144.238]
jak já jako admin se tedy dozvím, koho ta mašina poslouchá? hosta co ji virtualizuje nebo servery nastavene ve w32tm ?
-
Mašina nikoho neposlouchá. :-(
Služba w32tm monitoruje čas v systému a čas DC serveru a nějakým způsobem dorovnáná ten lokální čas v OS a předpokládá, že jednak nikdo jiný na ten čas v OS nesahá a čas v OS běží navíc rovnoměrně tempem, co určila (což ne vždy ve virtuálu je pravda). Pokud ti v systému běží ještě něco jiného, co případně s časem manipuluje, například VMware tools, tak se pak vzájemně ty nástroje přetahují a jen si v tom vzájemně vyrábí chybu.
Ty víš, jakou virtualizační platformu používáš, víš jak ji máš nastavenu ohledně udržovánbí času ve virtuálech, jaké služby a k čemu tam máš nacpané, co ne/umí a dle toho se zařídit. :-)
-
Prosímtě, nechceš se na to adminování Woken vysrat? Dle záplavy začátečnických dotazů za poslední týden to zjevně nebude tvoje parketa.
PDC se synchronizuje s nějakým veřejným zdrojem času, ostatní DC se synchronizují s ním, pracovní stanice v doméně se synchronizují s těmi DC. Krom nastavení toho PDC není normálně třeba nic dělat.
Pokud máš DC jako virtuály, tak synchronizaci s HyperV v integration services vypni.
Je úplně šumák, o kolik minut je to rozházené vůči zbytku světa, podstatné a účelem snažení je, aby to bylo synchronizované mezi sebou a fungovaly Kerberos tickety.
-
K předchozímu viz např. zde bod 5 (https://www.altaro.com/hyper-v/virtualized-domain-controllers-4-myths-12-best-practices/).
-
Ty víš, jakou virtualizační platformu používáš, víš jak ji máš nastavenu ohledně udržovánbí času ve virtuálech, jaké služby a k čemu tam máš nacpané, co ne/umí a dle toho se zařídit. :-)
díky za podporu, vypínám tedy službu pro syncTime primo na virtualizaci hostu:
VBoxManage setextradata "domain-server" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 1
-
Je dobrým pravidlem mít první dc na fyzickém stroji, noboť když je to na virtuálním tak se tam mlátí časy mezi sebou a děla to neplechu, neboť dc si při startu bere čas s z biosu a také se ho tam aktualizuje, když je to na virtualizaci tak nemá pravou upravovat čas v biosu a cele se to taky rozkazuje. Tak hlavní dc nať na samotnou masinu a na klienty nesahat sami si pak srovnání čas s dc
-
K předchozímu viz např. zde bod 5 (https://www.altaro.com/hyper-v/virtualized-domain-controllers-4-myths-12-best-practices/).
díky za článek
-
K předchozímu viz např. zde bod 5 (https://www.altaro.com/hyper-v/virtualized-domain-controllers-4-myths-12-best-practices/).
Díky za výživný odkaz - pro mě osobně výživný od A do Z.
Konkrétně k bodu 5:
takže "bývaly doby, kdy DC běžící ve VM (Hyper-V) uměl přebírat čas od hostitele a distribuce času v doméně takto fungovala. Ty doby jsou pryč. Odteď si chce DC ve VM správcovat čas striktně sám, brát ho z upstream NTP serveru." Přestože je to obecně z hlediska časomíry ve virtualizovaném prostředí možné méně vhodná varianta, dodávám já.
Líbí se mi, jak distribuce času ve Windows doméně funguje bezpracně, samospádem, včetně krypto-ošetření. Dokonce mám pocit, že W32time s každou novou generací Windows trochu dospěje. Bravo. Tzn. jenom na okraj chci zmínit, že to může fungovat taky mimo doménu, dokonce jako časová serviska na NTP klientech (včetně DC!) nemusí být použita W32time, ale open-source ntpd (Windows build).
Každopádně pokud NTP klient běží ve VM, ať už je na bázi W32time nebo ntpd, týkají se ho obecné nectnosti virtualizovaného prostředí pokud se týče časomíry. K tématu existuje obecný whitepaper od Meinbergů (https://www.meinbergglobal.com/download/burnicki/time_synchronization_in_virtual_machines.pdf) - autor Martin Burnicki je jejich dlouholetý klíčový vývojář ovladačů pro Windows a Linux. Jeho univerzální driver pod Windows, co se chytí cca od NT po Win10 na všechen jejich hardware (ISA/PCI/USB) je takový nepravděpodobný drahokam. Ten člověk ví o čem mluví. A mluví o spojitosti běhu softwarové časové základny v guest OS, která záleží na "spojitosti virtualizace" (ideálně vyhrazené CPU jádro pro guesta) a zejména na přesnosti/spojitosti/spolehlivosti doručování interruptů HW časovače - což není zrovna triviální požadavek vzhledem k tomu, že guest nevlastní fyzický čipset, ve kterém se tyto časovače vyskytují (vlastní nanejvýš CPU TSC a LAPIC timer, což je myslím trochu málo, on totiž není časovač jako časovač.)
Tradiční moudro bývalo, že ve virtuálu stojí časomíra za vyliž. (Což se na nenáročném klientovi ještě zkousne, ale na NTP serveru ztuha.) Nějakou dobu už ale slýchám dovětek, že moderní verze hypervizorů v tomto směru učinily značný pokrok. Každopádně mi připadá jako zdravý a systematický postup, použít nativní podporu HV pro časomíru, tzn. nakonfigurovat guesty, ať si berou čas 1:1 od hostitele, který jediný má pod palcem fyzické železo a může provozovat košer časovou základnu, včetně závěsu na vnější NTP, PTP, PPS, co já vím (záleží co HV software podporuje). Druhá možnost je, nechat guesta, ať si spravuje čas sám, pokud se HV vynasnaží, neházet mu v tom klacky pod nohy - viz doručování timer interruptů.
Zcela souhlasím s tím, co už tady napsali jiní: bacha ať časovou základnu guesta nedolaďují na střídačku dva různé mechanismy. Pak se totiž "perou", přestane existovat jediná a jasná zpětnovazební dolaďovací smyčka.
Pokud se týče doladění skokem vs. spojitě, ta volba je samozřejmě kompromis, uvědomte si že při skokovém doladění může čas poskočit *dozadu*, což je v mnoha případech průser. V jiných případech je kriticky žádoucí, aby přesný čas seděl hned po doladění. Záleží na aplikaci = způsobu použití, oblasti nasazení. Je třeba si uvědomit, že pro volnoběh (softwarové) časové základny lokálního OS mezi dvěma "olíznutími upstreamu" je třeba dolaďovat frekvenci tohoto volnoběhu, a že nějaká reziduální nepřesnost bude nastávat pravidelně, ať už dolaďujeme výhradně spojitě nebo výhradně skokem.
Úplně přesnému času se lze přiblížit několika způsoby:
- dodatečným hardwarem a třeba ještě specializovaným API, které z toho hardwaru bude tahat časové značky
- slušně přesnou synchronizaci lokálního systémového času OS dokáže poskytnout PPS vstup, ale ten pod Windows pokud vím nelze na generickém PC HW zavést (pod Linuxem ano, skrz sériový či paralelní port, nebo skrz síťovku s HW podporou PTP)
- což mi připomíná, že z hlavy nevím, jak často dolaďuje frekvenci SW časomíry OS Meinbergovic serviska běžící v přítomnosti Meinbergovic přesných HW hodin (PCI-e) - možná každou sekundu? Každopádně se to té systémové PPSce bude dost blížit
- v národních laboratořích etalonu času se vyskytují extrémisti, kteří si fázově zavěsí centrální oscilátor PC motherboardu na vnější frekvenční normál, takže pak servosmyčka časomíry v OS rychle zkonverguje ke konkrétní hodnotě, která se dál už prakticky nemění (protože ten mizerný šutr na motherboardu už nevandruje)
Závěrem obligátní poznámka: softwarová systémová časomíra pod Windows má přesnost poměrně omezenou reálnou granularitou časových značek. Za starých časů to bývalo 15.6 ms (perioda scheduleru), tuším od Win7 je to 1 ms, netuším zda v nejnovějších 10/2016 se to třeba dál nezlepšilo. V Linuxu už drahně let není problém, aby ntpd vykazoval reziduální offset v nízkých jednotkách mikrosekund pokud má PPS, nebo cca 20-50 us pokud bere čas po nezatížené LANce od kvalitního stratum 1.
-
.....
Vaším příspěvkem se téma dostalo na další vyší úroveň a je vidět, že ladění času ve virtualizovaném prostředí není uplně tak triviální věc.
Pročítám teď ty odkazy a podstatnou informací pro mne je:
http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.2. (http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.2.)
kde se píše:
________________________________________________________________________________________________________
NTP server was not designed to run inside of a virtual machine. It requires a high resolution system clock, with response times to clock interrupts that are serviced with a high level of accuracy. NTP client is ok to run in some virtualization solutions.
Run NTP on the base OS of the machine, and then have your various guest OSes take advantage of the good clock that is created on the system. Even that may not be enough, as there may be additional tools or kernel options that you need to enable so that virtual machine clients can adequately synchronize their virtual clocks to the physical system clock.
___________________________________________________________________________________________________________
podobně se vyjadřují na tom whitepaperu co jste zmínil https://www.meinbergglobal.com/download/burnicki/time_synchronization_in_virtual_machines.pdf (https://www.meinbergglobal.com/download/burnicki/time_synchronization_in_virtual_machines.pdf):
___________________________________________________________________________________________________________
Generally it is not advisable to run a VM as time server for other physical machines since the time
provided by such server is usually less accurate and provides significantly more jitter than a physical
machine acting as time server.
___________________________________________________________________________________________________________
Z toho tedy chápu, že bych neměl nechat virtuální stroj poskytovat časovou službu(být časovým serverem) kde čas vychází z jeho samotného.
Ok, ale jak je tomu v případě, že virtuální stroj si ten čas bere z upstreamu jako to mám já (tik.cesnet, tak.cesnet.cz) ?
Je "spolehlivé" vypnout na Hostu synchronizaci času pro Guesta a nechat Guesta si čas řídit z upstreamu?
díky
-
tak jsem si znova precetl vas prispevek a je tam i odpoved na to co se ptám:
Každopádně mi připadá jako zdravý a systematický postup, použít nativní podporu HV pro časomíru, tzn. nakonfigurovat guesty, ať si berou čas 1:1 od hostitele, který jediný má pod palcem fyzické železo a může provozovat košer časovou základnu, včetně závěsu na vnější NTP, PTP, PPS, co já vím (záleží co HV software podporuje). Druhá možnost je, nechat guesta, ať si spravuje čas sám, pokud se HV vynasnaží, neházet mu v tom klacky pod nohy - viz doručování timer interruptů.
díky
-
Každopádně mi připadá jako zdravý a systematický postup, použít nativní podporu HV pro časomíru, tzn. nakonfigurovat guesty, ať si berou čas 1:1 od hostitele, který jediný má pod palcem fyzické železo a může provozovat košer časovou základnu
To funguje, s výjimkou těch virtualizovaných DC. Fakt je potřeba to tam vypnout, jinak to zhusta rozjebe synchronizaci v celé doméně.
-
To funguje, s výjimkou těch virtualizovaných DC. Fakt je potřeba to tam vypnout, jinak to zhusta rozjebe synchronizaci v celé doméně.
Učinil jsem tak, klienti jsou synchronizovaní, čas drží přesně
Jen by mě ještě zajímalo jak často si klient čmuchne k DC serveru pro čas, je to průběžně nebo jen při loginu?
-
@ZAJDAN: optimální pro DC (z hlediska servírování času) je běžet na holém železe.
Pokud správně chápu bod č.5 a ještě čerstvé osobní potvrzení od Lol Phirae, tak pokud DC musí běžet ve virtuálu, je v tomto specifickém případě vhodné, aby si řešil časomíru sám = DC ve virtuálu si sám bere upstream NTP z divokého internetu a servíruje dál doménovým klientům, na čas od HV (hostitele) kašle a je úkolem HV, aby guestovi časomíru pokud možno nemrvil přerušováním přiděleného procesorového času a rozhasením timer interruptu (což patrně konfiguračně neovlivníte).
Varianta, že DC ve virtuálu si bere čas od HV=hostitele, podle uvedených zdrojů reálně nefunguje. Je to ale specifický případ MS DC. Obecná rada je přesně opačná :-(
Slýchal jsem, že tik a tak jsou docela vytížení. Nevím zda W32time vezme pool.ntp.org = DNS round-robin load-balanced množina NTP serverů rozprostřená po zeměkouli. Pokud chcete jistotu, znamená to postavit nebo koupit 1-2 dedicated stratum 1 servery zavěšené na GPS (o fous horší varianta je DCF77). Se třemi a více NTP servery je to teoreticky odolné dokonce i proti manipulaci jednotlivého NTP serveru (outlier rejection).
-
To funguje, s výjimkou těch virtualizovaných DC. Fakt je potřeba to tam vypnout, jinak to zhusta rozjebe synchronizaci v celé doméně.
Učinil jsem tak, klienti jsou synchronizovaní, čas drží přesně
Jen by mě ještě zajímalo jak často si klient čmuchne k DC serveru pro čas, je to průběžně nebo jen při loginu?
Nedokážu najít v dokumentaci, zda to tak skutečně je, ale tipuji, že je blbost, aby w32time fungovala jenom při přihlášeném desktopu. Jsem si skoro jistý, že to funguje i ve stavu "žádný uživatel není přihlášený", pokud je daný stroj přiřazen v AD do domény. Technicky to dává velmi dobrý smysl.
Možná napoví následující úryvek z Vašeho výpisu:
w32tm /query /status
Last Successful Sync Time: 3/6/2018 10:09:33 AM
Poll Interval: 10 (1024s)
Nechte stroj nějakou dobu běžet bez přihlášeného uživatele, pak se přihlaste a zeptejte se uvedeným způsobem.
Není mi jasné, zda ten "poll interval" je pevný. V případě ntpd (parametry minpoll/maxpoll) je perioda dotazování v nějakém rozmezí pseudonáhodná.
Potkal jsem nějaká starší povídání o volbě zdroje času v rozsáhlejší konfiguraci domén (domain forest).
https://tigermatt.wordpress.com/2009/08/01/windows-time-for-active-directory/
https://blogs.msdn.microsoft.com/w32time/2007/09/04/keeping-the-domain-on-time/
Nevím kolik z toho je ještě dneska pravda. Např. jsem žil v domnění že w32time používá NTP i v rámci domény - ale uvedené zdroje mluví o microsoftím vlastním mechanismu NT5DS.
-
Slýchal jsem, že tik a tak jsou docela vytížení. Nevím zda W32time vezme pool.ntp.org = DNS round-robin load-balanced množina NTP serverů rozprostřená po zeměkouli.
Ale jo, funguje.
> w32tm /query /computer:dc /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0127925s
Root Dispersion: 0.0570451s
ReferenceId: 0x59DDD2BC (source IP: 89.221.210.188)
Last Successful Sync Time: 07.03.2018 23:01:41
Source: 1.cz.pool.ntp.org,0x1
Poll Interval: 10 (1024s)
-
...
Není mi jasné, zda ten "poll interval" je pevný. V případě ntpd (parametry minpoll/maxpoll) je perioda dotazování v nějakém rozmezí pseudonáhodná.
....
našel jsem k tomu nějakou dokumentaci a pokud to dobře chápu, tak se to dá nastavit v registru pomocí ruzných parametrů jsou tam i zmíněné Min Max Pool a třeba i UpdateInterval
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/windows-time-service/windows-time-service-tools-and-settings (https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/windows-time-service/windows-time-service-tools-and-settings)
zkusím se tím ještě pročíst
anglicky umím ale mám problém tomu rozumět na technické úrovi, konkrétně co dělá ten Mix MaxPool Interval
-
Grammar nazi poznámka:
"pool" [vyslov "půůůl"] znamená bazén, množina, kyblík něčeho předpřipraveného. Případně je to k vidění jako sloveso: něco si předem připravit / nahromadit / dlouhodobě průběžně společnými silami udržovat na hromadě pro sdílené použití. V našem případě množina NTP serverů od které chceme, aby nám vybrala nějaký náhodný server, kterého se máme ptát. (Třeba europalety se taky točí v nějakém sdíleném "poolu".)
"to poll" [vyslov "pollll"] znamená dotázat se. Klasicky přečíst jednorázově nějakou hodnotu z hardwaru. Nebo v tomto případě poslat dotaz upstream NTP serveru / vyžádat si od něj aktuální přesný čas. ("Opinion poll" je průzkum veřejného mínění.)
Odtud vysvětlivka k věci:
Poll interval = jak často se dotazovat.
Minpoll / maxpoll = v jakém rozmezí se má pohybovat poll interval. Přesněji, v případě ntpd se jedná o exponent v mocnině dvou. Takže "minpoll 6" znamená dotazuj se v intervalu ne kratším než 2^6=64 sekund. Reálně se ntpd ptá v intervalu pseudonáhodně zvoleném mezi 2^minpoll až 2^maxpoll [sekund].
http://doc.ntp.org/4.1.1/confopt.htm
Zda mají tyto pojmy shodný význam a datový typ v konfiguraci w32time, to nevím :-)
-
Grammar nazi poznámka:
"pool" [vyslov "půůůl"] znamená bazén, množina, kyblík něčeho předpřipraveného. Případně je to k vidění jako sloveso: něco si předem připravit / nahromadit / dlouhodobě průběžně společnými silami udržovat na hromadě pro sdílené použití. V našem případě množina NTP serverů od které chceme, aby nám vybrala nějaký náhodný server, kterého se máme ptát. (Třeba europalety se taky točí v nějakém sdíleném "poolu".)
"to poll" [vyslov "pollll"] znamená dotázat se. Klasicky přečíst jednorázově nějakou hodnotu z hardwaru. Nebo v tomto případě poslat dotaz upstream NTP serveru / vyžádat si od něj aktuální přesný čas. ("Opinion poll" je průzkum veřejného mínění.)
omlouvám se, to byl překlep a zároveň děkuji za upřesnění na technické rovinně