Poslední příspěvky

1

Windows a jiné systémy / Re:Skok systémového času Windows

« Poslední příspěvek od Marvin kdy Dnes v 13:23:30 »

VMware potřebuje čas z hostitele při událostech boot/suspend/resume/snapshot, když musí posunout virtuální RTC a TSC o čas, kdy host spal a virtualizovaný OS o tom neví.
HPET VMware emulovat neumí.

2

Sítě / Re:Statická IPv4 a IPv6 PD na DOCSIS síti

« Poslední příspěvek od hlp84939 kdy Dnes v 12:50:34 »

Převodníky se aktuálně dodávají pouze business zákazníkům (u nich je automaticky veřejná pevná IPv4 a IPv6 součástí služby). Ovšem pozor, smlouva se uzavírá na 24 měsíců a tedy případná změna na nižší tarif nemusí být ze strany VF akceptována (a u business samozřejmě není ochrana v podobě měsíční výpovědní lhůty jako u běžných koncáků).

3

Windows a jiné systémy / Re:Skok systémového času Windows

« Poslední příspěvek od Marvin kdy Dnes v 12:45:23 »

Takže mi z toho vychází, že je špatně buď systémový čas v ESXi, nebo zmiňovaný offset (minimálně) pro tuto virtuálku. Čekám až se mi ozve admin. Skoro bych tipnul, že se u nás na firmě zprovoznil server, nastavil se čas a pak na to roky nikdo nešáhnul, ntp nebylo zapnuto, no a čas vesele driftuje o tu 0.8 vteřinu denně (což mi ale přijde docela dost). Ale třeba se pletu.

Vypadá to na neudržovaný čas na hostiteli.
Přesnost krystalu bez teplotní kompenzace je 10-50ppm, drift 0.8s/den je ještě dobrý výsledek.

4

Hardware / Re:Počítač se nezapne se zařízeními v USB

« Poslední příspěvek od redustin kdy Dnes v 12:36:03 »

IMO je tahle oblast docela komplikovaná. AI mi říká, že OTG USB-C nesmí připojit VBUS portu k napájení, dokud nezdetekuje Rd na CC lince - tj. připojené device. Současně ale signalizuje svůj "intent" hostitele připojením Rp CC na interní +5V, aby druhá strana viděla, že chce být hostitelem. Toto připojení nemá být trvalé, ale pravidelně to má odpojovat, aby mohl zdetekovat, že druhá strana chce také být hostitelem (jinak nemůže poznat Rp na druhé straně, protože by byly obě strany připojené Rp na 5V).

Ale současně AI říká, že každý hostitel by měl před sepnutím napájení do VBUSu zkontrolovat, zda druhá strana tam neposílá napětí. To platí i pro USB-A hostitele které nemají žádnou CC na komunikaci. Současně musí zajistit, aby se přicházející napětí z portu nedostávalo dál do zařízení.

Tudíž mi přijde, že v tomto případě jsou na vině obě zařízení - ten Rode nemá aktivovat VBUS, dokud na CC nevidí device, a ten PC host (který má USB-A  a tedy VBUS pod napětím před připojením Rode) by měl zabránit příchozímu proudu jít dál do PC (natož se z portu nechat napájet).

Ale pak chápu, že se dobře udělané PC odmítne spustit, když na USB portu zdetekuje příchozí VBUS, což tam nemá co dělat (OTG USB-C Rode to tam nemá co pouštět).

Ale možná jsem to pochopil blbě...

5

Windows a jiné systémy / Re:Skok systémového času Windows

« Poslední příspěvek od jardaplc kdy Dnes v 12:22:01 »

Povedlo se mi reprodukovat skoky, k posunu dojde i když ručně vypnu a zapnu servicu vmtoolsd. Po naběhnutí okamžite skok.
Z debug logu

Kód: [Vybrat]

