----------------------------------- romh 11 Iun 2025 16:19 ----------------------------------- Poate ca lucrurile sunt mai complicate de atat dar incerc sa simplific... Un calculator are intr-adevar un ceas, si face o poza la un anumit moment de timp... Dar cat de precis este timpul calculatorului este o alta discutie... Calculatorul are un ceas pe placa de baza, modul RTC, format dintr-un disc de cuart sau alt material care oscileaza de cateva miliaone sau miliarde de ori pe secunda(am spus asta odata in discutiile cu dom Iacob...). Cand calculatorul este deschis, sistemul de operare citeste timpul de la ceasul asta RTC, apoi atata timp cat calculatorul este in priza, ceasul de sistem(al sistemului de operare) este incrementat... de cate ori... pai in functie de frecventa cu care lucreaza modulul asta.. Daca modulul oscilator are o frecventa de 1 Ghz, apoi acesta oscileaza de un miliard de ori pe secunda, adica la fiecare ciclu al acestui disc de cuart, sistemul de operare incrementeaza ceasul de sistem cu inca o nanosecunda. Si in modul asta, cand programul care face poza, trebuie sa asocieze un timp pozei, pt ca vezi bine, vrea sa raporteze observatia la MCP sau in alta parte, cere de la sistemul de operare timpul... Sistemul de operare raporteaza timpul de sistem, adica timpul RTC cand a fost aprins calculatorul plus cate miliarde de cicluri au trecut de atunci. Problema apare pt ca nu intotdeauna modulul oscileaza cu exact 1 Ghz... Sistemele de operare au diferite nivele de consum energetic, poate ca ati observat la linux sau windows sunt politicile de consum energetic, Battery Saver, Balanced si Performance... Aceste nivele de consum energetic sunt asociate cu anumite stari ale procesorului (cstates). Asta inseamna ca modulul oscilator o sa aiba o frecventa mai mica si timpul o sa fie mai imprecis. Ai putea desigur sa obligi procesoarele statiilor sa lucreze in starea C0 pt precizie mai mare, apoi odata la 3 ani sa le schimbi procesoarele pt ca se uzeaza, sau sa asociezi anumite prioritati de sistem si parametri de sistem pt anumite procese dar tot s-ar aduna in timp decalaje. La asta folosesc protocoalele astea NTP care apeleaza periodic un server-ceas prin internet si sincronizeaza ceasul de sistem cu acel server. In mod normal sunt cateva milisecunde diferenta dar poate ca schimband anumiti parametri, adica interogand periodic odata la 10 secudne se pot obtine si cateva zeci de microsecunde daca nu trage lumea torente sau nu vizualizeaza tiktok si dezbateri electorale... Nu am verificat asiduu... Deci eu ma intreb cat de precisa este traiectoria meteoritului, adica daca renclod si quasar vor sa caute acest meteorit, ce suprafata trebuie sa acopere ei - sute de metri sau kilometri patrati? ma gandesc ca in functie de erorile de masurare asta se poate estima... Deci ai avea cel putin doua statii care fac doua masuratori independente cu o eroare proprie, pe baza carora trebuie sa reconstruiesti o traiectorie... Statiile sunt sincronizate prin protocol NTP cu un server-ceas si sa zicem ca sunt destul de precise, cateva zeci de microsecunde. ma gandesc ca o alta sursa de eroare poate fi rezolutia camerei. Citesc ca se folosesc CCD de 1.2 Mp ... ok... poate ca NTP este suficient. Banuiesc ca in funcie de frame-rateul camerei, un meteorit nu travrseaza o distanta mare in 20 microsecunde... Ah, vad acuma ca e 30 fps ... deci acuratetea timpului nu ar ajuta precizia in acest caz... NTP este mai mult decat suficient... In orice caz sincronizarea(timpului) statiilor intr-un cluster este o problema majora si bine stiuta. Daca aceasta problema nu conteaza aici este doar pt ca alte lucruri o fac redundanta la care autorii probabil s-au gandit.... Ma gandesc ca si o camera CMOS de rezolutie mare si fps mare ar fi tot utila aici... Vad multe modele de camere cmos cu fps mare si nu inteleg cine le utilizeaza si unde/ Dar asta sunt doar niste ganduri, am simplificat multe lucruri si posibil sa fif acut niste greseli.