Fartsrekord på nett

[Knopfix]

Er ikke den nåværende laboratorie-rekorden på 2-300 Gbit/s over 1 fiber?

 

Aner ikke.Syntes ikke 10 høres så mye ut når 1Gbps linjer er tilgjengelig på markedet.

[ATWindsor]

Saken er at de har klart å utnytte en 10Gbit/s link over lang avstand. Det er ikke trivielt over TCP/IP fordi disse protokollene skalerer elendig når latency øker. Dette skyldes bruk av transmisjonsvindu for å unngå overbelastning av mottaker som igjen ville medført pakketap og behov for retransmisjon med ellendig ytelse som resultat.

 

Jeg skjønner ikke helt greia, for det første er det vel vanlig at det hopper innom noe på vien, og for det andre, vil ikke det alltid være et problem når man transmiterer data over nett? Jeg har liksom ikke fantasi til å se for meg at man ikke bruker en viss mengde data, med noe checksum, og overfører det, uansett protokoll, og blir latencyen høy, så må man opp i størrelse på denne enheten data for å opprettholde en viss hastighet?

 

AtW

[Phyx]

Her kommer en off topic sorry men. Hvorfor er det fortsatt 8 bit på 1 byte her? Er det ikke 32/64bit i en byte på nyere PC'er etc? Eller har en byte 8 tegn og ferdig med det eller?

[Anders Jensen]

Hvordan harddisker bruker man ved sånne rekorder? Vanlig skriveytelse er jo kun noen titalls megabyte.

8482986[/snapback]

Det overføres nok fra ram til ram eller så er det snakk om en bunt med svært mange forbindelser på lavere hastigheter som rutes inn på den samme kabelen og til sammen utgjør 10 Gb/s.

8483281[/snapback]

Det er ikke noe problem å få 10Gbit/s fra disk da. Du får RAID kontrollere som takler 12Gbit/s (1,5GByte/s) og du kan ha 2 slike samt ett 10GbE kort i mange servere basert på Intel 5000 chipsettet. Selv får jeg 5,6Gbit/s (700MB/s) kontinuerlig fra disk, men har ikke fått testet om jeg klarer å utnytte 4x1GbE linken enda fordi jeg har ikke noe fornuftig i den andre enden, enn så lenge.

Endret 27. april 2007 av Anders Jensen

[Anders Jensen]

Saken er at de har klart å utnytte en 10Gbit/s link over lang avstand. Det er ikke trivielt over TCP/IP fordi disse protokollene skalerer elendig når latency øker. Dette skyldes bruk av transmisjonsvindu for å unngå overbelastning av mottaker som igjen ville medført pakketap og behov for retransmisjon med ellendig ytelse som resultat.

 

Jeg skjønner ikke helt greia, for det første er det vel vanlig at det hopper innom noe på vien, og for det andre, vil ikke det alltid være et problem når man transmiterer data over nett? Jeg har liksom ikke fantasi til å se for meg at man ikke bruker en viss mengde data, med noe checksum, og overfører det, uansett protokoll, og blir latencyen høy, så må man opp i størrelse på denne enheten data for å opprettholde en viss hastighet?

 

AtW

8483320[/snapback]

Tror ikke jeg helt forsto hva du vil frem til. Men det er slik at transmissjonsvinduet må økes for å få utnyttet båndbredden. Dette har en veldefinert matematisk sammenheng. Du kan ikke under noen omstendighet få utnyttet mer av linja enn forholdet ((båndbredde * tur-retur forsinkelse)/total vindusstørrelse) tilsier. Om tallet er større eller lik 1 så kan du i teorien utnytte hele linja. Hvor store pakkene er, er ikke viktig i dette regnestykket, men generelt vil små pakker medføre mer overhead enn store pakker. Det er vel det tekniske hovedargumentet mot ATM f.eks, men ATM vil som oftest få bedre kapasitetsutnyttelse likevel.

Endret 27. april 2007 av Anders Jensen

[Simen1]

Er ikke den nåværende laboratorie-rekorden på 2-300 Gbit/s over 1 fiber?

Aner ikke.Syntes ikke 10 høres så mye ut når 1Gbps linjer er tilgjengelig på markedet.