...
[2026-01-08T17:10:29.805Z] [   debug] [vmtoolsd] [13096] Setting option 'synctime.period' to '0'.
[2026-01-08T17:10:29.805Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.enable' to '1'.
[2026-01-08T17:10:29.805Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.guest.resync' to '0'.
[2026-01-08T17:10:29.805Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.guest.resync.timeout' to '0'.
[2026-01-08T17:10:29.805Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.startup.backward' to '0'.
[2026-01-08T17:10:29.807Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.startup' to '1'.
[2026-01-08T17:56:41.436Z] [   debug] [vmtoolsd] [13096] Setting option 'toolScripts.afterPowerOn' to '1'.
[2026-01-08T17:56:41.436Z] [   debug] [vmtoolsd] [13096] Setting option 'toolScripts.beforePowerOff' to '1'.
[2026-01-08T17:56:41.436Z] [   debug] [vmtoolsd] [13096] Setting option 'toolScripts.afterResume' to '1'.
[2026-01-08T17:56:41.436Z] [   debug] [vmtoolsd] [13096] Setting option 'toolScripts.beforeSuspend' to '1'.
[2026-01-08T17:56:41.436Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.slewCorrection' to '1'.
...
Takže s největší pravděpodobností je na ESXi špatně nastavený systémový čas a v noci dojde k nějakému eventu, který vynutí resync i když je "vypnutý". Dle dokumentace

Virtual machine occasionally synchronizes time with the host even if you do not turn on periodic time synchronization. To completely disable time synchronization, you must set some properties in the virtual machine configuration file.
Power off the virtual machine.
Open the configuration (.vmx) file of the virtual machine in a text editor.
Add lines for the time synchronization properties and set the properties to FALSE.
tools.syncTime = "FALSE"
time.synchronize.continue = "FALSE"
time.synchronize.restore = "FALSE"
time.synchronize.resume.disk = "FALSE"
time.synchronize.shrink = "FALSE"
time.synchronize.tools.startup = "FALSE"
Save and close the file.

Při restartu vmtoolshd procne ten time.synchronize.tools.startup. V noci procne třeba něco jinýho.

Takže mi z toho vychází, že je špatně buď systémový čas v ESXi, nebo zmiňovaný offset (minimálně) pro tuto virtuálku. Čekám až se mi ozve admin. Skoro bych tipnul, že se u nás na firmě zprovoznil server, nastavil se čas a pak na to roky nikdo nešáhnul, ntp nebylo zapnuto, no a čas vesele driftuje o tu 0.8 vteřinu denně (což mi ale přijde docela dost). Ale třeba se pletu.

6

Windows a jiné systémy / Re:Skok systémového času Windows

« Poslední příspěvek od Filip Jirsák (forum) kdy Dnes v 12:05:26 »

VMware si udržuje pro každého hosta stav RTC jako ofset k času hostitele.
Při startu hosta vezme RTC z hostitele, přičte ofset. Při zápisu do RTC si uloží jen ten ofset.
Každý host může mít jiné časové pásmo i úplně jiný čas.
Do VM configu jde přidat relativní čas k hostiteli rtc.diffFromUTC nebo absolutní čas rtc.startTime.

Díky, nevěděl jsem, že už tam tato možnost je. (Teď se ukáže, že „už“ je 20 let…)

_{Škoda, že tu není možnost jenom dát komentáři palec nahoru, bez dalšího okecávání.}

7

Windows a jiné systémy / Re:Skok systémového času Windows

« Poslední příspěvek od Marvin kdy Dnes v 10:49:12 »

nevím o tom, že by nějaká virtualizační technologie udržovala systémové hodiny pro každého hosta zvlášť.

VMware si udržuje pro každého hosta stav RTC jako ofset k času hostitele.
Při startu hosta vezme RTC z hostitele, přičte ofset. Při zápisu do RTC si uloží jen ten ofset.
Každý host může mít jiné časové pásmo i úplně jiný čas.
Do VM configu jde přidat relativní čas k hostiteli rtc.diffFromUTC nebo absolutní čas rtc.startTime.

8

Windows a jiné systémy / Re:Zvláštnost při přihlášení do Windows 11

« Poslední příspěvek od Marek Staněk kdy Dnes v 10:34:58 »

Ok, takze to vypada, ze to bylo spise o VMw. Kazdopadne doporuceni je evidentne aktualizovat i hostitele nebo vypinat SB

Ono ESXi v některých nasazeních aktualizovat nemůžeš, protože třeba Cisco v případě ústředen garantuje provoz CUCMu jen na verzi ESXi, pro kterou proběhla certifikace při vypuštění major verze. Takže třeba CUCM 9-11 v prostředí, kde máš garantovat provoz, musíš pást na ESXi 6.x, protože na 7.x a 8.x sice běží, ale POKUD dojde k problému, jde odpovědnost za tebou, přestože by šlo o prokázanou chybu ESXi nebo CUCM. Pro novější verze (pod supportem jsou jen CUCM 14 a 15, starší jsou dávno EoL a out-of-support) je to obdobný; 14ka má v požadavcích ESXi 7.x, 15ka 8.x, a na čemkoli jiným (včetně HyperV nebo proxmoxu) jseš v tom sám a odpovědnost jde za tebou.

9

Windows a jiné systémy / Re:Skok systémového času Windows

« Poslední příspěvek od Marek Staněk kdy Dnes v 10:29:15 »

Pak tam nebudou žádné posuny o 3600.

Tady je skok o 2777, na časové pásmo to nevypadá.
Standardní ntpd skoky nad 1000 vůbec nedělá, čeká na ruční zásah.
W32Time má na skoky limity MaxPosPhaseCorrection a MaxNegPhaseCorrection, ale defaultně nejsou nastaveny.

Teď mi vlastně došlo, že tohle se nám vloni na jaře dělo u jednoho zákazníka, kde časový server pro telefonní subsystém (tzn ústředna, TSAPI server, telefonní přístroje, nahrávače) zničeho nic začal ze svého časového normálu dostávat periodicky chybná data. Zhruba každých 7 hodin prostě dostal chybný čas, takže všechno na něj navázané se po náhodné prodlevě přeštelovalo, takže třeba párování záznamů hovorů bylo pro období asi měsíce naprostý peklo. Nakonec se ukázalo, že služba NTP démona na nějakém síťovém prvku po nějakém uptimu (nehorázná doba, asi 7 let) začala magořit a restart ji "opravil". Prostě jí něco někde přeteklo.
Takže ten problém klidně může být někde, kam nedohlídneš.

Zkus ty postižené virtuály nastavit proti cz.pool.ntp.org (viz výše).

10

Hardware / Re:Počítač se nezapne se zařízeními v USB

« Poslední příspěvek od jauznevimco kdy Dnes v 09:45:02 »

Rodecaster umi fungovat jak v rezimu USB host, tak USB peripheral, coz je skvele a progresivni.
A protoze nejaka fyzicka packa mezi "jsem host / jsem periferie" je prilis oldschool a vubec zcela nevhodna do dnesni skvele, progresivni a digitalni doby, mame prece ve specifikaci proces nejake autonegociace...


Cili for je ten, ze Rodecaster se po svem zapnuti snazi natroubit 5V do USBcka, jenze to USBcko jde z pocitace a 5V dodava taky.
To je pry zcela korektni a ve striktnim souladu se specifikacemi a autonegociace by si s tim mela umet poradit, jenze, slovy Rode, "nekteri vyrobci USB radicu tuto cast specifikace opomenuli".
https://help.rode.com/hc/en-us/articles/7376147203599-Why-can-t-my-computer-turn-on-when-the-R%C3%98DECaster-Pro-II-or-R%C3%98DECaster-Duo-is-connected

Implementace USB radice v nasi desce zpusobovala, ze pocitac nebylo mozno zapnout vypinacem (ale pocitac sel zapinat skrze zapnuti pripojeneho Rodecasteru :-) ). A po asi pul roce takoveho fungovani prislusny radic odesel zcela.