Onderwerp bekijken
Algemeen, maar niet gemeen.
 Snelheidsverhoging 2008
|
|
| simpliss |
Geplaatst op 10 september 2008, 08:52
|
 Activiteit  » Brabant Berichten: 3 Lid sinds: 10 sep 2008 |
In Pcoptimizer, kies tab Largest MTU ( hierbij word getracht het grootste niet gefragmenteerde pakket te vinden), hierbij moet ik de scan (verbinding) in mijn virusscanner goed keuren, dus niet zoals ik eerder vermelde in de livebox (na een dag bikkelen voor de chef wil er nog wel eens een foutje insluipen). indien je PCoptimizer gebruikt word alle info waar u om vraagt in een logje weergegeven, zal vanavond een aantal scans uitvoeren met verschillende ingegeven MTU waarde. Groenten uit Brabant The mind is like a parachute. It only functions when it's open........
|
|
|
|
| guus |
Geplaatst op 10 september 2008, 15:56
|
|
Activiteit  Berichten: 344 Lid sinds: 22 okt 2006 |
GEWELDIG  Dat tcp optimizer werkt geweldig Haal nu ineens 580 kb per seconde! Kan ik de waarde hoger zetten dan 1000 of is dat niet verstandig? Hij geeft bij largest 1500 aan trouwens. |
|
|
|
| pacod |
Geplaatst op 10 september 2008, 16:03
|
 Activiteit  » Almelo Berichten: 29 Lid sinds: 15 jul 2008 |
Wat is de default hiervan eigenlijk? Gewoon 0? |
|
|
|
| guus |
Geplaatst op 10 september 2008, 18:14
|
|
Activiteit Berichten: 344 Lid sinds: 22 okt 2006 |
Ja ik vind het ook raar maar goed het werkt! Ja ik heb hem nu op 576 staan. Veel lager heeft ook weer geen nut want als ik hem op 200 zet krijg ik 400 kb en als ik hem op 576 heb staan bijna 600. Ben er in ieder geval al blij mee! Nu hopen dat online binnekort de snelheid eens fatsoenlijk verhoogd. |
|
|
|
| rrozema |
Geplaatst op 10 september 2008, 19:22
|
 Activiteit  » Delft, 2191 meter vanaf Dt-Vhf Berichten: 2800 Lid sinds: 19 feb 2006 |
lagere mtu betekent dat je minder data per pakket kunt versturen, dus wordt de overhead groter. Aangezien de maximale doorvoercapaciteit van je lijn hetzelfde blijft, kun je met een hogere overhead dus minder data versturen. De reden dat de lijn sneller wordt door een kleinere mtu (dan de standaard van 1500) te kiezen kan meerdere oorzaken hebben, waaronder een foutief geconfigureerde router in het Online netwerk; deze staat dan bijvoorbeeld ingesteld dat hij maximaal pakketjes van 1000bytes kan doorlaten. Telkens als hij een pakket aangeboden krijgt dat groter is dan die 1000 bytes, zal hij aan de verzender vragen het op te delen in meerdere pakketten van maximaal 1000 bytes. Het opdelen van de pakketjes kost tijd en het versturen van 2 pakketjes levert meer overhead op waardoor er minder doorvoercapaciteit overblijft voor het netto dataverkeer. Een andere reden kan zijn dat het atm verkeer (tussen de livebox en de dslam) verkeerd staat ingeregeld waardoor ook weer fragmentatie en dus opdelen van pakketten en meer overhead optreedt. Nu echter niet op het IP niveau maar op het atm niveau waarover het ip verkeer gebridged wordt. Deze laatste lijkt trouwens waarschijnlijker als oorzaak omdat er op IP niveau geen melding van fragmentatie wordt gemaakt (TCP-Optimizer geeft immers nog steeds 1500 aan als maximale mtu waarde). Hopelijk kijkt er binnenkort iemand met verstand van zaken naar die waarden en ziet dan wat er fout staat. Misschien lezen ze dit wel  |
|
|
|
| TCP_IP |
Geplaatst op 10 september 2008, 20:05
|
 Activiteit Berichten: 2727 Lid sinds: 24 feb 2008 |
