67 odpowiedzi w tym temacie

[Ironmacko]

Striker, trochę rzeczy powinieneś sobie poukładać bo chyba za bardzo dałeś się wciągnąć w tzw: wyścig herców:

- po pierwsze pisanie, że film jakości blue-ray o pojemności 20GB da się skompresować bez strat do powiedzmy 1gb jest błędem, to samo tyczy się obrazów RAW do JPG. Zdjęcia i filmy przesyłane są na Ziemie w najwyższej możliwej jakości, bez żadnej kompresji.

- dwa, współczesne programy są pełne wodotrysków (czytaj: masą grafiki), która w kosmosie nie ma zastosowania, tam mają być wykonane komendy i interfejs graficzny tam nie występuje. tutaj dochodzimy do podstawowego pytania: co maja robić procesory w czasie misji kosmicznej:

Ich głównym zadaniem jest wydawanie komend poszczególnym podzespołom i uwierz to czy zadzieje się to w 1milisekundę czy w nawet w 20 nie ma kompletnie żadnego znaczenia, ponieważ obliczenia co do zmiany np. kursu wyliczane są na Ziemi (nigdy moc komputerów pokładowych nie dorówna mocy komputerów na Ziemi) i przesyłane do satelitów z instrukcją kiedy maja zostać zastosowane (można nawet obliczyć potrzebne opóźnienie dla danego procesora)

Takich kwiatków jest bardzo dużo. Ale żeby to jakoś zebrać w całość: procesory w kosmosie muszą być tak skonstruowane aby stosunek ich wydajności to zużycia energii był jak najwyższy. Obrazując to zdanie: procesor musi pracować jak najbliżej granicy 100% przy możliwie najniższym zużyciu energii. Nasze domowe komputery to przykład marnotrawstwa, ja w tym momencie wykorzystuje może 2% mocy obliczeniowej, a zużywam jakieś 350W energii, to samo mógłbym robić na komputerze 286, tracąc 20W albo jeszcze mniej...

[dzastin]

W sposób bezstratny da się skompresować ale na pewno nie z 20GB do 1GB.
FLAC czy APE to są chociażby formaty bezstratne do muzyki. Chyba PNG i JPEG 2000 też mają możliwość bezstratnej kompresji obrazów. MKV to akurat jest niejako "kontener" na film, ścieżki dźwiękowe do niego, napisy itd i może on być kompresowany różnymi kodekami, zazwyczaj stratnymi.

To co wysyłają satelity podejrzewam że jest w jakiś sposób kompresowane bezstratnie, ale taki typ kompresji ma jednak swoje ograniczenia.

[Lynx]

KOMPRESJA - procesor pakuje dane robiąc np ze 100MB -> 1MB.
Dzięki temu czas przesyłania strumienia danych jest 100 razy krótszy

Ależ dane z sond kosmicznych są kompresowane i to tak mocno, jak tylko się da bez utraty ich jakości. Ponadto w twoich wypowiedziach widzę kilka pułapek myślowych.

Przede wszystkim stopień kompresji danych zależy od przyjętego algorytmu, a nie od szybkości procesora. Rozumiem, że domagając się szybszego procesora chcesz, aby algorytm był wykonywany jak najszybciej, najlepiej w ułamku sekundy, ale popełniasz kolejny błąd wyobrażając sobie, że dane błyskawicznie skompresowane np. na Marsie równie błyskawicznie znajdą się na Ziemi. Zupełnie jakbyś zapomniał o kosmicznych odległościach i ograniczonej prędkości światła, na które z resztą zwrócono już tu uwagę.

Innym ograniczeniem, z którego być może nie zdajesz sobie sprawy, jest szybkość transmisji danych, uzależniona od mocy nadajnika. Dobrym przykładem może być misja łazika Curiosity na Marsie. Dane zebrane przez łazik są dostarczane na Ziemię za pośrednictwem sondy Mars Reconnaissance Orbiter (MRO), która może je przesyłać z prędkością 6 megabitów na sekundę, a więc całkiem szybko. Problem w tym że transmisja od łazika do sondy odbywa się trzy razy wolniej i ze względu na orbitę MRO jest ograniczona do 8 minut dziennie. Gdybyś wysłał tam swojego smartfona, to mógłbyś szybko kompresować duże ilości danych, ale musiałbyś też zainwestować w dodatkowe źródło zasilania i większą antenę dla usprawnienia łączności - oczywiście kosztem przyrządów badawczych, bo limit wagowy jest ograniczony.

