03. maj 2003 - 16:13Der er
23 kommentarer og 1 løsning
Full duplex på adsl eller ej...
Hej!
Jeg stiller dette spørgsmål, fordi jeg vil have bekræftet mit syn på en sag. Jeg er fritidsansat som phonesupporter hos TDC i deres bredbåndsafdeling, og her stødte jeg på en kunde, som mente at vi ikke leverede full duplex på hans adsl. Han mente at han burde kunne bruge alt hans upload hastighed samtidigt med at han brugte alt hans download hastighed, og det kunne han ikke.
Nu er jeg igang med at uddanne mig til ingeniør, og jeg så det som en faglig udfordring, og satte mig for at komme helt til bunds i dette. Dette er hvad jeg har fundet frem til: TDC's adslmodemer kører 10 mbit halv duplex TDC ADSL og DSL kører Full duplex. TDC's Backbone net er Full duplex og iøvrigt koblet med redundante forbindelser der gør at det er meget svært(reelt set umuligt med undtagelse af tilfælde hvor en eller flere linjer går ned) at anvende hele nettets kapacitet. Selv om adslmodemet kun kører 10mbit/half er det stadig rigeligt til en normal adsl linje der aldrig kommer op i nærheden af 10 / 2 = 5mbit. Det har resulteret i at jeg har læst op på TCP protokollen, og fundet en mulig kilde til problemet. Der sker nemlig pakketab på en linje når hele båndbredden er i brug, og det har TCP et problem med... TCP anvender sliding windows til styring af udestående pakker, pakker der ikke er kvitteret for som værende modtaget af klienten. Det fungerer sådan at hvis A sender til B, så er det hurtigere at sende 10 pakker ad gangen og få kvittering for dem på en gang. Hvis B kun modtager pakkerne 1-8, så kvitterer B kun for pakkerne 1-8 og 9 og 10 sendes med næste gang. Dette scenario er hvis B's download båndbredde er 100% anvendt. Hvis B's upload båndbredde kan der også mistes pakker i den anden retning, og det vil sige kvitteringerne. Hvis A ikke modtager en kvittering, vil den for det første vente i længere tid end hvis den havde modtaget kvitteringen, og bagefter vil den sende alle pakkerne igen. Dette vil allermindst halvere den hastighed B downloader med, og dermed skabe det scenarie jeg beskrev ovenfor.
Jeg er klar over det ikke umiddelbart er et spørgsmål, så her kommer reglerne: 1. Point hvis du kan komme med yderligere årsager til dårlig performance, og jeg gider ikke høre på ting som "en langsom computer, langsom forbindelse og lign." 2. Point hvis du kan fortælle mig at jeg tager fejl, uddybende selvfølgelig om hvor jeg får galt..
For det første: Hvordan vidste omtalte kunde at han ikke brugte full speed i begge retninger *samtidigt* ? Hvordan skulle han i givet fald have konstateret det?
For det andet: 256 kbps er ikke 256 kbps til computeren, og jeg tror det skyldes protokoloverhead. Ikke så meget pga. sliding windows, det bruger de fleste af protokollerne sikkert, men simpelt hen pga. de mange lag af protokoller.
For det tredje: Du som TDC supporter kan vel svare på hvor i netværket kommunikationen kører med 256 kbps? (eller hvilken hastighed, man nu anvender)
Når man sender data i én retning, sendes der kvitteringer i den anden retning. De fylder ikke meget, men nedsætter selvfølgelig hastigheden en smule.
"Langsom computer" kan næppe være årsagen, da de fleste i dag kan levere data helt op til de 100 Mb/s et typisk netkort har. Alligevel kunne man ønske at der blev testet med 2 computere, en der uploader, og en der downloader. Så har man isoleret problemet. Start fx en download, der varer længe. Kig på hastigheden. Start så en upload på den anden, og check hastigheden igen på den første.
1. Hvis du snakker om bits der kører ígennem kobber, så har han ingen mulighed for at se det, og det er heller ikke den hastighed jeg snakker om. Det er den hastighed han kan se når han henter noget med FTP fx. Det er jo relativt let at have to vinduer, 1 hvor du kan se hvor meget du effektivt uploader med, og et hvor du kan se hvor meget du effektivt downloader med.
2. Det er jeg også klar over. data bliver pakket ind i TCP, IP og AAL-5 mellem kunden og hvor kunden kobles over på internettet. Som udgangspunkt plejer vi at sige at hvis du deler bits med 10, får du ca kb/s hvor der er taget højde for overhead (headere). Men sagen er den at kunden kun oplevede problemet når han uploadede til hans venner samtidigt med at han selv downloadede, og header-overhead burde ikke vøre afhængig af om han uploader eller ej. Det har jeg vist ikke skrevet ret tydeligt - undskyld. Så vidt jeg er informeret kører linjen 256 kbit (eller hvilken hastighed det måtte være) på selve adsllinjen, og derfra er trafikken sammenlagt med alle andre adslkunder på samme 'central' på en linje hvor der skulle være rigeligt med båndbredde, således at 'flaskehalsen' er selve kobber strækningen.
>Når man sender data i én retning, sendes der kvitteringer i den anden >retning. De fylder ikke meget, men nedsætter selvfølgelig hastigheden >en smule.
Det nedsætter vel kun hastigheden hvis det er half duplex, og den eneste strækning det forekommer er mellem pc og ADSL modem, og der køres 10 mbit, så det burde slet ikke kunne mærkes når kunden ikke kan have mere end en 2048/512 linje.
emmek -> hvis du downloader med 2048 og forsøger at uploade med 512 samtidig, så vil noget af traffiken blive sat ned i hastidhed, da der sendes kvinteringer begge veje hele tiden!, så vil ikke kunne downloade med den fulde hastidhed, hvis du samtidig forsøger at oploade med hele din forbindelse samtidig.
Niks.. men den båndbredde der forsvinder er mere end blot det der bruges på at sende ACK pakker.. Det har jeg vist ikke fået skrevet specielt tydeligt, men kunden oplevede _betydeligt_ nedsat hastighed, han kunne ikke downloade med mere end 30-40% af kapaciteten.
I kan jo også selv prøve det. Man kan logge ind på ftptest1.tele.dk som anonymous og email som password. Under /pub er der nogle filer der kan downloades, og der kan også uploades til /pub/upload. Hvis i har adsl, kan i prøve at uploade en fil på 10 MB, og efter i har sat det igang, kan i downloade en fil på 10 mb. Downloadet på 10 mb bør blive færdig først med mindre man har DSL, hvor man så skal downloade en mindre fil. Jeg har en 1024/256 linje og i får mine resultater når jeg selv har testet..
Jeg behøver ikke at teste :) hvis jeg henter en fil på 10 mb så kan jeg hente med ca 64 kbs hvis jeg ikke laver andet!, hvis jeg så samtidig forsøger at sende en fil på 10 mb, (kan kun sende med 128) der burde jeg teoritisk kunne sende med 16 samtidig med at jeg henter den andenfil!
så i teorien burde jeg kunne sende og hente med 64/16 simultant, dette er ikke praksis hos mig, hvis jeg henter en storfil, og samtidig sender en stor fil, så bliver den nærmere sådanne 40/10 at min forbindelse forløber.
Hmm ok, nu føler jeg ikke jeg er blevet ret meget klogere.. Jeg testede med 20 mb filer: 1: hvis jeg uploadede og downloadede på samme tid: Upload hastighed: ~ 21kb/s Download hastighed: ~ 97kb/s
2: Hver for sig: Upload hastighed: ~ 26kb/s Download hastighed: ~ 110kb/s
Og hvis jeg kørte half duplex på den strækning hvor 1024/256 båndbredde begrænsningen gælder, så burde jeg vel ikke kunne uploade og downloade på samme tid med de hastigheder, når de 'enkeltvise' downloads er så lidt hurtigere.
Har læst det... det falder meget godt i hak med det jeg selv tror kan være årsagen (MAKR argejder selv hos TDC..) Grunden til at jeg ikke stilles tilfreds med dette link, er at kunden ikke gør det (jeg syntes ellers det passer fint med det jeg siger, men det er jo bare mig..) Forklaring til det sidste... Half duplex betyder (såvidt det er mig bekendt) at man kun ka sende eller modtage trafik på en gang.. Men!!! Hvis jeg rent faktisk kørte half duplex på min adsl, så burde jeg ikke kunne 'transportere' mere end den maksimale hastighed ud over min adsl forbindelse, på et givent tidspunkt. Her må den hastighed være Download hastighed: ~ 110kb/s. MEN!!! Efter som jeg rent faktisk kan transmittere 97 KB/s donwload + 21 kb/s uploadm kan jeg ikke helt se hvordan jeg kan undgå at anvende mere end den teoretisk maksimalt mulige båndbredde i en af retningerne (download) (119 kb/s), og dermed anvende mere båndbredde end hvis det blot var half duplex. Hmm Ok.. jeg er ret fuld, så hvis der er nogle der vil have en bedre ( anden ) forklaring kommer den nok tidligst i morgen ;o) sorry...
MEN!! I bør have tålmodighed indtil mindst 15.00 Selv om jeg er kommet tidligt i seng, er jeg lang tid om at vågne.. ;o)
//SSCH Så ved makr i det mindste hvem jeg er.. ;o)
Hvilket / hvilke programmer anvender i når i laver disse forsøg Jeg har selv prøvet at holde lidt øje med min båndbredde, men jeg synes det forskellige software viser hver deres tal (jeg har prøvet at have flere programmer til at måle samtidig). Og det kan godt være rimeligt store forskelle. (så min pointe er vel egentligt hvor meget skal man stole på de tal man når frem til)
Jeg har brugt dos FTP klienten. Men udemærket pointe. Det er derfor jeg bruger det jeg gør, fordi jeg tror at jo simplere en klient, jo færre faktorer er der til at spille ind. Jeg overvejer lidt at lave et program til at teste det med, der dog ikke bruger tcp, men udp der ikke bruger ACK pakker. Hvis jeg har ret i min formodning, så burde udp kunne køre max i begge retninger samtidigt. Hmm mon ikke man ka lave noget hurtigt i C#.. Eventuelt hvis der er nogle der kender til sådan noget, så jeg slipper for at lave det selv, er jeg meget interesseret.
UDP-pakker kan gå tabt. Sender du så mange du kan fra din PC, kan din ADSL ikke følge med, og du vil (hmm - jeg har da vist aldrig prøvet--) måske opleve et stort tab, set fra afsenderside.
Men måler du så på modtagerside, vil det sikkert være korrekt hvad du skriver.
Det var i hvertfald tanken.. Altså at måle det der KOMMER igennem. Det må da være den ultimative test. Vi behøver jo heller ikke tænke på fejlkontrol og den slags, så det burde ikke være vildt svært.
Så vidt jeg husker (jeg har ikke lige kigget i bogen), så kan du blive snydt et andet sted. Nemlig ved at UDP-pakker har en mindre header, og derfor mindre overhead end en TCP-pakke.
Men alt taget i betragtning et interessant eksperiment.
Hmm ja, men sagen er den at headerlængden er fast, så jeg kan faktisk fortælle præcist hvor meget der kommer igennem inklusiv overhead, og så kan man jo altid omregne til hvad det ville være blevet til i tcp, hvis altså der aldrig blev mistet pakker, og vi antog at antallet af pakker der sendes på en gang er statisk, hvad det jo ikke er.
Nemlig, du skal bare trække lidt % fra eller lægge til, hvad vej det nu vender. Og selvfølgelig kan du ikke tage højde for faktiske retransmissioner i TCP.
i kan komme med jeres headere og alt andet, men det har ikke noget med Up- og Downstreamen at gøre.
Det er sådan at når man har ADSL 512/128, får du en 512 Kb-linie, hvor du har mulighed for at bruge 128KB af linien til upload.
Hvis du havde mulihed for fuld duplex, dvs. fuld hastighed i begge retninger på samme tid, ville du have båndbredde til 640Kb, og dette er ikke muligt hos de fleste selskaber.
Det er mig bekendt direkte forkert. Du har ret i at man ikke får en forbindelse der tillader 640 kbit i en retning, men det der rent faktisk sker, er flg.: Data sendes ELLER modtages i separate frekvensbånd. Det er vist nok 4KHz for TDC, og dette tillader 64kbit trafik i et enkelt frekvensbånd. Der er herefter tildelt x frekvensbånd til at sende med og y frekvensbånd til at modtage med. Årsagen til at (a)dsl ER full duplex, er at frekvensbåndene kan betragtes som separate 'medier/kabler', og at man faktisk kan sende i nogle parallelt med at man modtager i andre. Tjek evt: http://www2.rad.com/networks/1997/adsl/ADSLTechDis.htm
For lige at runde det helt af, med hvorfor upload hastighederne som regel altid er mindre end download er der denne forklaring:
1. Folk har mere brug for at downloade.. (Den vigtigste)
2. Der er støjproblemer med upload i forhold til download: Det er meget støj, på den strækning i jorden, umiddelbart før alle telefonkablerne ryger ind i 'centralen' fordi der ligger mange kabler ved siden af hinanden. Det er godtnok lige for både up- og download, men da telefonkablet kan betragtes som en stor, lang modstand, mister upload signalerne, der jo starter helt ude hos adsl modemet, effekt i forhold til download signalet inden de to bliver udsat for denne støj.
Det udgør et problem fordi forholdet mellem signal og støj(dB) skal være over en bestemt grænse for informationerne i signalet kan tydes. I den anden ende er det ikke det samme problem, fordi downloadsignalet og støjen i signalet får reduceret deres effekt proportionalt af den lange kobberledning.
Ved godt det er lidt dårligt forklaret, men jeg havde også helst brugt en tavle eller et stykke papir og nogle figurer - det er lidt svært med rent tekst. ;o)
Jeg er nu ansat i TDC Backbone, og har snakket om dette med flere systemfolk som arbejder med DSL og er med i DSL-forum etc. Sagen er klar - jeg har ret!
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
