Det vil ta over ett år før vi har all Pluto-dataen fra New Horizons

[Joachim_F]

Fysikkens lover er noe herk.

Det vil ta over ett år før vi har all Pluto-dataen fra New Horizons

[Gjest Slettet-Pqy3rC]

Men siden lyset bruker over 4,5 timer på å reise mellom New Horizons og de gigantiske antennene man bruker på motta sendingene her på Jorden, tar det sin tid.

Vel, høy "ping" er ikke det samme som båndbredde.

 

Hadde båndbredden vært stor nok ville en hatt alle data etter 4,5001 timer, så det er nok mer enn avstanden alene som utgjør tiden det tar å foreta nedlastingen. Utfordringen er at DSN (deep space network) også benyttes til andre ting, så en må be om data fra New Horizon i puljer. Hver melding om å sende tar 4,5 på å nå frem og så nye 4,5 timer før datapakkene dukker opp. Båndbredden er i tillegg lav for å spare energi  (dette er også litt av grunnen til å ta pauser).

 

New Horizon som CS:GO server hadde gitt relativt utfordrende, og langvarige, runder.

Endret 8. september 2015 av Slettet-Pqy3rC

[magne.moe]

Hovedproblemet er den lave båndbredden, denne kommer av at signalet er svakt og lite kommer frem til jorden.

Alt går batchvis så lang ping er ikke så viktig om et teleskop som skulle mota signalet går ned ber du den bare sende det segmented på nytt neste dag.

[Mannen med ljåen]

Dette får EDGE fra Telenor til å fremstå som brukbart.

[Simen1]

Båndbredden er vistnok på opp mot 4 kbit/s (0,5 kByte/s) på det beste. Det vil si når jorda har rotert sånn at New Horizons er nært senit fra antenna som laster ned data. Gjennomsnittshastigheten skal vistnok ligge på 1 kbit/s med begge antennehodene aktivert. Men energikilden RTG blir gradvis svakere sånn at man ganske snart må slå av den ene av de to antennehodene. Da halveres båndbredden til 0,5 kbit/s i gjennomsnitt og 2 kbit/s maksimalt. New Horizons har to fulle 8 GB SSDer, der den ene er backup av den andre. Nedlastingen kan foregå inntil ca 8 timer i døgnet når Pluto er godt over horisonten sett fra antenna som benyttes. Dataene komprimeres før de sendes over.

[Gjest Slettet-RnjNn5NbHl]

Dette får EDGE fra Telenor til å fremstå som brukbart.

men EDGE fra netcom framstår fortsatt som ubrukelig.

Endret 8. september 2015 av Slettet-RnjNn5NbHl

[tommyb]

Håper den ikke bruker for mye tid på å vente på ACK :g

[ATWindsor]

Håper den ikke bruker for mye tid på å vente på ACK :g

 

Lurte litt på dette selv, hvordan gjøres dette for denne type overføringer. Har man ekstra mye error-check, og ber om resend for de pakkene som eventuelt er herpa helt til slutt, en annen smartere løsning?

 

AtW

[Gjest Slettet-Pqy3rC]

Lurte litt på dette selv, hvordan gjøres dette for denne type overføringer. Har man ekstra mye error-check, og ber om resend for de pakkene som eventuelt er herpa helt til slutt, en annen smartere løsning?

Jeg vet at det er brukt minimalt med CRC i lignende prosjekter tidligere. Grunnen er at data analyseres nøye uansett at en vil oppdage feil mer eller mindre manuelt. Disse folka er vant til at instrumentering ikke er 100% stabile (dvs korrekt overføring av feilmålinger), mange korringeringer må gjøres uansett.

Selv pakker med CRC feil ble vurdert før en avgjorde om det var noe poeng med re-sending. F.eks om feilen ligger i en helt mørk del av et bilde er liten vits å be om data en gang til.

 

Så; Sonden sender noen pakker - Analyse - Evt be om noen pakker på nytt om nødvendig. Ingen automatikk.

[tommyb]

Makes sense. Det ville uansett virke mer fornuftig å sende en enveisstrøm av store chunker og eventuelt bestille noen chunker om igjen, enn å bruke TCP-like mekanismer for å bekrefte mottatt data. Å spesifisere retransmisjon helt ned på minneadresse vil vel gi den mest gjerrige bruken av båndbredde. 

 

Det jeg først tenkte var at de kanskje sendte data på en måte hvor feilsjekkingen har grunnlag for å gjenskape innholdet, men det ville bruke mer båndbredde. Ikke så mye som å sende to identiske strømmer, kanskje, men likevel mer enn å bare bestille de uforståelige chunkene med data på nytt. 

Endret 8. september 2015 av tommyb