Konspirationsteorier!!

Vi sidder helt sikkert allesammen inde med en masse små, underlige og finurlige konspirationsteorier mod alverdens megavirksomheder eller andre relevante organistationer...

Denne tråd er dog ikke for de kedelige månelandings teorier, eller at Bush i virkeligheden er et sterinlys, men for de helt basale, små og underlige teorier som man går og gruer over i hverdagen... Såsom denne:

Konspirationsteori nummer 1:
Jeg oplever jævnligt, at hastigheden på vores internet pludseligt stiger ret meget, fra en normal download hastighed i transmission på 256 kb/s til 460-500 kb/s... Disse hastighedsforøgelser hænger mystisk sammen med, at de komme når der også er reklamer fra Comx (som vi altså får internet af) i mailboxen....!
Altså, frister ComX med høje hastigheder i deres mail, samtidig med at man synes det er fedt at ens hastighed bliver fordoblet!

Min papfar har lavet følgende konspiration:

TDC bombede WTC så de kunne sælge hurtigere internet til de nye tårne.. (Og jeg tror faktisk han mente det)

MiniatureZeus (1) skrev:

Jeg oplever jævnligt, at hastigheden på vores internet pludseligt stiger ret meget, fra en normal download hastighed i transmission på 256 kb/s til 460-500 kb/s...

Lad mig så være den første lyseslukker til at komme med en teknisk forklaring på fænomenet. Det kan være du er forbundet til en forbindelse som faktisk kan overføre med langt større hastighed, men som skal deles med andre brugere. Det gælder f.eks. kabeltv nettet. I så fald vil der side noget udstyr og sikre, at du ikke overfører med større hastighed i gennemsnit end du har betalt for. Hver enkelt pakke vil sendes med den fulde hastighed, så den delte båndbredde hurtigst muligt bliver tilgængeligt for den næste bruger, du vil altså kunne overføre bursts med større hastighed. Nærmere bestemt fungerer det ved, at der er en tæller der hele tiden tæller op hvor meget du er berettiget til at bruge. Så for hver pakke kigger udstyret om tælleren er nået langt nok op til at sende pakken igennem, hvis tælleren er højt nok, så bliver den talt ned og pakken bliver sendt. Hvis tælleren ikke er højt nok, så må pakken vente eller blive kasseret. Nu kan man selvfølgelig ikke lade sin internetopkobling være idle natten over og så næste dag overføre med fuld hastighed en time i træk. Der er en grænse for hvor langt denne tæller får lov at gå op. Grænsen kunne f.eks. være 1MB. Det vil sige, at hvis din forbindelse har været idle i et stykke tid, så kan du overføre 1MB med fuld hastighed som sagtens kunne være 10Mbit/s hvorefter hastigheden vil falde til den korrekte. På den anden side har TCP en slow start som lige skal bruge et kort tidsrum til at finde den rigtige hastighed. Det fungerer ved at hastigheden fordobles for hvert rtt indtil der opstår pakketab. Når der opstår pakketab halveres hastigheden, og så får den lov at stige igen men ikke lige så hurtigt. Disse faktorer resulterer i, at du vil se en hastighed som starter langsomt, men hurtigt vokser op over din tilladte hastighed - indtil din burst er opbrugt hvorefter den begynder at falde igen. Efter et minuts tid vil den have stabiliseret på den korrekte hastighed.

#3

Hvis der var en rating "Super informativ", så havde du fået den !

#3 AHA! Så du er altså med i denne konspirationsteori!

#3 er det så derfor at vores internet her er vold ustabilt og langsomt, men scorer 20 mbps i TDCs hastighedstest?

Rockerne sidder på stilladsmarkedet!

#7 Vores familie fremstiller stilladser... Og vi har en Harley Davidson! Og læderjakker!

milandt (6) skrev:

er det så derfor at vores internet her er vold ustabilt og langsomt, men scorer 20 mbps i TDCs hastighedstest?

Det er svært at sige. Jeg ved ikke hvordan deres hastighedstest virker. En hastighedstest skal selvfølgelig strække sig over et tilstrækkeligt langt tidsrum for at give et brugbart resultat. Hvis den er så kort, at den kun får den første burst med, så er resultatet ikke meget værd.

Et andet spørgsmål er, hvordan testen reagerer på pakketab. Hvis testen bare bruger TCP, så vil den opføre sig lige som hovedparten af alt andet kommunikation, som også anvender TCP. Hvis der er betydeligt pakketab, så vil TCP sætte hastigheden ned. Men ved at basere sin test på TCP har man også mistet muligheden for at finde ud af detaljerede oplysninger. Hvis man i stedet sender UDP pakker, vil man kunne måle pakketab og latens for hver enkelt pakke, men så er det svært at finde ud af, hvilken hastighed man ville opleve, hvis man havde brugt TCP.

Testen kunne selvfølgelig også bare starte med TCP for at estimere hastigheden og derefter sende UDP pakker for at måle latens og pakketab. Det skal selvfølgelig måles ved forskellige hastigheder som ligger hhv under og over den målte hastighed for TCP.

Der er yderligere den komplicerende faktor, at hvis problemet ikke er på forbindelsen mellem din computer og backbone, men et sted ude på backbone, så vil resultatet blive forskelligt afhængigt af hvilken server man kommunikerer med.

Du fortæller ikke hvor hurtig din forbindelse burde være og hvilken udbyder der er tale om. I øvrigt ved jeg ikke hvor gode forbindelser de enkelte udbydere har til forskellige netværk.

En test over et kvarters tid kan give en god fornemmelse af hastigheden, men den kan ikke vurdere om forbindelsen er stabil over længere perioder. Hvis man vil måle det kræver det noget som kører i baggrunden og periodisk sender enkelte pakker for at måle pakketab og latens.

Jeg lavede på et tidspunkt selv et program, som tester forbindelsen mellem to computere ved at sende en pakke hvert 15. sekund og logger hvor mange der er kommet igennem i de sidste fire minutter.

http://kasperd.net/~kasperd/src/connectivity-probe...

Det fortæller selvfølgelig ikke om problemet er i den ene eller anden ende. Men som regel vil der være nogle andre symptomer samtidig, som vil vise i hvilken ende problemet ligger.