Poslední příspěvky

1

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

2

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.

3

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.

4

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

5

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.

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 09:34:42 »

Tohle váš problém nevyřeší, ale není od věci ve Windows nastavit systémový čas na UTC:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f
(nutný restart)

Pak tam nebudou žádné posuny o 3600.
V případě dual boot je to skoro nezbytné.

Tohle nastavení by mělo být shodné s tím, v jakém časovém pásmu poskytuje čas hypervizor. Pokud hypervisor poskytuje hostovi čas v UTC, mělo by to být nastavené, jak píšete. Pokud hypervizor poskytuje lokálí čas, měla by tam být výchozí hodnota.

Každopádně tohle ovlivňuje, jak se čas načte ze systémových hodin při startu systému. Pak naběhnou služby a ty to srovnají buď podle NTP, nebo podle hypervizora (pokud se používá ta služba z VMware Tools).

(Když běží systém nafyzickém železe, ovlivňuje výše uvedené samozřejmě i zpětný zápis, když operační systém zapíše svůj čas zpátky do hodin počítače. Ve virtualizovnaém prostředí to ale nemá žádný efekt – nevím o tom, že by nějaká virtualizační technologie udržovala systémové hodiny pro každého hosta zvlášť.)

7

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

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

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.

8

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

« Poslední příspěvek od redustin kdy Dnes v 08:54:13 »

Co tedy ten Rode konkrétně dělá, že dokonce způsobí poškození napájení portu? Odebírá větší proud, než kolik udává jeho deskriptor (resp. > 500mA)? Překvapuje mě, že by port neměl nadproudovou ochranu. Díky!

9

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

« Poslední příspěvek od Radek Zajíc kdy Dnes v 07:50:49 »

Dá se to dostat i k nižším rychlostem, a bez pevné IP?

Ze zacatku (v zari) to slo, pronajal jsem si prevodnik k tarifu 100/20 pro domacnosti. Pak jsem cestou "aktivace staticke IP adresy"/"deaktivace staticke IP adresy" ziskal i /56 IPv6 (takze ted mam dynamickou IPv4 adresu a dynamicky IPv6 prefix, ovsem ten ma lease time 40 dni a zatim se nezmenil). Pred par dny jsem ten tarif zvedl na 100/100, IPv6 funguje stale.

Ale dochazi jim zasoby, takze ted zrovna to moc nejde. I kdyz kolegovi ted pronajali prevodnik k 500/200 business tarifu (prechazel z VF station), takze mozna staci byt asertivni. Nebo si rict o tarif 2000/400 s tim, ze potrebujete bridge, a po instalaci tarif snizit.  (Prevodnik je jedine zarizeni pro 2 Gbit/s tarif schopne bridge.)

10

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

« Poslední příspěvek od BobTheBuilder kdy Dnes v 07:16:53 »

Tohle váš problém nevyřeší, ale není od věci ve Windows nastavit systémový čas na UTC:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f
(nutný restart)

Pak tam nebudou žádné posuny o 3600.
V případě dual boot je to skoro nezbytné.