Duplex og hvorfor linjen blir treg ved opplasting

[ATWindsor]

Ok, så det er egentlig modemene som er det svakeste leddet her mao? Det harmonerer bedre med mine erfaringer også, da dette problemet ikke virker til å være i nærheten så stort på LAN.

På LAN er det jo "litt" mer fart å rutte med da. Ofte 100mbit eller mer. Og det lille ADSL-modemet er jo tross alt en ganske enkel skapning i forhold til PC'en.

Joda, men jeg sitter på 10mbit, har flere ganger kjørt linja maks både opp og ned samtidig, uten at jeg kan si at jeg har merket noe særlig på hastigheten. Man skulle jo tro at det var den samme prosentuelle nedgangen for alle, om det bare var ack-pakker som var problemet. Mao konkluderer jeg med at skylda ligger hos modemet, til noen kan overbevise meg om noe annet.

 

AtW

[tvangsgreie]

Pingtid har også noe å si. Det blir lenger ventetid på ack-pakkene når det tar et sekund for pakkene å ta runden.

[rornes]

NeiNeiNei *Med forbehold om feil

 

Konklusjonen her er at TCP stacken gir delay ved pakkeprioritering av ACK.. OK..

 

MEN.

 

Samme problem oppstår med UDP via xDSL der det ikke oppstår ACK. Og jeg har ikke klart å gjennskape samme problem via Ethernet-overføring for TCP med ACK. Dette må være et problem kyttet mot DSL sentralene, og ikke lokale PC. *Med forbehold om mer feil*

 

Noen som har innspill?

[JKJK]

hihiih ... blib sin quote var jo som sakset fra warriors of teH net videoen.

[brazir]

En annen ting.....Hvis jeg setter nettverksinnstillinger til "Full duplex" kobler linja mi seg av etter en liten stund. Har ADSL fra telenor. Nettverkskortet funker bare på "Full autonegotiation".

[ATWindsor]

NeiNeiNei *Med forbehold om feil

 

Konklusjonen her er at TCP stacken gir delay ved pakkeprioritering av ACK.. OK..

 

Men hvorfor er dette nærmest ett ikke-eksisterende problem på konvensjonelle LAN da?

 

AtW

[Vegard20]

De som har lest siste Nettverk og Datakommunikasjon har kansje kost seg over leserinnlegget til en eller annen markedssjef for noe hot-shot IT selskap, der han blander asymetrisk og asynkron, og noe annet jall som ikke har noe med fakta å gjøre. Hadde vært best om sånne bedrevitere hadde holdt kjeft en å forelese om ting de ikke har peiling på!

Hvor har du at jeg blander asymetrisk og asynkront? Det står at ADSL er "asymetrisk" og at overføringen er "asynkron". Mener du at det er feil så kan jeg ikke si meg enig.

 

Og markedssjefen i dette hot-shot IT firmaet ditt gikk ikke IKT driftsfag når han satt på skolebenken. Men han lærte om hvordan pulsene gikk i kabelen fra sender til mottaker, og da snakker vi ikke om "synkront" i programmeringsspråk. Da snakker vi synkron overføring.

 

Og til dere som diskuterer over her. Når det gjelder UDP så har jo den ingen feilkontroll? Har jeg forstått det som, at det er en ren streaming metode altså. Hadde det vært UDP forbindelse til nettbanken din så kan det hende at du plutselig overfører noen flere siffer en du egentlig skulle. Det kan bli dyrt, evt billig!

[rornes]

NeiNeiNei *Med forbehold om feil 

 

Konklusjonen her er at TCP stacken gir delay ved pakkeprioritering av ACK.. OK..

 

Men hvorfor er dette nærmest ett ikke-eksisterende problem på konvensjonelle LAN da?

 

AtW

Vel. Jo. Prøv dette hvis du har en hub.

 

Sett 3 maskiner i nett via en HUB (ikke switch)

 

Når de 3 maskinene sender samtidig vil hubben gi pakkekrasj. Dette medfører via en TCP overføreing at ACK ikke blir godkjent. Maskinene vil da sende pakker på nytt.

 

