Poslední příspěvky

1

Hardware / Re:Relativně přesné RTC

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

60sec za 3 roky je pro volně běžící oscilátor < 0.6ppm přesnost a stabilita, což za stabilitu splňuje třeba tenhle (ale stejně by potřeboval počáteční kalibraci, protože od výroby jen 1ppm):
https://www.sitime.com/support/resource-library/datasheets/sit7910-datasheet
Ale cenově to bude asi mnohem víc, než 500Kč.

V malém teplotním rozsahu (termostatování) by možná vyhověl i nějaký levnější, ale už to není out-of-box řešení a s nejistým výsledkem.

2

Hardware / Re:Relativně přesné RTC

« Poslední příspěvek od CPU kdy Dnes v 22:22:59 »

Měl jsem tři zařízení, která jela kupodivu poměrně hodně přesně a vypadalo to na rozdíl třeba 15 vteřin ročně, tak jsem to neřešil. Ale teď jsem dostal dalších patnáct a tady to rozcházení už je markantnější. Jak se to bude chovat dlouhodobě, tak to netuším.


 

3

Sítě / ipv6 ndp adverts vs routovaná

« Poslední příspěvek od Vietnamka kdy Dnes v 22:14:28 »

A ještě jedna věc, než ji zapomenu:jak rozumět tomuto? Pokud bych bral analogii ipv4, tak jde zda jde blok routovaný a to druhé co ? Něco jako upnp  ? Vůbec netušim

understand/im assuming that your upstream does not route the /64 directly to your host’s eth0 interface, and instead relies on NDP adverts to direct IPv6 traffic to your host. That is why you understand that each container’s IP will need to be advertised to the upstream network using proxy NDP entries on the host’s eth0 interface.

( https://discuss.linuxcontainers.org/t/ipv6-without-nat-inside-lxc-container/12238 )

4

Hardware / Re:Relativně přesné RTC

« Poslední příspěvek od ogdru6jahad kdy Dnes v 22:10:55 »

U většího počtu jednotek je málo realistické pro každou jednotku hledat vhodný offset.

a dotaz laika: a ten offset stale roste a rozchazi se vic a vic, a nebo je nekdy offset kladny, nekdy zaporny a v prumeru se nuluje? samozrejme kdyz to bude litat +/- 5 minut tak je to na nic.

5

Hardware / Re:Relativně přesné RTC

« Poslední příspěvek od CPU kdy Dnes v 22:05:41 »

Požadavek na bezpečnost je v principu uzavřená síť.

U většího počtu jednotek je málo realistické pro každou jednotku hledat vhodný offset (jako: "jednou týdně odečti 3sec"), navíc je tam teplotní závislost a dokonce i závislost na napájecím napětí (malinko, ale..). Jinými slovy, nové zařízení se na začátku rozchází o jinou hodnotu než vystárlé zařízení a jak se v průběhu roku mění teplota, mění se i ten rozdíl.

Pokud si jednou měsíčně čuchnu správný čas, jsem v principu v pohodě.

6

Hardware / Re:Relativně přesné RTC

« Poslední příspěvek od ogdru6jahad kdy Dnes v 21:55:58 »

nedavno se tu resilo radiove spojeni s nizkou rychlosti na velkou ~10km vzdalenost.
jak daleko chcete mit to zarizeni?

a s nejakym normalnim chipem je kumulativni chyba casu stale rostouci a nebo se chyby rusi a chyba lita kolem 0?

neslo by si udelal par dni statistiku s danym chipem a pokud chyba lita kolem nuly, tak by slo zmerit jaka je treba denni odchylka/chyba.
pokud chyba v case kumulativne roste, tak linearne prepocitat spatny cas pomoci spravneho casu zmereneho na zacatku a na konci.

7

Hardware / Re:Relativně přesné RTC

« Poslední příspěvek od CPU kdy Dnes v 21:51:38 »

+/- 20 sec za jak dlouho? Rozsah pracovních teplot?

Revize bude jednou za tři roky, více než minutový rozdíl je neshoda, tři minuty = problém, pět minut už je průůů.
Teploty v podstatě stabilní 10-15°C, spíš to bude ve sklepech, tam asi žádné prudké výkyvy nehrozí.

Distribuci předpokládám po LAN.
Blbý je, že běžné RTC se umí za rok rozhodit klidně o 6 minut.
No, tady se to podcenilo, ale DCF77 nebo GSM to asi dokáže vyřešit.

Dokážu si objednat ESP32 s LAN RJ45 + 2x RTC s DCF77 a pořád se vejdu do pětikila. 
Ale abych znovu nevynalézal kolo 

8

Hardware / Re:Relativně přesné RTC

« Poslední příspěvek od CFM kdy Dnes v 21:31:27 »

+/- 20 sec za jak dlouho? Rozsah pracovních teplot?

9

Hardware / Re:Relativně přesné RTC

« Poslední příspěvek od RDa kdy Dnes v 21:17:06 »

Resis blbosti, dej tam GPS a cas budes mit primo na seriaku. A ten muzes nakrmit do LORA a potahnout od prijmace pod oblohou, nekam do skryteho okoli.

Pokud ti staci +-20 sec, tak to muzes pouzit jakekoliv vestavene RTC ktere je soucasti dnes uz temer vseho. Ale pokud je instalace s vetsim rozsahem teplot, nebo pravidelnym cyklovanim, muze to ujet o dost dal.

10

Server / Re:Jednoduchši HA na Proxmox

« Poslední příspěvek od RDa kdy Dnes v 21:11:32 »

Pokud mas nejake masove nasazeni (a la FB) tak se to neresi.

Pokud mas nejake kriticke systemy, tak ty se pripojuji na vicero uzlu podle priority listu - viz napr. distribuci balicku - pokud nejede preferovany mirror, package manager to stahne z jineho (konkretne zkusenost s gentoo/portage), stejne tak distribuce seznamu (portage tree) je rsync a ma to sekundarni adresu.

Ale pokud se bavime o klasickych sluzbach (web, ftp, git, atd), tam ti pomuze leda aplikacni proxy, ktere ti presmeruje provoz na preferovany a zrovna funckcni backend. Ale zde vse, co je pred touto proxy, musi byt pripojeno spolehlive (tj nemuzes to provozovat doma).

Mi prijde ze se snazis resit velice okrajovou podminku (selhani providera, selhani distribucni site EE), namisto toho, abys umistil sve zelezo na lepsi misto (do datacentra). Na takove pofiderni reseni holt sluzby neudelas s HA, kdyz je sami nejakym zpusobem neresi.

Plus napr. pokud chces resit neco jineho nez readonly obsah (ktery muzes syncovat jednosmerne), tak se u RW obsahu (cokoliv s db, git, atd) podelas z toho jak nastavit nejaky rozumny prepnuti. Musis brat do uvahy, ze na kazde sluzbe muzes mit aktivne pracujiciho usera (treba git push, db import) a padne ti ta lokace uprostred takovych opraci. Prepnes na zalozni - a tam co.. lidi budou zrazu o tyden zpet? a pak to prepnes zas, a zmeny se ztrati. Takze pro vetsinu sluzeb je lepsi hodit nedostupno/INOP/deny a opravit si svoji jedinou lokaci.

A ted se dostavame zpet k tomu, ze muzes resit HA a proxy, a nejaky lokalni cluster, ktery prezije castecny vypadky a rebooty - to je neco co resit muzes (a mel bys) - ale pouze v ramci jedne garantovane lokace (homelab), ne roztahane skrze internet. Ze ti vypadava ISP, je neco, co resi lepsi vyber, lepsi umisteni, lepsi smlouva - a treba SLA.

Alternativne muzes jit do dvou ISP, a tu aplikacni proxy (anebo pouze vpn+nat) si dat na VPS, aby vyuzivala zrovna funkcni cestu k tvemu homelab backendu.