Napisałeś o projekcie PhoneSat - i bardzo dobrze, bo to może być przyszłość technologii satelitarnej, jeśli tylko zda podstawowe testy i wyjdzie z powijaków. Ale wydaje mi się, że przyjmujesz błędne założenia co do czasu, w jakim przygotowywane są misje kosmiczne i dlatego dziwisz się, że stosuje się stary sprzęt. Opracowanie nawet najprostszej misji (choćby wysłanie balonu na wysokość kilkudziesięciu kilometrów) trwa miesiącami, a czas potrzebny na stworzenie bardziej ambitnego projektu idzie w lata, przy czym decyzje o potrzebnych komponentach podejmuje się na samym początku. Wspomniany łazik Curiosity wylądował w tym roku na Marsie mając na pokładzie sprzęt zatwierdzony 8 lat wcześniej. Już choćby z tego powodu nie można go było wyposażyć w procesor z dwuletniego smartfona ;-)

[Striker]

@wieslawo uwierz rozumiem jaki jest cel misji i nie mam na myśli żadnych "rozrywkowych" sond kosmicznych. Natomiast kompresja występuje. Sama stacja jak by zaczęła wysyłać nieskompresowane dane to trwałoby to bardzo długo.

@Ironmacko - wiem doskonale, że większość formatów jest stratna ale podałem też przykład zwykłego RAR albo ZIP. Nie jestem specjalistą od kompresji i nie wiem jakimi programami to robić ale dla NASA pracują ludzie którzy wiedzą. Teraz do rzeczy - Sondy wyposażone są w wiele procesorów z których każdy obsługuję osobną aparaturę, a to oznacza, że jest tam sporo dodatkowych kilogramów. Ja natomiast tylko sugeruję, że zastosowanie jednego procesora z kilkoma backupami byłoby lżejsze. Nie mówiąc już o tym, że taka sonda mogłaby zabrać na pokład więcej aparatury badawczej na miejsce starych układów scalonych.

@dzastin dokładnie!

@Lynx

Przede wszystkim stopień kompresji danych zależy od przyjętego algorytmu, a nie od szybkości procesora. Rozumiem, że domagając się szybszego procesora chcesz, aby algorytm był wykonywany jak najszybciej, najlepiej w ułamku sekundy, ale popełniasz kolejny błąd wyobrażając sobie, że dane błyskawicznie skompresowane np. na Marsie równie błyskawicznie znajdą się na Ziemi. Zupełnie jakbyś zapomniał o kosmicznych odległościach i ograniczonej prędkości światła, na które z resztą zwrócono już tu uwagę.

No właśnie nie popełniam błędu - załóżmy, że dysponujemy ograniczonym łączem do np. 2mb/s i mamy 200 mb wavów do przesłania.
Jeśli zaczniemy je przesyłać łączem zajmie to bardzo długo ale jeśli skompresujemy te 200 mb wavów do 20mb np dajmy na to rarem to taką paczkę wyślemy 10 razy szybciej.

Ty wziąłeś pod uwagę tylko prędkość łącza i odległość. Ja się zastanawiałem jak upchać jak największą ilość danych w jednym pakiecie.

Innym ograniczeniem, z którego być może nie zdajesz sobie sprawy, jest szybkość transmisji danych, uzależniona od mocy nadajnika. Dobrym przykładem może być misja łazika Curiosity na Marsie. Dane zebrane przez łazik są dostarczane na Ziemię za pośrednictwem sondy Mars Reconnaissance Orbiter (MRO), która może je przesyłać z prędkością 6 megabitów na sekundę, a więc całkiem szybko. Problem w tym że transmisja od łazika do sondy odbywa się trzy razy wolniej i ze względu na orbitę MRO jest ograniczona do 8 minut dziennie. Gdybyś wysłał tam swojego smartfona, to mógłbyś szybko kompresować duże ilości danych, ale musiałbyś też zainwestować w dodatkowe źródło zasilania i większą antenę dla usprawnienia łączności - oczywiście kosztem przyrządów badawczych, bo limit wagowy jest ograniczony.

No i znowu co ma piernik do wiatraka. Co jest lepsze paczka idąca z Marsa 20 minut zawierająca 20 mb zdjęć czy paczka idąca z Marsa 20 minut i zawierająca 200 mb zdjęć skompresowanych do 20 mb?