Mens disse re-sender kan du prøve å sende en fil der du klokker hastigheten med størrelse. Prøv så etterpå denne sendingen uten annen trafikk på linjen. Dermed kan en bevise at det oppstår en ack forsinkelse med LAN også

 

...MEN..

 

Når du laster trafikk på et OK LAN oppstår samme problem, men det er knapt merkbart hvis det ikke oppstår feil trafikkflyten.

 

Derimot oppstår det samme med DSL, men her er det merkbart ved normal trafikk.

 

Min konklusjon er at dsl teknologien er for dårlig. Om feilen oppstår i modemet, eller hos ISP er uvisst. Men S-DSL skal ikke ha samme problem som A-DSL.

 

Noen som har mulighet for å teste ACK med ADSL-modem. Er det her problemet oppstår? Eller er ISPene ansvarlig. (Uansett er det vel ISP som leverer modemene, så ansvaret ligger hos dem)

[ATWindsor]

NeiNeiNei *Med forbehold om feil 

 

Konklusjonen her er at TCP stacken gir delay ved pakkeprioritering av ACK.. OK..

 

Men hvorfor er dette nærmest ett ikke-eksisterende problem på konvensjonelle LAN da?

 

AtW

Vel. Jo. Prøv dette hvis du har en hub.

 

Sett 3 maskiner i nett via en HUB (ikke switch)

 

Når de 3 maskinene sender samtidig vil hubben gi pakkekrasj. Dette medfører via en TCP overføreing at ACK ikke blir godkjent. Maskinene vil da sende pakker på nytt.

 

Mens disse re-sender kan du prøve å sende en fil der du klokker hastigheten med størrelse. Prøv så etterpå denne sendingen uten annen trafikk på linjen. Dermed kan en bevise at det oppstår en ack forsinkelse med LAN også

 

...MEN..

 

Når du laster trafikk på et OK LAN oppstår samme problem, men det er knapt merkbart hvis det ikke oppstår feil trafikkflyten.

 

Derimot oppstår det samme med DSL, men her er det merkbart ved normal trafikk.

 

Min konklusjon er at dsl teknologien er for dårlig. Om feilen oppstår i modemet, eller hos ISP er uvisst. Men S-DSL skal ikke ha samme problem som A-DSL.

 

Noen som har mulighet for å teste ACK med ADSL-modem. Er det her problemet oppstår? Eller er ISPene ansvarlig. (Uansett er det vel ISP som leverer modemene, så ansvaret ligger hos dem)

Jeg kan ikke forstå hvorofr eksemplet ditt er relevant, hubben sender all trafikk til alle, og det blir masse stress om flere maskiner kjører fullt. Dette er en begrensing ved hubben, og gir ingen indikasjon på vanlig forhold. Der du mener at ack-pakker sørger for forsinkelse. Hvis det hadde vært problemet, så hadde man merket det med en switch også. (adsl er jo også switchet?). Og denne hastighetsnedgangen burde være prosentuelt like stor uavhengig av linje. (det generes ca like mange ack-pakker per byte utsendt).

 

Og du er inne på noe på slutten, på ett vanlig LAN er dette ett problem du ikke merker noe til. Selv om du pøser på med trafikk. På ADSL er dette ett mer eller mindre stort problem. Det må være en forsskjell ett sted?

 

AtW

[blackbrrd]

Jaha ATWindsor? Sjelden jeg ser et lokalnett hvor både sender og mottager får 100mbit/s, selv på et switchet lokalnett... Personlig har jeg til gode å se noen få 12,5mbyte/s på et lokalnett selv hvor det kun er en sender og en mottaker. Skulle disse begynnte å bruke full duplex muligheten tipper at hastigheten hos begge ville droppet rimelig bra.

[rornes]

NeiNeiNei *Med forbehold om feil 

 

Konklusjonen her er at TCP stacken gir delay ved pakkeprioritering av ACK.. OK..

 

Men hvorfor er dette nærmest ett ikke-eksisterende problem på konvensjonelle LAN da?

 

AtW

