Superrask opp/nedlasting over internett mulig?

[Hoax]

Jeg har testet overføringshastigheten med en kamerat som sendte meg en fil på 1GB som bare tok 6 minutter å hente fra han. Vi hadde 1024/512 ADSL under overføringen.

 

Dette var en "Fake fil" (Vellkjent begep for de av dere som laster ned ting med DC++ og Emule lignende programmer vil jeg tro) Denne filen er en eneste stor fil som ikke inneholder annen data enn "0" såvidt jeg har forstått.

 

Tanken som slo meg senere da jeg kom til å tenke på at f.eks rar og zip filer helt basic består av bare "0" og "1" Så hva med å sende filens "0"er først så sende "1"ere i neste "Fake fil" å på en måte bruke et programm som putter "1"ere der de skal være for å få den komplette filen, pakke ut og kjøre i gang.

 

 

Er jeg helt på feil villspor nå eller?

[_Xorcist]

Problemet er jo at du må ha en fil som beskriver hvor alle 0 og 1 skal puttes og det vil jo kreve like stor plass som den opprinnelige fila.

[Hoax]

Jo men når det ER mulig å sende så stor fil så fort så må det jo gå ann å utnytte på en eller annen måte, det er noe noen ikke har tenkt på

[Vannpistol]

Nei, dette er allerede tenkt på. Det kalles kompresjon .

 

Du kan f.eks kompimere et par TB med 0data til -veldig- små filer. Dette fungerer rett og slett ikke på ekte data.

 

Google er din venn, søk her etter hvordan lossless datakomprimering fungerer.

[Folo]

Det tar altså 6 minutter å sende en fil som ser ut som 1GB. For filen er ikke 1GB så det går ikke å utnytte dette.

[guge]

Jo men når det ER mulig å sende så stor fil så fort så må det jo gå ann å utnytte på en eller annen måte, det er noe noen ikke har tenkt på

_Xorcist har rett, det blir like dumt som å presentere en haug med sagspon som flatpakket kaffebord. Monteringsbeskrivelsen ville blitt større enn bordet:

 

"Trinn 4891234: Spon nr. 981236B limes til 98236A slik at kantene XI og XVI møtes....."

 

Det eneste slike 1GB på 6 minutter overføringer kan brukes til er salg.

 

I virkeligheten vil 1GB på 6 minutter bety en båndbredde på 2 982 616 Byte/sekund. Det er ca 30 megabit pr sekund hvis vi regner med litt protokoll-overhead. Foreslår at dere prøver med en litt mindre faket fil neste gang. Lag foreksempel et program som fyller opp med tilfeldige tall!

 

Så en saklig opplysning: De siste versjonene av NTFS kan operere noe som kalles "sparse files". Det er filer som stort sett bare inneholder nuller. Hvis du på et slikt filsystem lager en 1GB fil med bare nuller, vil den ikke oppta noe særlig plass på disken, kun en liten beskrivelse i en tabell. Hvis du derimot putter inn 1M B med ekte data midt i gigafilen vil NTFS bruke ca. 1MB plass på den. Veldig nyttig i enkelte sammenhenger.

[Culpa]

Det som skjedde var at filen ble kompriert før den ble sendt. Og pakket opp når den kom frem. I teorien kan man ha algoritmer som setter 1 og 0 på riktig plass, men muligheten for å finne en "liten" algortime som matcher din 1GB fil er veldig lik null.

 

Det er veldig mye i dag som er komprimert på ulik måte. F.eks. mp3, film (divx), bilder(jpg), filer (zip) osb. og emnet er noe av det man har jobbet mye med. Så for å komme opp med en "genial" løsning kreves det nok ganske mange år på skolebenken og videre som forsker.

 

Lykke til!

 

Den viktigste egenskapen du trenger er å være nysgjerrig.

[Globe]

det blir like dumt som å presentere en haug med sagspon som flatpakket kaffebord. Monteringsbeskrivelsen ville blitt større enn bordet

den likte eg

[durabit]

Bare prøv å pakk den fila med winzip. Da vil du oppnå det du beskrev

[Hoax]

Jo men pakke programmer gjør jo bare 010111101000010 om til 010001110 f.eks hvis jeg ikke tar mye feil. hmm jaja klør meg i skjegget og tenker videre

[jocke]

Jeg liker tanken din Hoax, men innen man har funnet en måte å gjøre dette på, sitter alle på 100mbit - og da er poenget borte

[Mosess]

Jeg liker tanken din Hoax, men innen man har funnet en måte å gjøre dette på, sitter alle på 100mbit - og da er poenget borte

Klart, men da krever en normalinstallasjon av nyeste sim-city rundt 200GiB's så da er det jo greit alikevel?

[Arne Nåtedal]

Jo men pakke programmer gjør jo bare 010111101000010 om til 010001110 f.eks hvis jeg ikke tar mye feil. hmm jaja klør meg i skjegget og tenker videre

Et pakkeformat kan i sin enkleste form se slik ut:

<byte(1)> <antall(1)>

<byte(2)> <antall(2)>

.

.

<byte(n-1)><antall(n-1)>

<byte(n)><antall(n)>

 

Inneholder fila ingen forekomster av 2 like påfølgende bytes blir den "pakkede" fila dobbelt så stor som originalen.