Napisałeś o projekcie PhoneSat - i bardzo dobrze, bo to może być przyszłość technologii satelitarnej, jeśli tylko zda podstawowe testy i wyjdzie z powijaków. Ale wydaje mi się, że przyjmujesz błędne założenia co do czasu, w jakim przygotowywane są misje kosmiczne i dlatego dziwisz się, że stosuje się stary sprzęt. Opracowanie nawet najprostszej misji (choćby wysłanie balonu na wysokość kilkudziesięciu kilometrów) trwa miesiącami, a czas potrzebny na stworzenie bardziej ambitnego projektu idzie w lata, przy czym decyzje o potrzebnych komponentach podejmuje się na samym początku. Wspomniany łazik Curiosity wylądował w tym roku na Marsie mając na pokładzie sprzęt zatwierdzony 8 lat wcześniej. Już choćby z tego powodu nie można go było wyposażyć w procesor z dwuletniego smartfona ;-)

No super tylko wyobraźcie sobie, że poza łazikiem na marsie, którego produkcja trwa 8 lat na naszej orbicie chronionej przed promieniowaniem kosmicznym przez pole magnetyczne ziemi jest pełno satelitów komunikacyjnych, szpiegowskich i innego rodzaju platform, których produkcja zajmuje znacznie krócej i są łatwiej dostępne z ziemi. Zresztą dam sobie głowę uciąć, że satelity wojskowe są wyposażone w nowsze procesory.


Nadmienię tylko jedno - większość starych procesorów montuje się i to całkiem słusznie w układy sterowania pojazdami. Nie tylko w kosmosie ale też i na ziemi i tam faktycznie nic lepszego nie potrzeba. Ale, żeby aparatury zbierały ogromne ilości danych i wysyłały je na ziemie potrzebna jest kompresja. Prądu tutaj nie biorę pod uwagę ale nawet tutaj miniaturyzacja może oznacza mniejsze zużycie.

[dzastin]

Oczywiście, że teoretycznie przy lepszym procesorze można by zastosować bardziej algorytm kompresji bezstratnej, i mniejszy plik zostanie szybciej odebrany.
Tyle, że w NASA pracują tęgie głowy, i z naszego punktu siedzenia możemy się dziwić czemu nie wcisną do łazika lepszego procka, ale oni już chyba lepiej wiedzą jak znaleźć kompromis między wydajnością, niezawodnością a poborem mocy. Bo przy takiej misji to ważniejsza jest niezawodność.

[Lynx]

Ja się zastanawiałem jak upchać jak największą ilość danych w jednym pakiecie.

To dlaczego w kółko nawijałeś o szybszych procesorach, zamiast skoncentrować się na algorytmach kompresji? Jak już wspomniałem, to od algorytmu zależy, jaki ostateczny rozmiar będą miały przesyłane dane.

[Striker]

Ja się zastanawiałem jak upchać jak największą ilość danych w jednym pakiecie.

To dlaczego w kółko nawijałeś o szybszych procesorach, zamiast skoncentrować się na algorytmach kompresji? Jak już wspomniałem, to od algorytmu zależy, jaki ostateczny rozmiar będą miały przesyłane dane.

Może dlatego, że algorytmu już mamy, a brakuje tylko procesorów które szybciej wykonają polecenia?

[Lynx]

Więc teraz już nie chodzi ci o rozmiar spakowanych danych, tylko o szybkość kompresowania? Trudno za tobą nadążyć.

[Striker]

Więc teraz już nie chodzi ci o rozmiar spakowanych danych, tylko o szybkość kompresowania? Trudno za tobą nadążyć.

Powiedz mi Lynx co jest Ci tak trudno zrozumieć? Czepiasz się tylko żeby się czepiać? Bo ja to już wyjaśniałem to dosyć dokładnie. Chyba, że mózg Ci prawidłowo nie funkcjonuje i nie rozumiesz tego co wszyscy już przed Tobą zrozumieli.

Łopatologicznie - Dane płyną strumieniem. Satelita nagrywa, kompresuje i przesyła cały czas nieprzerwanie. Mocny procesor jest potrzebny po to aby szybko i skutecznie kompresować dane.

Bardzo dobry i prosty algorytm ma rar lub zip - spakuj sobie 300 mega na komputerze zasilanym procesorem x486 i na współczesnym PC - ja akurat od x486 zaczynałem i pracowałem w DOS gdzie nie było grafiki. Ponieważ kiedyś nie było CD całymi dniami używaliśmy kompresji ZIP i RAR aby kompresować gry i muzykę na pliki dyskietki o pojemności 1,44 mb.