Vel. Jo. Prøv dette hvis du har en hub.

 

Sett 3 maskiner i nett via en HUB (ikke switch)

 

Når de 3 maskinene sender samtidig vil hubben gi pakkekrasj. Dette medfører via en TCP overføreing at ACK ikke blir godkjent. Maskinene vil da sende pakker på nytt.

 

Mens disse re-sender kan du prøve å sende en fil der du klokker hastigheten med størrelse. Prøv så etterpå denne sendingen uten annen trafikk på linjen. Dermed kan en bevise at det oppstår en ack forsinkelse med LAN også

 

...MEN..

 

Når du laster trafikk på et OK LAN oppstår samme problem, men det er knapt merkbart hvis det ikke oppstår feil trafikkflyten.

 

Derimot oppstår det samme med DSL, men her er det merkbart ved normal trafikk.

 

Min konklusjon er at dsl teknologien er for dårlig. Om feilen oppstår i modemet, eller hos ISP er uvisst. Men S-DSL skal ikke ha samme problem som A-DSL.

 

Noen som har mulighet for å teste ACK med ADSL-modem. Er det her problemet oppstår? Eller er ISPene ansvarlig. (Uansett er det vel ISP som leverer modemene, så ansvaret ligger hos dem)

Jeg kan ikke forstå hvorofr eksemplet ditt er relevant, hubben sender all trafikk til alle, og det blir masse stress om flere maskiner kjører fullt. Dette er en begrensing ved hubben, og gir ingen indikasjon på vanlig forhold. Der du mener at ack-pakker sørger for forsinkelse. Hvis det hadde vært problemet, så hadde man merket det med en switch også. (adsl er jo også switchet?). Og denne hastighetsnedgangen burde være prosentuelt like stor uavhengig av linje. (det generes ca like mange ack-pakker per byte utsendt).

 

Og du er inne på noe på slutten, på ett vanlig LAN er dette ett problem du ikke merker noe til. Selv om du pøser på med trafikk. På ADSL er dette ett mer eller mindre stort problem. Det må være en forsskjell ett sted?

 

AtW

Det jeg ville frem til er at det også oppstår ack problemer i LAN, men det er ikke synlig med mindre det er noe alvorlig gærnt.

 

DSL har store problemer med up downstream uansett.

 

Konklusjon: ACK problematikken beskrevet i tråden er ikke kilden til DSL struping av up/down. Både A-DSL og S-DSL har dette problemet.

 

Mitt spørsmål: Hvor er problemet for struping av DSL?

[ATWindsor]

Det jeg ville frem til er at det også oppstår ack problemer i LAN, men det er ikke synlig med mindre det er noe alvorlig gærnt.

 

DSL har store problemer med up downstream uansett.

 

Konklusjon: ACK problematikken beskrevet i tråden er ikke kilden til DSL struping av up/down. Både A-DSL og S-DSL har dette problemet.

 

Mitt spørsmål: Hvor er problemet for struping av DSL?

Men da er vi jo klinkende enig! Det var mitt poeng også, at disse problemene alene ikke kan forklare "ADSL-fenoment"

 

AtW

[ATWindsor]

Jaha ATWindsor? Sjelden jeg ser et lokalnett hvor både sender og mottager får 100mbit/s, selv på et switchet lokalnett... Personlig har jeg til gode å se noen få 12,5mbyte/s på et lokalnett selv hvor det kun er en sender og en mottaker. Skulle disse begynnte å bruke full duplex muligheten tipper at hastigheten hos begge ville droppet rimelig bra.

Det må du jo gjerne tippe, man komemr sjeldent høyere enn 10-11 mb/s pga av overhead. Men til gjengjeld så kan du godt kjøre 10-11 mb/s begge veier i ett switchet nettverk (riktignok om HDen følger med). Bare å sette opp og teste det.

 

AtW

[Marti]

Angående duplex: En gang for alle!

Sånn. Da fikk jeg sagt det .

[el-asso]

Siden det har kommet en samletråd med link til de andre guidene avklistrer jeg denne.

[cdr]

Hei