8483317[/snapback]

10Gbps er jo også tilgjengelig i markedet. Blant annet banetele og uninett har kjøpt inn flere slike løsninger. Sikkert Telenor også.

 

Her kommer en off topic sorry men. Hvorfor er det fortsatt 8 bit på 1 byte her? Er det ikke 32/64bit i en byte på nyere PC'er etc? Eller har en byte 8 tegn og ferdig med det eller?

8483329[/snapback]

1 Byte = 8 bit. Ferdig med det. Det er definisjonen. 64bit = 8 Byte.

[qualbeen]

Tenk deg pingen i cs da holy crap !

8483308[/snapback]

Sorry, men pingen vil ikke påvirkes mye av dette. Avstand til mottaker er fremdeles avgjørende når det gjelder ping.

 

At de benytter IPv6 framfor IPv4 skyldes at IPv4 ikke er designet for hurtighet. IPv6 er en enklere protokoll som går betydelig kjappere å generere for maskinvare (nettverkskort, rutere).

 

At man nå kan sende data med en hastighet når 10Gbps er gøy det

[efikkan]

Slike hastigheter begynner å bli bra. Jeg synest at fiberkabel med minimum 100 Mbps bør bli tilgjengelig for folk flest her snart til fornuftige priser.

 

Jeg har lest litt på nettsider til ulike leverandører av fiberkabel, men ikke funnet ut hvilken hastigheter de tilbyr til hvilken pris.

[Knopfix]

Tror ikke jeg helt forsto hva du vil frem til. Men det er slik at transmissjonsvinduet må økes for å få utnyttet båndbredden. Hvor store pakkene er, er ikke viktig i dette regnestykket, men generelt vil små pakker medføre mer overhead enn store pakker. Det er vel det tekniske hovedargumentet mot ATM f.eks, men ATM vil som oftest få bedre kapasitetsutnyttelse likevel.

 

Det gjelder vel kun TCP.

TCP bruke sliding windows for å forhandle om hvor mye mottaker kan ta imot og av den grunn stor overhead da all pakkelevering blir bekreftet av avsender og mottaker og tapte pakker sendt på nytt.

Men UDP har ikke windowing og av den grunn mer effektivt og med mindre overhead.Den sender pakkene og har ingen kontroll på om noe kommer frem.UDP er ganske pålitelig selv om pakker ikke blir sendt på nytt,men det er en mekanisme gjennom applikasjon som kan få pakker sendt på nytt ved tap gjennom UDP.

[ATWindsor]

Saken er at de har klart å utnytte en 10Gbit/s link over lang avstand. Det er ikke trivielt over TCP/IP fordi disse protokollene skalerer elendig når latency øker. Dette skyldes bruk av transmisjonsvindu for å unngå overbelastning av mottaker som igjen ville medført pakketap og behov for retransmisjon med ellendig ytelse som resultat.

 

Jeg skjønner ikke helt greia, for det første er det vel vanlig at det hopper innom noe på vien, og for det andre, vil ikke det alltid være et problem når man transmiterer data over nett? Jeg har liksom ikke fantasi til å se for meg at man ikke bruker en viss mengde data, med noe checksum, og overfører det, uansett protokoll, og blir latencyen høy, så må man opp i størrelse på denne enheten data for å opprettholde en viss hastighet?

 

AtW

8483320[/snapback]

Tror ikke jeg helt forsto hva du vil frem til. Men det er slik at transmissjonsvinduet må økes for å få utnyttet båndbredden. Dette har en veldefinert matematisk sammenheng. Du kan ikke under noen omstendighet få utnyttet mer av linja enn forholdet ((båndbredde * tur-retur forsinkelse)/total vindusstørrelse) tilsier. Om tallet er større eller lik 1 så kan du i teorien utnytte hele linja. Hvor store pakkene er, er ikke viktig i dette regnestykket, men generelt vil små pakker medføre mer overhead enn store pakker. Det er vel det tekniske hovedargumentet mot ATM f.eks, men ATM vil som oftest få bedre kapasitetsutnyttelse likevel.

8483423[/snapback]

 