Dalej odpowiadając na Twoją zaczepkę wyobraź sobie, że RAR albo ZIP mają jakości kompresji. Chcesz mieć mocno skompresowany plik to jego rozmiar będzie większy ale czas przeprowadzenia kompresji będzie dłuższy niż standardowej kompresji która będzie miała większy rozmiar ale za to jej proces będzie krótszy. Proces można przyśpieszyć tylko sprzętowo czyli procesorem potrafiącym wykonać większą ilość obliczeń.

Powiem Ci, że dużo szybciej jest dzisiaj spakować 300 mega niż wtedy. W dodatku dzisiejsze 300 mega można dużo bardziej spakować niż wtedy.

Więc albo jesteś totalnym ignorantem i nie przeczytałeś kompletnie niczego w tym temacie albo prowokatorem tak czy inaczej minus za prowokacje.


Proponuje trochę spokojniej w każdej dyskusji traktujmy się jak dorośli... - Iron

[Ironmacko]

[...]
@Ironmacko - wiem doskonale, że większość formatów jest stratna ale podałem też przykład zwykłego RAR albo ZIP. Nie jestem specjalistą od kompresji i nie wiem jakimi programami to robić ale dla NASA pracują ludzie którzy wiedzą. Teraz do rzeczy - Sondy wyposażone są w wiele procesorów z których każdy obsługuję osobną aparaturę, a to oznacza, że jest tam sporo dodatkowych kilogramów. Ja natomiast tylko sugeruję, że zastosowanie jednego procesora z kilkoma backupami byłoby lżejsze. Nie mówiąc już o tym, że taka sonda mogłaby zabrać na pokład więcej aparatury badawczej na miejsce starych układów scalonych.

A nie uważasz, że z rozsądku lepiej mieć 10 fizycznie różnych procesorów, niż jeden? Przecież skazujesz się na totalną klapę jeśli pójdzie ten jeden, w pierwszej wersji ciągle możesz ratować misję, przecież jeszcze 9 urządzeń działa. (chyba, że dla Ciebie backup to kolejny procek..., tyle że to niczym się nie różni od kolejnych procesorów).

Jedna rzecz, której nie wyczytałeś jeszcze z mojego posta to fakt że może po prostu nie potrzeba lepszych procesorów, bo nie miałyby one co robić...

[Striker]

A nie uważasz, że z rozsądku lepiej mieć 10 fizycznie różnych procesorów, niż jeden? Przecież skazujesz się na totalną klapę jeśli pójdzie ten jeden, w pierwszej wersji ciągle możesz ratować misję, przecież jeszcze 9 urządzeń działa. (chyba, że dla Ciebie backup to kolejny procek..., tyle że to niczym się nie różni od kolejnych procesorów).

Jedna rzecz, której nie wyczytałeś jeszcze z mojego posta to fakt że może po prostu nie potrzeba lepszych procesorów, bo nie miałyby one co robić...

Backup to dla mnie kolejny procek tylko zauważ proszę, że jak pójdzie jakiś procek np od wysięgnika to potem trzeba sterować wysięgnikiem za pomocą i kosztem innego procesora, który może np służyć do sterowania rakietą - już nie mówiąc o tym, że faktycznie trzeba brać wtedy schematy i patrzeć jak tu przeprogramować nowy procesor aby sygnał szedł po konkretnych kanałach układów scalonych aż dojdzie do ramienia. W końcu ta metoda ma pewne mocne ograniczenia.

W przypadku backupu po prostu wyłączasz jeden procesor i włączasz drugi i z automatu wszystko działa. Backupów też możesz mieć dużo więcej.

Może nie potrzeba. Nie kłócę się z tym. Ale może po prostu się nie opłaca bo wzmocniony procesor RAD6000 albo Dual BAE kosztuje coś pomiędzy 200,000 a 300,000 USD.

Użytkownik Striker edytował ten post 12.12.2012 - 17:32

[Lynx]

Powiedz mi Lynx co jest Ci tak trudno zrozumieć?

Twoje przeskoki myślowe i nerwowość ;-) Według mnie ani jedno, ani drugie nie jest potrzebne w dyskusji.

Dane płyną strumieniem. Satelita nagrywa, kompresuje i przesyła cały czas nieprzerwanie. Mocny procesor jest potrzebny po to aby szybko i skutecznie kompresować dane.