Noen som har noen tips til meg? Jeg har følgende problem:

 

Jeg bruker BitTorrent til å laste ned anime, tv-serier, manga etc.

Problemet er at ned-hastigheten er veldig ustabil, ettersom opp-hastigheten varierer. Jeg bruker netlimiter til å holde hastigheten nede, men det synes ikke å virke 100%.

Jeg har 2048/300 kbps linje, men ned-hastigheten går sjeldent over 120-150 KB/s, pluss at når en nedlastinge er ferdig og går over til SEEDING, tramper den ned hastigheten yttligere.

 

Finnes det noen formel som tilsier "Bruk kun 40% av opp-kapaisteten, eller får dårlig ned-hastighet" e.l ?

 

Finnes det instillinger jeg kan endre på i windows som kan hjelpe, og i såfall, hvilke?

 

 

Nedlastingsklienten lar meg i tillegg sette max/min UL-hastighet pr task, og overall maks UL-speed.

 

Jeg har prøvd mye forskjellig av instillinger innenfor programmet, og forskjellige sperringer av ut-hastighet, men ikke noe av det har gitt meg tydelige resultater.

Hvis jeg sperrer UL til 1kb/s, loker det seg til. Det samme gjør det om jeg ikke sperrer noe i det hele tatt. Jeg pleier å ha den på midten et sted, men når jeg står opp og skal sjekke nedlastingene, kan den ligge på 20kb/s og grafene viser at det er ustabilt. Hvis jeg da fjerner alle seeds (ferdige downloads som står på dele-modus) endrer det seg betraktelig, dog ikke bra nok.

 

Noen som vet noe?

Endret 30. august 2005 av RaScZaK

[klilleng]

Hva med å drite i NetLimiter, og bruke en klient som klarer å regulere hastigheten? Med BitComet får jeg av en eller annen merkelig grunn best DL hvis jeg setter global UL til 35k. Har 4000/600 (ca) linje fra NGT. Hos deg ville jeg prøvd å satt den på 15-20k max.

 

Husk også at nedlastingshastigheten (DL) kan variere mye, uansett hva du har på UL, pga forhold utenfor din PC..

Endret 30. august 2005 av klilleng

[JVRG]

Noen små ting.

 

Ingen hastighetsbegrensere/netlimitere jeg har brukt begrenser hastigheten til ACK-pakker. Derfor går nedhastigheten som vanlig selv om opphastigheten er begrenset til 1kb/s.

 

Anbefaler også folk til å laste ned en hastighetsmåler som måler hvor mye nettverkskortet sender ut og tar imot. Last så ned noe fra en annen maskin og se på opp-hastigheten. Da vil du se hvor mye som forsvinner til ACK-pakker og andre mystifistiske pakker. Har selv brukt statbar til dette. Vær obs på at måleren måler all data og ikke bare TCP/UDP-data som sendes.

 

Og for de som laster ned via bittorrent. I tillegg til å sende ACK-pakker for data som mottas, så kommer også forespursler om tilkoblinger. Laster man ned en torrent med mange brukere, så vil jeg anta at disse forespurslene også tar litt av ned hastigheten.

 

Anbefaler også at dere leser Wikipedia sin adsl forklaring.

 

Vegard20: Hadde satt pris på om du kunne dokumentere det du sier, da det er nytt for meg (og sikkert en del andre her).

 

Og en siste liten ting. Ole Lukkøye (med venner, bl.a. Leif) driver og mobber meg litt nå. Har prøvd å luke ut skrive-feil (og andre feil), men overrasker meg ikke om de har lagt inn noen nye.

 

Target

[Hans Erling]

2000/512 er ikke lik 200/50kB/s, men 250/65 i teorien.

 

[kbps=kilobit pr sekund]

[kB/s=KiloByte pr sekund]

[Caddy]

Del 2: Hvor blir nedlasting treg ved opplasting? (eller omvent)