Inneholder den konsekvent 2 og 2 like påfølgende bytes blir pakkefila like stor som originalen.

Inneholder den 3 og 3 like påfølgende bytes blir størrelsen redusert med 33% etc..

 

I eksemplet ovenfor er det forutsatt at <antall> også representeres av en byte, dette begrenser <antall> til 255. Finnes det flere påfølgende like enn 255 må de "deles" opp i flere sekvenser.

Bruker vi feks DWORD til <antall> vil en fil på 4 GB med bare nuller bli på kun 5 bytes ferdigpakket. Tilsvarende vil en slik angivelse (med kun DWORD) ikke gi noen som helst gevinst på binærfiler med masse variasjoner.

 

Dette var kun ment som et eksempel, virkelige (og effektive) pakkeprogrammer bruker flere algoritmer og tilpasser dem til innholdet i fila etter en analyse.

F.eks kan flere forekomster av samme bytesekvens på forskjellige steder i fila representeres ved at sekvensen angis én gang og at det så angis plassering (offset) for de forskjellige forekomstene i fila.

[Zenit]

Jo men pakke programmer gjør jo bare 010111101000010 om til 010001110 f.eks hvis jeg ikke tar mye feil. hmm jaja klør meg i skjegget og tenker videre

Du kan si at hver byte i filen blir omkodet slik at den tar mindre plass. I praksis brukes en algoritme som benytter seg av en intern datastruktur, f.eks et Huffman-tre. Her er blir det gjort slik at de tegnene som forekommer oftest får kortest binære koder og på den måten sparer man plass. Ved dekomprimering kan treet traverseres for å få tilbake originalen. Det vil da fungere som en "beskrivelse".

 

Her er en beskrivelse av Huffman-trær brukt i datakompresjon:

 

http://www.iu.hio.no/~ulfu/appolonius/e-bo...p5/4/kap54.html

[D_KILLAH]

Siden komprimering bygger på at når det i en fil f.eks kommer 16 nuller etter hverandrre sender den det som 16x0 (forenklet)

 

men siden at f.eks. rar komprimerer dataene så har dne allerede komprimert dataene og man skal lete en stund etteer en lettere måte å skrive 16x0 (vi har ikke de oprinnelige 16 0-ene

[guge]

Du kan si at hver byte i filen blir omkodet slik at den tar mindre plass. I praksis brukes en algoritme som benytter seg av en intern datastruktur, f.eks et Huffman-tre. Her er blir det gjort slik at de tegnene som forekommer oftest får kortest binære koder og på den måten sparer man plass. Ved dekomprimering kan treet traverseres for å få tilbake originalen. Det vil da fungere som en "beskrivelse".

 

Her er en beskrivelse av Huffman-trær brukt i datakompresjon:

 

http://www.iu.hio.no/~ulfu/appolonius/e-bo...p5/4/kap54.html

Bra link Zenit.

 

Man kan også tenke seg at huffmann-treet ikke bør se bare på hvilke bytes som kommer oftest, men også hvilke byte-kombinasjoner med 2, 3, 4 eller flere bytes som gjentar seg.

 

Et tankeeksperiment:

Vi lager en fil med tilfeldige bytes slik at huffmann ikke klarer å komprimere noe særlig. Så tar vi den fila og skjøter på en kopi av fila slik at den første halvdelen er identisk med den første. Nå vet vi at fila bør la seg komprimere 50%. Hvilket komprimeringsprogram vil oppdage dette?

 

Svaret er at bare komprimeringsprogrammer som bruker masse prosessortid på å analysere data vil kunne komprimere optimalt.

 

I praksis er alltid komprimering en avveining mellom prosessorkraft, forutsigbarhet og plasskostnad!

 

Dersom man bruker huffmann på en tilfeldig fil vil resultatfilen faktisk bli større! Dette fordi huffmanntreet også må lagres. Det kalles overhead.

[RickRoll]

Hvis ikke jeg husker helt feil så har (hadde?) Telenor automatisk datakompresjon i alle fall på isdn linjene. Noen som kan bekrefte/avkrefte dette?

 

EDIT: Skriveleif (ja, det er jo bestandig noen)

Endret 25. mai 2004 av l_samu

[Hoax]

Telenor hadde ISDN Turbo ja, økt datakompresjons protokoll eller noe som man kunne legge til ja

[Kim0]

Komprimering er fascinerende greier. F.eks. er det bevist at man aldri kan bli sikker på om man har funnet beste komprimering. Det er alltid en mulighet for at det kan finnes en enda bedre måte å komprimere på.

 

Angående hvorfor denne trådens kompresjon er umulig.

 

La oss si at man har 000 og 11111. Disse kan være kompresjon av

både 01101011 og 11111000, og mange flere. Det er altså flertydig. Man har tapt informasjon.

[Folo]

Det jeg kunne tenke meg å se er filmer komprimert i mindre størrelser.

Ettersom de fleste filmer er widescreen, er det mye unødvendig data som ligger i de svarte feltene. Da disse er gjennomgående svarte i alle widescreen filmer vil det jo egentlig ikke være nødvendig å ha de med. Så vist det ikke er slik video komprimeringen fungerer i dag vil jo kanskje dette gi litt mindre filmer? Kanskje konstant svart allerede bruker lite plass?