nou ben er ook eens stevig op gaan googlen ... Mogelijk andere oorzaak (no 3 dus) [url] http://en.wikipedia.org/wiki/Maximum_transmission_unit[/url] A higher MTU brings higher bandwidth efficiency. However, large packets can block up a slow interface for some time, increasing the lag for further packets. Dit stukje viel me dus op... Grote pakketen kan een langzame interface dus zorgen voor een opstopping als het ware (bottle-neck), waardoor de pakketten achter hem ook een vertraging oploopt.... De snelheid is er dus wel maar lijkt alsof het door een trechter moet als het ware, er gaat veel in maar komt minder uit... Als MTU dus lager gezet word kan de interface dit makkelijker aan en resulteert dus eigenlijk in een snellere verbinding !! Grotere pakketten werken ook wel maar raken gefragmenteerd wat weer leid tot een opstopping wat leidt tot een instabiele en eigenlijk trage verbinding... Als ik mijn eigen verhaal zo lees lijkt het alsof de livebox de schuldige is ... daarom zou eigenlijk iemand het eens met deze symptomen moeten/kunnen/willen uittesten met een ander ADSL2+ modem... RFC 1191 describes "Path MTU discovery", a technique for determining the path MTU between two IP hosts. It works by setting the DF (Don't Fragment) option in the IP headers of outgoing packets. Any device along the path whose MTU is smaller than the packet will drop such packets and send back an ICMP "Destination Unreachable (Datagram Too Big)" message containing its MTU, allowing the source host to reduce its assumed path MTU appropriately. The process repeats until the MTU is small enough to traverse the entire path without fragmentation. Dit bovenstaande verhaal gebeurt dus blijkbaar niet, dit gebeurt nu dus door een aantal handmatig d.m.v. TCPoptimizer.... Online blijft pakketten maar doorverzenden en past zich niet aan.... Als ik het mis heb corrigeer me alsjeblieft, dit is het resultaat van een halfuurtje googlen, lezen en logisch beredeneren (na een pilsje weliswaar  ) |
|
|
|
| guus |
Geplaatst op 10 september 2008, 20:22
|
|
Activiteit Berichten: 344 Lid sinds: 22 okt 2006 |
IP host is wat anders dan ISP host. Maar het zou inderdaad wel zo kunnen zijn dat KPN de centrales die online van hun huurt verkeerd heeft staan of dat hun een andere manier gebruiken en daar geen last van hebben. |
|
|
|
| pacod |
Geplaatst op 10 september 2008, 22:34
|
|
Activiteit » Almelo Berichten: 29 Lid sinds: 15 jul 2008 |
@simpliss thanks voor het posten van dit tijdelijk lapmiddel. Ging van een instabiele 250-350 naar een redelijk stabiele 590-620KB/s toe met de nieuwsgroepen! |
|
|
|
| rrozema |
Geplaatst op 10 september 2008, 23:20
|
|
Activiteit » Delft, 2191 meter vanaf Dt-Vhf Berichten: 2800 Lid sinds: 19 feb 2006 |
Path MTU discovery werkt alleen voor IP fragmentatie. Mijn vermoeden is dat op de ATM layer fragmentatie optreedt, de laag er onder dus. Het door Online gebruikte protocol is immers "1483 Bridged IP (RFC1483) LLC", m.a.w. het IP verkeer wordt over de ADSL verbinding ge-bridged. Heel simpel gezegd: de dslam stopt om elk IP pakketje een ATM envelopje en stuurt dat over de adsl verbinding heen naar de livebox, de livebox haalt het ATM envelopje er weer af en stuurt het originele IP pakketje weer door. Als echter de ATM envelopjes te klein zijn om het IP pakket te bevatten, dan splitst de dslam het IP pakketje in 2 of zelfs meerdere stukken en stopt die afzonderlijk in een ATM envelopje. De livebox wacht als hij zo'n stuk van een IP pakket ontvangt tot hij alle stukken compleet heeft en geeft dan in een keer het hele IP pakket door. Op de IP laag lijkt het dan ook alsof er geen fragmentatie optreedt, terwijl dat 'onder water' dus wel gebeurt. Als je, door een lagere mtu in te stellen, forceert dat elk IP pakket klein genoeg is om in een ATM envelopje te passen zorg je er voor dat er geen fragmentatie meer optreedt en krijg je netto een snellere verbinding. Wat trouwens ook heel vervelend kan zijn, is als er op meerdere punten achter elkaar fragmentatie optreedt: Voor elk pakket dat te groot is, gaat de eerste router dan splitsen in 2 pakketten, 1 grote, plus 1 kleintje voor de rest van het oorspronkelijke pakket. Als het grote pakket echter verderop weer te groot blijkt te zijn, dan splitst de 2e router dat pakket weer in 2-en: 1 grote, plus 1 voor de rest. Netto gaan er dan dus 3 pakketten over de verbinding, 1 grote plus 2 hele kleine. Omdat er veel overhead op elk pakket zit (minstens 28 bytes maar vaak zelfs meer) is het dus heel vervelend als je de gegevens krijgt aangeleverd in blokken die net te groot zijn. Het is dan handig om bij de eerste router al de grootte van het kleinste mtu in de keten in te stellen, zo voorkom je dat elk pakket in meerdere stukjes geknipt wordt. In feite is dit wat Path MTU discovery doet; zoek het grootste mtu dat nog in z'n geheel door de hele pijplijn kan en stel dat in als de mtu op de eindpunten. Dit probleem zie je nog wel eens bij vpn verbindingen: doordat de vpn eindpunten extra informatie in de header stoppen voor de beveiliging, is er minder netto ruimte beschikbaar in elk pakket dat nog steeds over dezelfde ip verbinding door dezelfde routers moet. De vpn tunnel zal daardoor een lagere mtu hebben dan de oorspronkelijke ip verbinding. Als je een volledig transparante vpn verbinding hebt, kun je zo heel inefficiente ip verbindingen maken: de path mtu discovery denkt dat hij de volledige 1500 - 28 = 1472 bytes kan gebruiken. Een programma dat zo efficient mogelijk wil communiceren probeert om elk pakketje zo vol mogelijk te maken, dus zal proberen om elk pakketje precies 1500 bytes groot te maken. De tunnel zal echter minstens 4 bytes extra in elk pakket willen stoppen, er kunnen echter maximaal 1500 bytes in een ip pakket, dus het pakket moet daarvoor gesplitst worden. Uiteindelijk wordt dan voor elk pakketje dat verstuurd wordt 1 pakketje van 1468 (= 1472 - 4) bytes verstuurd plus 1 pakketje met de resterende 4 bytes. Ondertussen wordt er echter wel 2 keer een header van 28 bytes verstuurd in plaats van 1 keer. @TCP_IP: misschien begrijp ik je verkeerd maar de situatie die jij beschrijft is toch gewoon een gevolg van de fragmentatie? Als je veel grote pakketten gaat versturen over een verbinding die fragmenteert dan krijg je vanzelf een verstopping op de plek waar de fragmentatie optreedt. Dat is toch geen 3e oorzaak? |
|
|
|
| rrozema |
Geplaatst op 10 september 2008, 23:38
|
|
Activiteit » Delft, 2191 meter vanaf Dt-Vhf Berichten: 2800 Lid sinds: 19 feb 2006 |
Quote deebee schreef: Is het nou zo dat zoiets softwarematig moet worden aangepast, of hardwarematig ? En waar dan ? Als het inderdaad op ATM niveau optreedt, dan moet je het aanpassen in de protocol instellingen van de modembank. De dslam heet dat ding officieel voor zover ik weet. Daar moet je dan ofwel de transfer unit size van het atm protocol groter maken zodat een volledig ip pakket van 1500 bytes in 1 atm pakket past of de router op ip niveau zo instellen zodat deze op ip niveau de maximale netto grootte die je in 1 atm pakket kunt stoppen doorlaat. De eerste oplossing heeft zeker de voorkeur vanuit het oogpunt van de klanten en ik denk ook wel vanuit die van Online; zo groot mogelijke pakketten overbrengen scheelt namelijk in de overhead, en daardoor in de netwerkbelasting. In het geval van de 2e oplossing zal de Path MTU discovery van windows automatisch vaststellen dat er een route is die een kleinere mtu heeft en zal elke windows machine zijn mtu instellen op die lagere mtu waarde. Zodat de data in kleinere maar meer pakketten wordt verstuurd. Meer pakketten levert echter meer overhead en daardoor een hogere netwerkbelasting op. En daarbij staat het ook nog eens slordig naar de oplettende klant toe: hij kan namelijk aan de mtu zien dat het netwerk niet optimaal presteert doordat het niet optimaal is geconfigureerd. |
|
|
|
Deze website gebruikt Awin affiliate links en Google advertenties, om deze service voor iedereen gratis te houden.
| |
| Spring naar forum: |
|
Gebruik BBcode of HTML om naar; 'Snelheidsverhoging 2008', te verwijzen!
| BBcode: | |
| HTML: |
Vergelijkbare onderwerpen
| Onderwerp | Forum | Laatste bericht | |
|---|---|---|---|
| Problemen na snelheidsverhoging (12/12/2012) | Livebox configuratie en problemen | : 5 | 22 dec 2012 |
| snelheidsverhoging november 2012 | Snelheid | : 40 | 19 dec 2012 |
| duidelijke datum snelheidsverhoging | Algemeen | : 7 | 02 sep 2008 |
| Vanaf 1 juli 2008 afronding prijzen! | Wat verandert er? | : 29 | 21 jul 2008 |
| 2008-05-14 01:12:51 - Landelijke Storing ADSL | Storing | : 7 | 16 mei 2008 |
Advertentie