Vel, jeg tror jeg skal sitere Blib jeg (dette er hentet fra http://forum.hardware.no/index.php?showtopic=280477&st=0 og er endre litt med Blibs velsignelse ).

Så, hvorfor opplever vi da det at ved full upload synker den maksimale downloadshastigheten vår? Jo, fordi vi bruker en teknologi som heter TCP/IP. Kommunikasjon over TCP/IP forgår pakkevis, altså at litt og litt informasjon blir pakket ned i små esker og sendt via routere mellom klienter og servere. Ved destinasjonsstedet blir så pakkene pakket ut og informasjonen satt sammen igjen. Når pakken forlater maskinen din fyker den stille og rolig ut fra PCen og inn i din router. Innen dette har den da fått klistret på seg IPen den skal dra til og routeren din hiver den på riktig vei. Men, når du så kommer ut på det store nettet, er alt kaos. Pakker kan kollidere eller gå tapt og det er en farlig landevei. Og det kan være kritisk at *alle* pakkene i en forespørsel faktisk kommer frem. Hva tror du ville skjedd dersom pakke #1424224 gikk tapt undervei, og at den pakken inneholdt de første kommandoene i en av de viktigste filene i pakken, som f. eks hvis dette var et PC-spill. Vi kunne i værste fall ende opp med et uspillbart spill pga spill.exe-fila var korrupt. Dette er jo selvsagt ikke akseptabelt, iallefall ikke med tanke på at pakketap kan skje mangfoldige ganger under en stor overføring. Så derfor sjekker alltid serveren pakkene når den mottar de, at pakkene er i "orden" (Ikke blitt litt ødelagte) samt at det er rett pakkenummer. Du vil vel ikke at når PCen din pakker opp pakkene for å sette sammen informasjonen, at den skal prøve å sette sammen pakke #1 og #3 etter hverandre? Nei? Tenkte ikke det. De fleste av oss vil nemlig ha #2 mellom der. Så, etter at serveren du laster opp til da har sjekket at pakken ser fin ut, eller at en mangler en pakke, skal den så informere deg igjen om dette. For å informere om at pakken var skadet eller OK, sender den ut en pakke selv, tilbake til deg. Hvis så maskinen din ser at en av pakkene den sendte ikke kom frem, vil den sende pakken på nytt.

 

Og her kommer det vansklige: Hvis du også laster ned, for full guffe, fra en annen server, hva vil da skje med disse konfirmasjonspakkene fra serveren du uploader til? Jo, disse konfirmasjonspakkene blir prioritert foran de vanlige nedlastningspakkene! Og derfor vil hastigheten på din download synke, for den må også ta i mot konfirmasjonspakker.

 

Selve hovedgrunnen til at du mister så vesentlig mye på å downloade for fullt mens du uploader for fullt, er tho enda ikke dette. Det er rett og slett at for at du selv skal kunne downloade i max hastighet, må du jo selv også sende ut konfirmasjonspakker. Og hvis uploadskapasiteten din er nådd, vil PCen din ha store problemer med å sende ut disse pakkene. Og grunnet teknologien i TCP/IP vil da ikke maskinen din laste ned mer enn at den klarer å sende konfirmasjonspakker for.

 

200kB/s ned krever ca 5kB/s ut. Men hvis uploaden din er hardt presset fordi du laster opp noe til en FTP samtidig, klarer den kanskje bare sende ut 2kb/s med konfirmasjonspakker. Og da vil den sette ned downloadshastigheten til ca 90kB/s.

 

Føler forresten at jeg bør legge til at jeg ikke er absolutt 100% sikker på om jeg har fått det akkurat rett, dette med hvorfor downloaden synker med uploaden. Men jeg er temmelig sikker på at det er veldig likt iallefall en av de to metodene jeg nå har beskrevet. Om det kanskje foregår bare litt anderledes eller at den første grunnen min er litt feil, så får jeg bare unnskylde. Poenget med posten var hovedsakelig å få frem at det finnes noe som heter konfirmasjonspakker og at det er disse som får folk til å tro at xDSL bare er half duplex. Uansett er informasjonen her rimlig nøyaktig ellers

 

Informativ film om nettopp dette.

 

Direktelink til nedlastingsside.

Endret 5. desember 2005 av Caddy