Altså, du snakker om at TCP/IP har problemer med hy latency og høy båndbredde, men om man ser på et helt grunnleggende nivå på dataoverføring: så kan jeg ikke se for meg noen annen måte å overføre data enn nyttedata+checksum eller annen type feilsjekking. Og da må klumpen med nyttedaya+checksum økes om man har høy latency g vil ha høy bånbredde, helt uavhengig av hvilken prtokoll man bruker?

 

Altså, såvidt jeg kan skjønne må dette være et helt generelt problem, og ikke noe man kan slippe unna med en annen protokoll?

 

AtW

[qualbeen]

mengden headere, checksum og annen info som skal sendes med overføringen vil variere fra protokoll til protokoll. Dermed egner noen protokoller seg bedre enn andre.

[Anders Jensen]

Saken er at de har klart å utnytte en 10Gbit/s link over lang avstand. Det er ikke trivielt over TCP/IP fordi disse protokollene skalerer elendig når latency øker. Dette skyldes bruk av transmisjonsvindu for å unngå overbelastning av mottaker som igjen ville medført pakketap og behov for retransmisjon med ellendig ytelse som resultat.

 

Jeg skjønner ikke helt greia, for det første er det vel vanlig at det hopper innom noe på vien, og for det andre, vil ikke det alltid være et problem når man transmiterer data over nett? Jeg har liksom ikke fantasi til å se for meg at man ikke bruker en viss mengde data, med noe checksum, og overfører det, uansett protokoll, og blir latencyen høy, så må man opp i størrelse på denne enheten data for å opprettholde en viss hastighet?

 

AtW

8483320[/snapback]

Tror ikke jeg helt forsto hva du vil frem til. Men det er slik at transmissjonsvinduet må økes for å få utnyttet båndbredden. Dette har en veldefinert matematisk sammenheng. Du kan ikke under noen omstendighet få utnyttet mer av linja enn forholdet ((båndbredde * tur-retur forsinkelse)/total vindusstørrelse) tilsier. Om tallet er større eller lik 1 så kan du i teorien utnytte hele linja. Hvor store pakkene er, er ikke viktig i dette regnestykket, men generelt vil små pakker medføre mer overhead enn store pakker. Det er vel det tekniske hovedargumentet mot ATM f.eks, men ATM vil som oftest få bedre kapasitetsutnyttelse likevel.

8483423[/snapback]

 

Altså, du snakker om at TCP/IP har problemer med hy latency og høy båndbredde, men om man ser på et helt grunnleggende nivå på dataoverføring: så kan jeg ikke se for meg noen annen måte å overføre data enn nyttedata+checksum eller annen type feilsjekking. Og da må klumpen med nyttedaya+checksum økes om man har høy latency g vil ha høy bånbredde, helt uavhengig av hvilken prtokoll man bruker?

 

Altså, såvidt jeg kan skjønne må dette være et helt generelt problem, og ikke noe man kan slippe unna med en annen protokoll?

 

AtW

8483607[/snapback]

Vi snakker om to forskjellige problemer her. Det ene er overhead det andre er BDP (bandwidth delay product) de to har ingenting med hverandre å gjøre. Store pakker er fint det, men det hjelper ingenting å sende store pakker om du har høy BDP og lite TCP vindu, så vidt jeg vet er UDP lite brukt på Internett i forhold til TCP. Windows XP vil forhandle med motparten om hvor stort vinduet skal være, men algoritmen for å finne optimal størrelse er ganske dårlig og kan i følge MS bruke opp til en time på å finne optimal vindustørrelse. Vista gjør dette mye raskere. Generelt tror jeg fokus på overhead som et problem er et blindspor i denne sammenhengen. Det er ikke overhead som er førsteordens begrensning.

Endret 27. april 2007 av Anders Jensen

[Olaaaaa]

TCP baserer seg jo på at sender får tilbake kvitteringer, om den ikke gjør det innenfor tidsrammen vil den anta congestion. Dermed vil linker med høy latency lide om ikke transmissjonsviduet (hvor mange pakker som til en hver tid kan være sendt uten å ha blitt kvittert for) er stort nok.

 