Jeśliby zawęzić zastosowanie szybkich procesorów do takiego typu satelitów, jaki opisałeś, to rzeczywiście miałyby one wyraźną przewagę, choć jednocześnie trudno mi sobie wyobrazić ich (satelitów) sensowne użycie. Na myśl przychodzi mi jedynie opcja rozrywkowa w postaci filmików "na żywo" gdzieś z kosmosu. W przypadku tradycyjnych sond kosmicznych z ich limitami energii, ograniczonymi sesjami łączności itp., szybkie procesory nie miałyby już takiej przewagi.

Bardzo dobry i prosty algorytm ma rar lub zip

Kto wie, może wraz z upowszechnianiem się eksploracji kosmosu ktoś kiedyś zacznie ich używać do kompresji danych z satelitów i sond. Na razie agencje kosmiczne korzystają z bardziej wysublimowanych algorytmów - innych dla każdego rodzaju danych - opracowanych specjalnie pod używane "wolne" procesory.

[Ill]

@Striker
Wybacz, ale w niektórych miejscach wygadujesz głupoty i chyba nie masz za bardzo pojęcia w temacie.
Po pierwsze: kompresja.

Łopatologicznie - Dane płyną strumieniem. Satelita nagrywa, kompresuje i przesyła cały czas nieprzerwanie. Mocny procesor jest potrzebny po to aby szybko i skutecznie kompresować dane.

Jeśli dysponujemy łączem 6Mbit z Ziemią, to potrzebujemy procesora, który potrafi kompresować te 1.5MB/s bezstratnie. Nie ma potrzeby szybciej, bo trzeba będzie buforować coraz więcej danych. Gdzie?
Poza tym, skoro i tak nie ma ciągłej łączności z sondą na powierzchni planety, to tym bardziej nie ma sensu inwestować i procesory do szybkiej kompresji.
Lepiej, nie ma sensu w ogóle inwestować w ciężką kompresję bezstratną, bo to nieopłacalne. Lepiej jest stosować podstawową i bardzo szybką kompresję oraz zabezpieczyć poprawność transmitowanych danych.

No właśnie nie popełniam błędu - załóżmy, że dysponujemy ograniczonym łączem do np. 2mb/s i mamy 200 mb wavów do przesłania.
Jeśli zaczniemy je przesyłać łączem zajmie to bardzo długo ale jeśli skompresujemy te 200 mb wavów do 20mb np dajmy na to rarem to taką paczkę wyślemy 10 razy szybciej.

Ty wziąłeś pod uwagę tylko prędkość łącza i odległość. Ja się zastanawiałem jak upchać jak największą ilość danych w jednym pakiecie.

To trochę nie ma sensu
Silna kompresja jest kosztowna obliczeniowo i zawsze jest ograniczona entropią danych. Praktycznie nie da się kompresować zdjęć, czy dźwięku bezstratnie z takim stosunkiem jak zakładałeś, czyli jakieś 10:1. Chyba, że ciszę chcesz przesyłać, bo np. szumu praktycznie nie da się skompresować. To już nie jest kwestia mocy obliczeniowej, nawet nie jest to kwestia algorytmu. To w większości przypadków jest niemożliwe.

Btw. rar i zip są stosunkowo słabe, jeśli chodzi o kompresję. Istnieją algorytmy o znacznie silniejszym stopniu kompresji np. lzma2, ale to wymaga dużej mocy procesora i dużej ilości przydzielonej pamięci, której sonda nie ma.

Żeby nie być gołosłownym, polecenie (Linux):

tar cvf - ~/test | xz -z9e > test.tar.xz

zaalokowało 678MB pamięci i zabrało 18 minut 14 sekund czasu jednego rdzenia procesora C2D E6770 3,20GHz, gdzie testowane dane to było ok. 8 gigabajtów zdjęć w rawie. Ile czasu i energii poświęci na to sonda? I to nie jest jakiś nieoptymalny algorytm (w efekcie mamy paczkę o nieco ponad połowę mniejszą), aczkolwiek lzma2 niejako z definicji nie nadaje się to kompresji takich danych.

Bardzo dobry i prosty algorytm ma rar lub zip - spakuj sobie 300 mega na komputerze zasilanym procesorem x486 i na współczesnym PC - ja akurat od x486 zaczynałem i pracowałem w DOS gdzie nie było grafiki. Ponieważ kiedyś nie było CD całymi dniami używaliśmy kompresji ZIP i RAR aby kompresować gry i muzykę na pliki dyskietki o pojemności 1,44 mb.

