-
Data: 2017-05-26 12:52:55
Temat: Re: Źródła czasu -- kolejność padania
Od: "HF5BS" <h...@...pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]
Użytkownik "Piotr Wyderski" <p...@n...mil> napisał w wiadomości
news:og4sje$nmn$1@node2.news.atman.pl...
> HF5BS wrote:
>
>> To może własny zegar atomowy/cezowy/rubidowy?
>
> To nie wychodzi wcale tak drogo, za kilkaset dolców można mieć
> wzorzec rubidowy. Cezowy to inna półka, nie do zastosowań domowych.
No... zdaję sobie sprawę, że nic wiecznego nic wiecznego nie ma. Choćby i
zmęczenie materiału, czy jego płynięcie.
>
> Tylko one mają dwie wady: potrzebują sporo energii i się szybko
To płachta jakaś z fotoogniw, najwyżej pójdzie się do kiosku po nową
baterię, jak się stara zużyje, dla pewności przynajmniej dwie-trzy, aby w
razie padu jednej, pozostałe chociaż przez chwilę to utrzymały.
> zużywają (patrząc na to w skali kilkudziesięciu lat). Kwarc przy
Ano... to też zdywersyfikować i jechać na przynajmniej dwa zegary. Jak jeden
powie, że za chwilę umrze... albo i nie powie, tylko padnie, to drugi
powinien to jakiś czas podtrzymać, zanim wróci ten drugi, lub zostanie czymś
zastąpiony.
> braku drgań jest przewidywalny, rezonator widełkowy będzie działał
> i za 100 lat.
Cóż... albo tanio, albo dobrze, coś kosztem czegoś...
>
>>i/lub zrobić to tak, że czasu nie podawać
>> bezpośrednio, tylko zrobić coś, co będzie jakby interfejsem, co
>> pozwoliło by, w razie przepadku jednego źródła, móc przekształcić
>> protokół nowego do postaci strawnej dla starego, dzięki czemu żródeł
>> można by sobie narobić i pierdylion, wystarczyło by wtedy
>> "przetłumaczyć" ich dane, na postać dotychczas stosowaną; ze źródła,
>> które lepsze, bądź wygodniejsze.
>
> To jest unikanie problemu, choć w praktyce może się okazać nadzwyczaj
> skuteczne. :-)
Nie... nie chcę tu unikać problemu, tylko wyjść na przeciw sytuacji, że nowe
źródła mogą się okazać znacznie lepsze I TRWALSZE, wiążąc na sztywno stare
źródło z urządzeniem, czynimy sobie trudność, gdzie musielibyśmy bujać się z
czymś, co stare, najprawdopodobniej już nie produkowane, kosztowne w
utrzymaniu i niepewne. A tak, mając interfejs, zachowujemy integralność
systemu na ruski miesiąc (w samym systemie, jeśli się da, to oczywiście, też
jakieś źródełko, ale nie jako jedyne), może to sobie stać choćby w samym
piekle w pieczarze Diabła Naczelnego, a my sobie na spokojnie, "nie wiedząc"
o piekle, zmieniamy peryferia, nie ruszając samego systemu. Przekładanie
danych różnych źródeł na jednolity format ma właśnie temu służyć, żeby nie
trzeba było w samym systemie już nic robić, a w razie zmiany formatu źródła
nie być tym ograniczonym, w razie nowe źródło - siadamy do kompilatora,
tłuczemy te parę linijek programu do interfejsu i po bólu, wszystko nadal
bangla.
Ja sobie pomyślałem o jeszcze jednym źródle - o Księżycu, ale nie w sensie
zaćmiony, w której fazie, etc. tylko o jego obecności, lub nie, na
horyzoncie.
Zgodnie z prawem powszechnego ciążenia, Ziemia i Księżyc oddziałują na
siebie, a jako, że to są wektory, wystarczyło by mierzyć ich wypadkową,
okres obiegu księżyca wokół ziemi jest dokładnie znany, w związku z czym,
nawet, jakby zaliczyć potężną zgubę w odmierzaniu czasu, wystarczyło by
określić, ile razy Łysy w tym czasie okrążył Ziemię, z wartości wektora, w
powiązaniu z położeniem na firmamencie wyliczyć DOKŁADNY czas. Maszyny są
mocne, wystarczy azymut i elewacja, nasz wektor, podstawiamy do odpowiednich
wzorów i wydaje mi się, że mamy wystarczająco dokładny czas, którym możemy
zsynchronizować system. Pozostaje tylko problem w miarę dokładnego
zmierzenia wektora ciążenia, ale to chyba nie takie bolesne do zrobienia?
Może i nie tanie, ale połączenie pomiaru wektora, z wyznaczeniem dokładnego
położenia, mogło by być ciekawe i całkiem przyzwoite.
Przecież już starożytni potrafili pewne rzeczy obliczyć całkiem dokładnie,
czemu by nie wykorzystać tu matematyki, a fizyką jedynie się wesprzeć?
--
"Jeśli przyjmiesz do siebie zabiedzonego psa i sprawisz,
że zacznie mu się dobrze powodzić - nie ugryzie cię.
Na tym polega zasadnicza różnica między psem a człowiekiem"
(C) Mark Twain
Następne wpisy z tego wątku
- 26.05.17 13:08 HF5BS
- 26.05.17 13:08 Piotr Gałka
- 26.05.17 13:18 HF5BS
- 26.05.17 13:32 Jarosław Sokołowski
- 26.05.17 13:32 Jarosław Sokołowski
- 26.05.17 13:34 Jarosław Sokołowski
- 26.05.17 14:15 robot
- 26.05.17 14:51 Marek
- 26.05.17 16:50 Paweł Pawłowicz
- 26.05.17 17:26 Jarosław Sokołowski
- 26.05.17 20:38 Zenek Kapelinder
- 26.05.17 21:09 badworm
- 26.05.17 21:37 Sebastian Biały
- 26.05.17 22:02 Zenek Kapelinder
- 27.05.17 07:08 slawek
Najnowsze wątki z tej grupy
- karta parkingowa
- Wl/Wyl (On/Off) bialy/niebieski
- I3C
- Pytanie o transformator do dzwonka
- międzymordzie USB 3.2 jako 2.0
- elektronicy powinni pomysleć o karierze elektryka
- jak szybko plynie prad
- Płytki Milkv-Duo
- Światłowód między budynkami
- POtrzebny bufor 3.3<>5V, jedonkieruowy, trójstanowy, wąski
- retro
- Bezprzewodowe polączenie Windows z projektorem
- rozklejanie obudowy
- Prośba o identyfikację komponentu
- Smart gniazdko straciło na zasięgu wifi?
Najnowsze wątki
- 2024-11-14 Dobra zmiana
- 2024-11-14 Czy prezydent może ułaskawić od zadośćuczynienia? [A. Lepper odszkodowania]
- 2024-11-14 Gliwice => Network Systems Administrator (IT Expert) <=
- 2024-11-14 Gliwice => Administrator Systemów Sieciowych (Ekspert IT) <=
- 2024-11-13 Filtr do pompy ruskiej
- 2024-11-12 Gdzie kosz?
- 2024-11-13 elektrycznie
- 2024-11-12 Jebane kurwa, kurwy.
- 2024-11-13 karta parkingowa
- 2024-11-13 Wl/Wyl (On/Off) bialy/niebieski
- 2024-11-12 I3C
- 2024-11-13 Kraków => DevOps Engineer (Junior or Regular level) <=
- 2024-11-13 Łódź => Senior SAP HANA Developer <=
- 2024-11-13 Zabrze => Senior PHP Symfony Developer <=
- 2024-11-13 Karlino => Konsultant wewnętrzny SAP (FI/CO) <=