UDP baserer seg ikke på kvitteringer, og i motsetning til hva Knopfix sier er det ikke pålitelig. Man kan ha protokoller høyere oppe i stacken som sørger for retransmissjon, men per definisjon er UDP ikke pålitelig.

 

Feilsjekk/retting ligger forøvrig både på linklaget og transportlaget, mens IP bare har feilsjekk for headeren. Den maksimale mengden data man får inn i en frame/pakke/datagram er definert av protokollen, dette er noe man ikke kan overskride sånn helt uten videre.

[Knopfix]

UDP baserer seg ikke på kvitteringer, og i motsetning til hva Knopfix sier er det ikke pålitelig. Man kan ha protokoller høyere oppe i stacken som sørger for retransmissjon, men per definisjon er UDP ikke pålitelig.

 

Poenget mitt var at det ikke er pålitelig men pakketapet er minimalt med dagens utstyr ifølge Cisco.

Har du lest det jeg har skrevet?

Endret 27. april 2007 av Knopfix

[ATWindsor]

Saken er at de har klart å utnytte en 10Gbit/s link over lang avstand. Det er ikke trivielt over TCP/IP fordi disse protokollene skalerer elendig når latency øker. Dette skyldes bruk av transmisjonsvindu for å unngå overbelastning av mottaker som igjen ville medført pakketap og behov for retransmisjon med ellendig ytelse som resultat.

 

Jeg skjønner ikke helt greia, for det første er det vel vanlig at det hopper innom noe på vien, og for det andre, vil ikke det alltid være et problem når man transmiterer data over nett? Jeg har liksom ikke fantasi til å se for meg at man ikke bruker en viss mengde data, med noe checksum, og overfører det, uansett protokoll, og blir latencyen høy, så må man opp i størrelse på denne enheten data for å opprettholde en viss hastighet?

 

AtW

8483320[/snapback]

Tror ikke jeg helt forsto hva du vil frem til. Men det er slik at transmissjonsvinduet må økes for å få utnyttet båndbredden. Dette har en veldefinert matematisk sammenheng. Du kan ikke under noen omstendighet få utnyttet mer av linja enn forholdet ((båndbredde * tur-retur forsinkelse)/total vindusstørrelse) tilsier. Om tallet er større eller lik 1 så kan du i teorien utnytte hele linja. Hvor store pakkene er, er ikke viktig i dette regnestykket, men generelt vil små pakker medføre mer overhead enn store pakker. Det er vel det tekniske hovedargumentet mot ATM f.eks, men ATM vil som oftest få bedre kapasitetsutnyttelse likevel.

8483423[/snapback]

 

Altså, du snakker om at TCP/IP har problemer med hy latency og høy båndbredde, men om man ser på et helt grunnleggende nivå på dataoverføring: så kan jeg ikke se for meg noen annen måte å overføre data enn nyttedata+checksum eller annen type feilsjekking. Og da må klumpen med nyttedaya+checksum økes om man har høy latency g vil ha høy bånbredde, helt uavhengig av hvilken prtokoll man bruker?

 

Altså, såvidt jeg kan skjønne må dette være et helt generelt problem, og ikke noe man kan slippe unna med en annen protokoll?

 

AtW

8483607[/snapback]

Vi snakker om to forskjellige problemer her. Det ene er overhead det andre er BDP (bandwidth delay product) de to har ingenting med hverandre å gjøre. Store pakker er fint det, men det hjelper ingenting å sende store pakker om du har høy BDP og lite TCP vindu, så vidt jeg vet er UDP lite brukt på Internett i forhold til TCP. Windows XP vil forhandle med motparten om hvor stort vinduet skal være, men algoritmen for å finne optimal størrelse er ganske dårlig og kan i følge MS bruke opp til en time på å finne optimal vindustørrelse. Vista gjør dette mye raskere. Generelt tror jeg fokus på overhead som et problem er et blindspor i denne sammenhengen. Det er ikke overhead som er førsteordens begrensning.

8483648[/snapback]

 

Jeg tror vi snakker om det samme (selv om jeg formulerer meg som et nek) Dvs BDP, det jeg mener er at: Er ikke høyt BDP et problem på helt genrell basis? Jeg kan ikek skjønne at man skal kunne snike seg unna det problemet med en annen protokoll, jeg ser ingen måte å overføre data på (med potensiale for pakketap da) der høy BDP ikke er et problem. Mer spesifikt så kan jeg heller ikke se at man ikke på generell basis bør har større størrelse på en pakke når BDP er stor?

 

 

 

AtW

[Anders Jensen]

Joda BDP er et grunnleggende problem en må håndtere, men transmissjonsvindu er bare en av flere måter å løse det på. F.eks kan du sette opp en link med fast kapasitet, som f.eks ISDN eller ATM kan gjøre. Om du så implementerer en stack uten vindu oppå der så har du løst problemet, men klart det er mer komplekst hvis en sammtidig skal ha god ressurs utnyttelse fordi nå har en jo monopolisert nettverksbåndbredde enten en benytter den eller ikke. Hvis trunkene er mye fetere enn hver kobling og en har mulighet til å håndtere unntak som f.eks en midlertidig kapasitetsredusering av koblingen så kan en likevel få nær optimal utnyttelse av en trunk.

Endret 27. april 2007 av Anders Jensen

[Olaaaaa]

UDP baserer seg ikke på kvitteringer, og i motsetning til hva Knopfix sier er det ikke pålitelig. Man kan ha protokoller høyere oppe i stacken som sørger for retransmissjon, men per definisjon er UDP ikke pålitelig.

 

Poenget mitt var at det ikke er pålitelig men pakketapet er minimalt med dagens utstyr ifølge Cisco.

Har du lest det jeg har skrevet?

8483691[/snapback]

Pakketapet kommer jo helt an på kvaliteten på linken ende-til-ende. Om du kommer inn i en ruter risikerer man veldig fort at pakken droppes i i køen. Kjør f.eks "netstat -s 2" i et kommandovindu og se under TCP-statistikken hvor mange segmenter som blir retransmittert.

 

Pakketap i form av dropping er en del av spillet. Mange protokoller baserer seg på det.

[Knopfix]

Pakketapet kommer jo helt an på kvaliteten på linken ende-til-ende. Om du kommer inn i en ruter risikerer man veldig fort at pakken droppes i i køen. Kjør f.eks "netstat -s 2" i et kommandovindu og se under TCP-statistikken hvor mange segmenter som blir retransmittert.

 

Pakketap i form av dropping er en del av spillet. Mange protokoller baserer seg på det.

 

Ja det er jo derfor TCP brukes til blant annet banktransaksjoner og annen viktig info.

Så lenge ikke bufferen på ruteren blir sprengt pga av for dårlig kapasitet i forhold til inn/ut linje skal det gå greit.

Poenget er at UDP ikke er pålitelig men har blitt "ganske pålitelig".

Tar man utganspunktet i en råtten linje er det normalt med pakketap.

 

Info om IPv6,ser ut som checksum blir fjernet fra headeren.

 

IPv6 info

Endret 27. april 2007 av Knopfix

[Olaaaaa]

Kikk litt på http://www.ietf.org/rfc/rfc2309.txt , på anbefalingen for RED. Pakkedropping har ikke noe med protokoller eller linjer å gjøre, det handler om congestion avoidance og forsøk på å rettferdig dele linjekapasiteten man har til rådighet. I mange implementasjoner begynner man pakkedroppingen allerede ved 50% fyllingsgrad på bufferet, noe som slett ikke er uvanlig. Ingen råtten linje nødvendig.

 

Nå ser jeg vi begynner å bevege oss et stykke off-topic. Var ikke meningen.

[Knopfix]

UDP Statistics for IPv4

 

  Datagrams Received    = 22622

  No Ports              = 1012

  Receive Errors        = 0

  Datagrams Sent        = 23715

 

Eks fra mitt kort.

 

Congestion er er overfylling som lett oppstår pga av mye broadcast som kan slå ut et helt nett og naturlig nok gir pakketap.

Linje ha mye å si for er linjen for lang så mister du pakker uten repeater,feks bør ikke en Cat5 være lenger enn 100m uten repeater mens fiber kan ha store lengder før en repeater må inn.

En annen sak er linjelengde til sentral.

Ble kanskje litt off topic ja

Endret 27. april 2007 av Knopfix