Vegard20 Skrevet 14. september 2004 Del Skrevet 14. september 2004 Noe som mange her trenger å få klarhet i, men som aldri blir respektert er i det hele tatt hvordan overføringen foregår. Og her skiller vi mellom asynkron og synkron overføring. ADSL står for "Asymetrisk" ja, men det er en asynkron overføring og dette fører til tap når upload også kjører for fullt. Egentlig så er det alltid tap i en slik linje siden den legger seg i hvilestilling og overfører kun ett og ett tegn. I praksis får vi dermed kun nærmere 80% utbytte av linjen. Synkron derimot overfører data`er alltid selv om du ikke bruker linjen. Er den ikke i bruk overfører den bare tomgangstegn eller "Idle character" som har en hexadesimalverdi på FF. I praksis med denne linjen da får vi så mye utbytte av linjen som vi kan få, altså nærmere 100%. Dette er kort sagt det fysiske laget og TCP/IP protokollen har intet med dette å gjøre. Men det kommer selvfølgelig andre tap i tilegg som som har mere med programvaren og gjøre. Lenke til kommentar
tvangsgreie Skrevet 30. september 2004 Del Skrevet 30. september 2004 (endret) Noe som mange her trenger å få klarhet i, men som aldri blir respektert er i det hele tatt hvordan overføringen foregår. Og her skiller vi mellom asynkron og synkron overføring. ADSL står for "Asymetrisk" ja, men det er en asynkron overføring og dette fører til tap når upload også kjører for fullt. Egentlig så er det alltid tap i en slik linje siden den legger seg i hvilestilling og overfører kun ett og ett tegn. Tror det er feil. Finner egentlig ikke noen konkret dokumentasjon som sier det ene eller det andre, bortsett fra at det finnes et synkroniseringssymbol: http://www.cs.tut.fi/tlt/stuff/adsl/node27.html Kan ikke se hva som er vitsen med det om linjen er asynkron. Kan egentlig ikke helt se hvor du får denne "et og et tegn"-forklaringen din fra. Bitene overføres i celler (husker ikke hvor store de er), og bytes blir ikke brukt før på et høyere nivå. Endret 30. september 2004 av tvangsgreie Lenke til kommentar
ifi Skrevet 7. oktober 2004 Del Skrevet 7. oktober 2004 For de som ikke vil tape downloadhastighet ved upload, vil det fungere bra å sette opp prioritering for SMÅ pakker, slik at de blir sluppet gjennom først. Dette inkluderer da ACK-pakker, samt irc/msn etc. Eventuellt kan man sette opp prioritering for kun små ack's.. Lenke til kommentar
ebso86 Skrevet 11. oktober 2004 Del Skrevet 11. oktober 2004 For de som ikke vil tape downloadhastighet ved upload, vil det fungere bra å sette opp prioritering for SMÅ pakker, slik at de blir sluppet gjennom først. Dette inkluderer da ACK-pakker, samt irc/msn etc.Eventuellt kan man sette opp prioritering for kun små ack's.. og hvordan gjør man dette? Lenke til kommentar
Remo Skrevet 12. oktober 2004 Del Skrevet 12. oktober 2004 Noe som mange her trenger å få klarhet i, men som aldri blir respektert er i det hele tatt hvordan overføringen foregår. Og her skiller vi mellom asynkron og synkron overføring. ADSL står for "Asymetrisk" ja, men det er en asynkron overføring og dette fører til tap når upload også kjører for fullt. Egentlig så er det alltid tap i en slik linje siden den legger seg i hvilestilling og overfører kun ett og ett tegn. I praksis får vi dermed kun nærmere 80% utbytte av linjen. Synkron derimot overfører data`er alltid selv om du ikke bruker linjen. Er den ikke i bruk overfører den bare tomgangstegn eller "Idle character" som har en hexadesimalverdi på FF. I praksis med denne linjen da får vi så mye utbytte av linjen som vi kan få, altså nærmere 100%. Dette er kort sagt det fysiske laget og TCP/IP protokollen har intet med dette å gjøre. Men det kommer selvfølgelig andre tap i tilegg som som har mere med programvaren og gjøre. Lenke til kommentar
*Titan* Skrevet 17. oktober 2004 Del Skrevet 17. oktober 2004 Sånn som jeg forstår det virker det som at grunnen til at download synker ved upload er at programmet du kjører bruker (eller reserverer) båndbredde for å vente på ACK pakkene.. er det riktig?? -*TiTaN*- Lenke til kommentar
Gjest orden Skrevet 20. november 2004 Del Skrevet 20. november 2004 (endret) Slettet. Endret 22. januar 2015 av orden Lenke til kommentar
Lautsprecher Skrevet 20. november 2004 Del Skrevet 20. november 2004 Trikset er i bunn og grunn bare at dele opp (det andre laster fra dig) i mindre pakker end det som er 'default' for TCP/IP protokollen. Da får svarpakkerne en større sjanse for at 'komme igennem'! Dvs. raskere frem til mottakeren. Hvordan gjør man det? endrer størrelsen på selve filen? Lenke til kommentar
tvangsgreie Skrevet 8. desember 2004 Del Skrevet 8. desember 2004 Sånn som jeg forstår det virker det som at grunnen til at download synker ved upload er at programmet du kjører bruker (eller reserverer) båndbredde for å vente på ACK pakkene.. Det er operativsystemet som styrer det, og det blir ikke brukt eller reservert båndbredde for å vente på ACK, men om hele båndbredden ut blir brukt, er det ikke tid til å sende dem med en gang, og derfor vil ACK-pakkene bli liggende i kø en liten stund før de blir sendt. Å prioritere små pakker kan f.eks. gjøres ved å sette opp en Linux-ruter mellom PCen og modemet. Det er desverre ikke nødvendigvis en god nok løsning alene. ADSL-modemer ol. har et sende-buffer, og om det fylles opp, vil pakkene bli liggende i kø en liten stund. Køen i modemet er ofte den største grunnen til at ACK-pakkene kommer seint fram, og det er derfor det kan hjelpe veldig mye å begrense ut-hastigheten. Har man flere PCer som må dele linje, er sansynligvis det optimale å koble dem til en Linux-ruter som både prioriterer små pakker, og begrenser ut-hastigheten til litt under det modemet maksimalt kan ta unna. Lenke til kommentar
Cluster1 Skrevet 17. desember 2004 Del Skrevet 17. desember 2004 Hvis adsl er full duplex og blir påvirket av upload/download.Hvordan har det seg da at lyse som leverere 2mbit og 10mbit i rogaland klarer uploade/downloade i max uten tap og det er også full duplex Lyse bruker jo fiber -ikke kopper over telefonlinjen slik som ADSL linjene til Telenor, ngt osv. Med fiberoptikk er det nesten ikke begrensninger. Lenke til kommentar
Micromus Skrevet 18. desember 2004 Del Skrevet 18. desember 2004 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å! Btw: Slik jeg har forstått det betyr Synkron overføring at det først sendes, så mottas en bit/ramme/pakke, på en måte som blokkerende sockets i div. programmeringsspråk. Lenke til kommentar
TanglewoodD Skrevet 23. desember 2004 Del Skrevet 23. desember 2004 Ah, vi trengte en sånn guide. Men hva med å korte ned forklaringen (del 2) litt? Edit: Eller kanskje skrive et sammendrag på et par linjer som forklarer prinsippet med bekreftelsespakker osv? Forkorte, hehe jeg skjønner ikke bæret. kanskje dra opp ordlista? Mvh Stian_A Lenke til kommentar
|SeVen| Skrevet 29. januar 2005 Del Skrevet 29. januar 2005 Har 700/512 fra eidsiva energi, og jeg laster ned like bra uansett hvor mye jeg uploader, litt snodig egntlig. Lenke til kommentar
curtiis Skrevet 9. februar 2005 Del Skrevet 9. februar 2005 Ga jo en del svar på en del ting jeg lurte på. Lenke til kommentar
snarum Skrevet 21. februar 2005 Del Skrevet 21. februar 2005 Er jo en grisegammel tråd, men kanskje noen med peiling leser den likevel. Jeg skjønner teorien med at ack bruker opp uthastigheten når det blir mye inntrafikk. Men da er det noe jeg lurer på: Når jeg laster ned for full guff, og bruker netlimiter til å strupe uthastigheten på dc++ til f.eks 2kb/s hvorfor senkes ikke innhastigheten også da? Når windows ikke får sendt Ack pakker, sender den likevel ut requests på nye pakker? Dette burde vel ha samme effekt som det at andre bruker opp uthastigheten, eller? snorre Lenke til kommentar
brazir Skrevet 21. februar 2005 Del Skrevet 21. februar 2005 Bra poeng....Jeg har 1024/256 fra tele*or. Hvis jeg struper uthastigheten til 1 Kb/sek kan jeg fortsatt laste ned full pupp dvs. ca 140 Kb/sek. Hvordan har dette seg? Blir ikke så mange ACK sendt eller? Eller er det ikke behov for mer båndbredde til dette formålet slik at det går greit lell? Lenke til kommentar
tvangsgreie Skrevet 25. februar 2005 Del Skrevet 25. februar 2005 Når jeg laster ned for full guff, og bruker netlimiter til å strupe uthastigheten på dc++ til f.eks 2kb/s hvorfor senkes ikke innhastigheten også da? Modemer har vanligvis et sende-buffer, som ack-pakkene blir liggende i kø i når man forsøker å sende mer data enn linjen kan ta imot. Når du begrenser uthastigheten, blir det ikke noen kø, og ikke noen ekstra forsinkelse. Derfor kommer ack-pakkene fortere fram når du begrenser hastigheten til under maks. Har skrevet om det i en annen melding i denne tråden også. Hvor mye under maks du må begrense til avhenger av hvor jevnt dataene blir sendt ut. Noen programmer sender dataene i rykk og napp når man har satt på hastighetsbegrensning, og da hjelper det nesten ikke, siden sende-bufferet vil fylles opp hver gang det kommer en ny dose data. Lenke til kommentar
ATWindsor Skrevet 25. februar 2005 Del Skrevet 25. februar 2005 Når jeg laster ned for full guff, og bruker netlimiter til å strupe uthastigheten på dc++ til f.eks 2kb/s hvorfor senkes ikke innhastigheten også da? Modemer har vanligvis et sende-buffer, som ack-pakkene blir liggende i kø i når man forsøker å sende mer data enn linjen kan ta imot. Når du begrenser uthastigheten, blir det ikke noen kø, og ikke noen ekstra forsinkelse. Derfor kommer ack-pakkene fortere fram når du begrenser hastigheten til under maks. Har skrevet om det i en annen melding i denne tråden også. Hvor mye under maks du må begrense til avhenger av hvor jevnt dataene blir sendt ut. Noen programmer sender dataene i rykk og napp når man har satt på hastighetsbegrensning, og da hjelper det nesten ikke, siden sende-bufferet vil fylles opp hver gang det kommer en ny dose data. 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. AtW Lenke til kommentar
klilleng Skrevet 25. februar 2005 Del Skrevet 25. februar 2005 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. Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå