1
Windows a jiné systémy / Re:Skok systémového času Windows
« Poslední příspěvek od jardaplc kdy Dnes v 15:11:44 »Pro doplnění, v jiné virtuálce se to děje taky. Fyzické železo je Dell Poweredge R350 a běží na něm ESXi.
Poslední příspěvky
2
Bazar / Re:Prodám vývojovou desku a moduly Toradex
« Poslední příspěvek od redustin kdy Dnes v 14:42:57 »Tak je fakt, že navrhovat vlastní desku (jak je zmíněno v úvodním příspěvku) pro takto starý modul je dost nepravděpodobné.
3
Sítě / Re:Wi-Fi pro dvoupatrový dům
« Poslední příspěvek od Martin Poljak kdy Dnes v 14:18:20 »To je právě ten váš největší omyl. Trh takhle nefunguje. Jestli s tím souhlasíte nebo nikoliv není podstatné.Problém je, že specificky tady většina lidí nechápe, že je irelevantní co uživatel ví a neví. O tom, co potřebuje a nepotřebuje rozhoduje on a je zcela irelevantní jaký k tomu má důvod. Prostě nepotřebuje to, o čem se on rozhodne, že to nepotřebuje.
Je mi líto, ale s tím nelze ani v nejmenším souhlasit. V procesu rozhodování jsou informace, tedy co uživatel ví, či neví, zcela zásadní. Ať už jde o analytické nebo intuitivní informace. Na základě těchto informací probíhá rozhodovací proces. Tedy rozhodně záleží jaké informace uživatel má, odkud je získal a jestli odpovídají realitě.
No právě. Ale mluvíte o úplně něčem jiném. Držte se kontextu. Tedy výše prezentované představy, že běžný domácí uživatel půjde a koupí si místo TP-Linku, který mu naprosto dostačuje arubu za cca pětkrát tolik. To je jednoduše sci-fi. A taky se to celkem logicky opravdu neděje.tyhle vlastnosti jsou často těm běžným uživatelům jednoduše úplně jedno a rozhodně za ně neplánují zaplatit pětkrát tolik.
S tím také nesouhlasím. Ano, je jim jedno, jestli bude mít CPU X nebo Y GHz. Ale není jim jedno, jestli bude jejích počítač rychlý nebo pomalý. Uživatel prostě má potřeby a tedy i požadavky. Jen je někdy a některé a priory explicitně nespecifikuje neb toho není schopen.
Zkuste si na základě toho, co jsem napsal odpovědět sám. Přímo to z toho vyplývá. Minimálně se to totiž nijak nevylučuje. Spíš naopak.Ta "potřeba" je záležitost subjektivní volby kombinovaná s mezním užitkem z kvality a peněz, které na ni je třeba vynaložit.Tak proč rozporujete jejich potřebu v podobě drahého telefonu, když vzápětí tvrdíte, že je potřeba subjektivní?
Spíš to na mne působí tím klasickým dojmem, že se jim snažíte vnutit svůj pohled resp. jim podsouváte svoje potřeby.Co na vás působí dojmem je vaše dojmologie. Nic ve zlém.
4
Bazar / Re:Prodám vývojovou desku a moduly Toradex
« Poslední příspěvek od em.ve kdy Dnes v 13:20:33 »To je fakt jen pro nadšence. Imx6 je 10+ let stará platforma, zbytek neumím z fleku posoudit. Ta tisícovka, co tu někdo za to nabízí, je myslím adekvátní. Stejně to jenom dá do nějaké krabice a za 5-10 let vyhodí.
5
Windows a jiné systémy / Re:Skok systémového času Windows
« Poslední příspěvek od jardaplc kdy Dnes v 13:16:08 »"Synchronize guest time with host" je zapnuto nebo vypnuto?Těď jsem ji ve virtuálce vypnul. Uvidím zítra, jestli to pomůže
Kód: [Vybrat]
VMwareToolboxCmd.exe timesync disableBohužel jsem se nepodíval předtím na status jestli byla zapnuta nebo nikoliv. Předpokládám ale, že byla. Napsal jsem správci aby sycnchronizaci vypnul v host systému v konfiguraci virtuálky než se přijde na příčinu.Nedočetl jsem se důležitou informaci: máte důvod se domnívat, že ten VMware (hypervizor) má správný čas?
Díval jste se? Bere si ho odněkud přes NTP?
To je velmi dobrá připomínka, zeptám se správce.
Vrtá mi hlavou, jestli Vám tam běží nějaký další nespecifikovaný software, zda se třeba nesnaží ještě taky po svém zasahovat do systémového času - to už je na Vás.Našel jsem zásahy jenom od zmíněného wmtoolsd a pak korekce zpět (a případné běžné korekce v řádu milivteřin) od w32tm
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 13:14:52 »Teď už zbývá jenom zjistit proč to dělá.Přepdokládám, že proto, že máte zapnutou synchronizaci času s hostitelem, jak psal Marvin. A ty časové skoky by pak byly způsobené tím, že má špatně nastavený čas hostitel – jak psal František Ryšánek, je potřeba zkontrolovat, zda hypervizor má správný čas, a zda má nějaký mechanismus, jak čas udržovat správný (např. z NTP).
Pokud to tak je, u vás by se problém vyřešil tím, že vypnete synchronizaci času s hostitelem a necháte Windows, ať se o čas starají na základě NTP (tj. to standardní nastavení, které vám ráno nastavuje zpět správný čas). Nicméně chtělo by to vyřešit správný čas i na tom hypervizoru, protože dneska mít někde špatný čas je celkem nebezpečné (jsou z toho různé podivné chyby) a v drtivé většině případů zbytečné (pokud nemáte počítač v bunkru pod zemí odpojený od sítě, vždycky se aspoň nějaký zdroj přesného času dá sehnat).
A až bude vyřešen problém se synchronizací času v hypervizoru, rozhodněte se, který ze způsobů synchronizace času chcete použít, a použijte jenom jeden. Buď vlastí synchornizaci v hostovaném systému (Windows) nejspíš přes NTP, nebo synchornizaci času s hypervizorem. Protože ještě horší, než mít špatný čas, je mít špatný čas pokaždé jinak, podle toho, který zdroj času zrovna vyhraje.
7
Windows a jiné systémy / Re:Skok systémového času Windows
« Poslední příspěvek od František Ryšánek kdy Dnes v 13:07:48 »Na Windows (uvnitř QEMU+KVM) používám tohle, mohlo by pomoci. https://www.timesynctool.com/
1.) proti gustu žádný dišputát. Pokud Vám to funguje, klidně si poslužte...
2.) nemá specifickou podporu pro virtuální časoměrná zařízení hypervizoru QEMU+KVM (ani pro VMware)
3.) pokud to použijete, vypněte všechny ostatní způsoby dolaďování času ve VM guestovi = zastavte standardní MS servisku w32time, VMware tools, cokoli dalšího případně sahá na systémový čas
4.) ta věc je zcela banální SNTP klient, původně vyvinutý pro Win98. Tzn. patrně umí reálně méně, než standardní NTčkový w32time, a velmi pravděpodobně méně, než třeba Win32 build ntpd (nějaký binární build mají k dispozici Meinbergové, ale viděl jsem alternativní build i od někoho dalšího).
Ale ten Váš timesynctool bude také citelně méně složitý na konfiguraci, než zmíněné "seriózní" servisky.
8
Sítě / Re:Wi-Fi pro dvoupatrový dům
« Poslední příspěvek od Zopper kdy Dnes v 13:03:45 »Ale MP přece říká, že reálně to nepotřebují, ale rozhodli se, že potřebují a stojí jim to za to. Stejně jako se rozhodli, že nepotřebují AP za 10 tisíc. A to je to, na čem nakonec záleží.Ta "potřeba" je záležitost subjektivní volby kombinovaná s mezním užitkem z kvality a peněz, které na ni je třeba vynaložit.
Tak proč rozporujete jejich potřebu v podobě drahého telefonu, když vzápětí tvrdíte, že je potřeba subjektivní?
Spíš to na mne působí tím klasickým dojmem, že se jim snažíte vnutit svůj pohled resp. jim podsouváte svoje potřeby.
9
Windows a jiné systémy / Re:Skok systémového času Windows
« Poslední příspěvek od František Ryšánek kdy Dnes v 12:57:33 »Nedočetl jsem se důležitou informaci: máte důvod se domnívat, že ten VMware (hypervizor) má správný čas?
Díval jste se? Bere si ho odněkud přes NTP?
Dál bych zkoumal, zda nemám náhodou povolené dva (či více) mechanismy, aby mi konfigurovaly čas v guest-side OS.
Servisky dolaďující čas toto obvykle činí dolaďováním rychlosti běhu (="frekvence") softwarové časové základny. Pokud se začnou dvě různé zpětnovazební smyčky "pravidelně přetahovat o kormidlo", můžou být výsledky zajímavé.
Nebo jedna smyčka dolaďuje frekvenci, a druhý kousek softwaru dolaďuje periodicky skokem na chybný čas...
Doladění skokem je z hlediska best practices v oboru časomíry nešťastné řešení, ale při velkém rozdílu asi jediné správné.
Tzn. zatím by se hypoteticky mohlo jednat o soupeření mezi nativní MS serviskou w32time (která může brát buď NTP, nebo páchá zmíněný "Secure Time Seeding" ze SSL), vs. VMware Tools.
Kromě toho si guest OS při startu bere čas z emulovaného RTC, jak už tu správně psal Filip Jirsák.
Vrtá mi hlavou, jestli Vám tam běží nějaký další nespecifikovaný software, zda se třeba nesnaží ještě taky po svém zasahovat do systémového času - to už je na Vás.
Dále, pokud by se stalo, že daný VM guest je v nějakých časových periodách držen hodně zkrátka co do přístupu ke strojovému času hostitelova CPU, takže mu softwarová časová základna běží pomaleji, než si třeba v lepších časech nakalibroval, velmi teoreticky by to taky mohlo vést k následným skokovým korekcím...
Neznám VMware. Třeba KVM+QEMU umí guestovi exportovat emulované fyzické hodiny "PHC", pro které je tuším guest-side virtio ovladač. Následně linuxový guest umí toto "autoritativní PHC" využít k doladění své softwarové časové základny, asi by podle toho uměl běžet i ntpd v guestově OS apod. Windows jsou v této oblasti za linuxovým světem vývojově pozadu, ale postupně to zaostávání dotahují. Nedávno přibyla podpora PTP (konkrétní profile), tuším i zárodek podpory pro HW timestamping v síťových kartách, nevím jak obecnější podpora PHC.
Díval jste se? Bere si ho odněkud přes NTP?
Dál bych zkoumal, zda nemám náhodou povolené dva (či více) mechanismy, aby mi konfigurovaly čas v guest-side OS.
Servisky dolaďující čas toto obvykle činí dolaďováním rychlosti běhu (="frekvence") softwarové časové základny. Pokud se začnou dvě různé zpětnovazební smyčky "pravidelně přetahovat o kormidlo", můžou být výsledky zajímavé.
Nebo jedna smyčka dolaďuje frekvenci, a druhý kousek softwaru dolaďuje periodicky skokem na chybný čas...
Doladění skokem je z hlediska best practices v oboru časomíry nešťastné řešení, ale při velkém rozdílu asi jediné správné.
Tzn. zatím by se hypoteticky mohlo jednat o soupeření mezi nativní MS serviskou w32time (která může brát buď NTP, nebo páchá zmíněný "Secure Time Seeding" ze SSL), vs. VMware Tools.
Kromě toho si guest OS při startu bere čas z emulovaného RTC, jak už tu správně psal Filip Jirsák.
Vrtá mi hlavou, jestli Vám tam běží nějaký další nespecifikovaný software, zda se třeba nesnaží ještě taky po svém zasahovat do systémového času - to už je na Vás.
Dále, pokud by se stalo, že daný VM guest je v nějakých časových periodách držen hodně zkrátka co do přístupu ke strojovému času hostitelova CPU, takže mu softwarová časová základna běží pomaleji, než si třeba v lepších časech nakalibroval, velmi teoreticky by to taky mohlo vést k následným skokovým korekcím...
Neznám VMware. Třeba KVM+QEMU umí guestovi exportovat emulované fyzické hodiny "PHC", pro které je tuším guest-side virtio ovladač. Následně linuxový guest umí toto "autoritativní PHC" využít k doladění své softwarové časové základny, asi by podle toho uměl běžet i ntpd v guestově OS apod. Windows jsou v této oblasti za linuxovým světem vývojově pozadu, ale postupně to zaostávání dotahují. Nedávno přibyla podpora PTP (konkrétní profile), tuším i zárodek podpory pro HW timestamping v síťových kartách, nevím jak obecnější podpora PHC.
10
Windows a jiné systémy / Re:Skok systémového času Windows
« Poslední příspěvek od MarekKnapek kdy Dnes v 12:50:45 »Na Windows (uvnitř QEMU+KVM) používám tohle, mohlo by pomoci. https://www.timesynctool.com/