Algorytmy zastosowane w tych formatach nie potrafią efektywnie kompresować muzyki ani zdjęć. Co najwyżej mogłeś stosować zipa do dzielenia archiwum na części.
Kompresja zdjęć i dźwięku, a kompresja np. tekstu, to są dwie zupełnie różne bajki. RAR i ZIP nadają się do tekstu i w zasadzie do niczego innego, a sonda tego raczej nie przesyła.

Więc albo jesteś totalnym ignorantem i nie przeczytałeś kompletnie niczego w tym temacie albo prowokatorem tak czy inaczej minus za prowokacje.

No kolego od zipa i rara, nie wywołuj wilka z lasu, bo ja widzę, ze ignorancją w temacie to Ty się tu popisujesz.

Btw. witam wszystkich po przerwie.
No nie wytrzymałem

Użytkownik Ill edytował ten post 12.12.2012 - 20:30

[D.K.]

Btw. rar i zip są stosunkowo słabe, jeśli chodzi o kompresję. Istnieją algorytmy o znacznie silniejszym stopniu kompresji np. lzma2, ale to wymaga dużej mocy procesora i dużej ilości przydzielonej pamięci, której sonda nie ma.

Nie zajmuję się projektowaniem sond kosmicznych, ani w ogóle tego typu zagadnieniami inżynieryjnymi, ale zdrowy rozsądek podsuwa zupełnie inne rozwiązanie, w którym moc obliczeniowa procesora nie ma najmniejszego znaczenia, a dane będą kompresowane znacznie szybciej, niż przy użyciu nawet najmocniejszego procesora dostępnego dziś na rynku. Mam na myśli kompresję sprzętową. Nie wiem, czy faktycznie stosowane są takie rozwiązania w sondach, czy ogólnie statkach lub pojazdach kosmicznych, ale wiem na pewno, że są na rynku urządzenia pozwalające kompresować i dekompresować strumień danych równolegle z przepustowością do 10GB/s albo i więcej, co dalece wykracza poza możliwości standardowych procesorów. Gzip jest dosyć przyzwoitym algorytmem, a kilka sprzętowych kompresorów w sondzie spełni z nawiązką wszelkie wymagania dotyczące kompresowania zbieranych danych.

A procesor "główny" powinien się jak na mój laicki gust zajmować nie kompresowaniem danych, tylko kontrolowaniem podległych mu systemów. Wyłączaniem niesprawnych, przełączaniem na zapasowe i uruchamianiem odpowiednich zadań (nie "wykonywaniem", tylko "uruchamianiem", czyli mówiąc prościej wysyłaniu sygnałów typu "Heniek, nie obijaj się, daj no do pieca i skręć w lewo o 3 sekundy, bo Zdzichu twierdzi, że z podporządkowanej idzie jakaś koreańska rakieta. Jak zrobisz, to daj znać."). A do tego nie potrzeba mu żadnej imponującej mocy obliczeniowej.



Chyba

[wieslawo]

niby wszystko ok, ale czy silna kompresja nie powoduje większych trudności w przypadku niekompletnego pliku? Zakładam, że słabsza kompresja pozwala dokładniej odtworzyć uszkodzone dane. Poza tym, jeżeli łazik może wysłać pakiet danych do satelity raz dziennie, to chyba nie ma powodu by musiał kompresować te dane jakoś szybko? Poza tym został już poruszony temat magazynowania danych. To kolejny problem. Jeżeli nagle na pokładzie w ciągu dnia, miałbym 20 razy więcej danych niż jest w stanie w ciągu tego dnia wysłać, to drugiego dnia ma ich 40 razy więcej a siódmego miejsce zapełnione. I teraz co? Ma się zatrzymać i będziemy czekać pół roku aż zrobi miejsce na nowe dane? Przecież to by była uber głupia misja.

Od razu zaznaczam, że nie wiem, nie pracuje tam. Ale chodzi mi po głowie myśl, że inżynierowie stawiają na niezawodność rozwiązań zamiast na chwilową szybkość. Misja na inną planetę jak już wiemy to kilka długich lat samych przygotowań. Nie chodzi przecież o to by w pierwszy miesiąc przesłał łazik z jednego miejsca mnóstwo gigabajtów zdjęć a potem na skutek usterki padł i szlag trafia misję przygotowaną przez lata a o to, by taki łazik tam badał i przemieszczał się przez jak najdłuższy czas.