
Hier de resultaten:
Your current download speed:
2864kbit/s
or
358kbyte/s
Your current upload speed:
159kbit/s
or
20kbyte/s
Blue-Sky schreef:@Massachusetts
Hier kan je resultaten zien > Klik op view the last 40 test results
http://www.userbase.be/forum/portal.php?show=speed
Zo kan je vergelijken met andere tests
Heatryn schreef:Heb even naar die laatste 40 resultaten gegeken en die zien er inderdaad wel zeer goed uit. Ben precies één van de snelste met een Skynet Go abonnement.
Anonymous schreef:http://www.adslbox.be speed test results:
- Download speed : 24 kbit/s or 3 kbyte/s
- Upload speed : 96 kbit/s or 12 kbyte/s
Wed Sep 10 2003 at 16:06:10 UTC+0200
dit zijn mijn resultaten.
mijn adsl bij belgacom heeft meestal een goede snelheid maar in die 6 maand die ik bij belgacom ben heb ik al paar keer enkele dagen of weken met snelheden zoals dit gezeten terwijl ik nog nooit volume overschreden heb(heb zelfs nog lege volumepacks staan)
technieker is al is geweest,zei dat alles goed was en heeft me toen andere modem gegeven en na een paar weken had ik het weer zitten.
op belgacom zeggen ze enkel: je lijn is goed.
dat snelheid niet is wat ze beloven ok maar hiermee kun je niet eens deftig surfen.
kheb speedtouch home btw
Hallo, hieronder het resultaat van uw snelheidstest, dit lijkt vrij goed.
Volgens het uur wat je in uw bericht aangeeft moet dit uw test zijn. > Skynet 2852 107 16:06 10/09/2003
Anonymous schreef:sorry was iets vergeten.
ga die test nu doen :
downstream:
attainable line rate: 3672 kbit/sec
attainable ATM rate: 3296 kbit/sec
used line rate : 1372 kbit/sec
fast used atm rate: 1120 kbit/sec
interleaved used atm rate : 0 kbits/sec
rel. capacity occupation : 37
noise margin : 19 dB
line attenuation : 51 dB
output power : 19dBm
downstream:
attainable line rate: 3672 kbit/sec
attainable ATM rate: 3296 kbit/sec
used line rate : 1372 kbit/sec
fast used atm rate: 1120 kbit/sec
interleaved used atm rate : 0 kbits/sec
rel. capacity occupation : 37
noise margin : 19 dB
line attenuation : 51 dB
The Oddity schreef:Heatryn schreef:Heb even naar die laatste 40 resultaten gegeken en die zien er inderdaad wel zeer goed uit. Ben precies één van de snelste met een Skynet Go abonnement.
Je zal wel Plus abonnement bedoelen, tenzij je contacten hebt binnen BGC. Of tenzij je al een optie package hebt voor meer upload (al dacht ik dat die nog ni released waren), want 20Kbyte/s up kan je niet halen met een go.
Normaal synchroniseer je met adsl go aan d:3360&u:128
128/8=16 --> 16kbyte/s is max, wat niet véél gehaald wordt. Slechts met héél goede, lijnen, modem, korte range, etc etc.
Vermoed dat je dus een plus hebt.
The Oddity schreef:het feit dat die mtu véél snelheids problemen oplost, als die verkeerd zou staan..
nck schreef:Een MTU van 16k zou misschien een beetje beter zijn.
Zijn hier practische problemen die ik over het hoofd zie ?
...
De zendende en de ontvangende TCP-entiteit wisselen data uit in de vorm van segmenten. Een segment bestaat uit een vaste header van 20 bytes (plus een facultatief gedeelte) gevolgt door nul of meer data bytes. De TCP-software beslist hoe groot de segmenten moeten zijn. De TCP-Software kan data uit verschillende schrijfacties in één segment combineren of data uit één schrijfactie over meerdere segmenten verdelen. Voor de segmentengrootte gelden twee limieten. Ten eerste moet elk segment, inclusief de TCP-header, in 65.535 bytes van de payload van IP passen. Ten tweede heeft elk netwerk een maximale tranfer-unit (MTU) en een segment moet in de MTU passen. In de praktijk is de MTU in het algemeen een paar duizend bytes groot en legt daarom een bovengrens op aan de segmentgrootte. Als een segment door een reeks netwerken reist zonder te worden gefragmenteerd en dan een netwerk bereikt waarvan de MTU kleiner is dan het segment, verdeelt de router op de grens het segment in twee of meer kleinere segmenten.
Een segment dat te groot is voor een netwerk waar het doorheen moet, kan door een router in een aantal segmenten worden opgesplitst. Elk nieuw segment krijgt zijn eigen IP-Header, zodat fragmentatie door routers de totale overhead vergroot (omdat elk nieuw segment 40 bytes headerinformatie toevoegt).
TCP-entiteiten gebruiken het sliding window protocol. Wanneer een zender een segment zendt, start hij ook een timer. Wanneer het segment bij de bestemming aankomt, zendt de ontvangerende TCP-entiteit een segment (met data, als die er is; anders zonder data) terug met een bevestigingsnummer dat gelijk is aan het volgende volgnummer dat de TCP-entiteit verwacht. Als de timer van de zender afloopt voor de bevestiging binnenkomt, zendt hij het segment opnieuw.
Hoewel dit protocol simpel klinkt, zijn er veel facetten, die zullen we nu bekijken. Omdat segmenten gefragmenteerd kunnen worden, is het bijvoorbeeld mogelijk dat een deel van een verzonden segment aankomt en door de ontvangende TCP-entiteit bevestigd wordt, maar dat de rest verloren gaat. Het is ook mogelijk dat segmenten niet in de oorspronkelijke volgorde aankomen. Zo kunnen bijvoorbeeld de bytes 3072-4095 arriveren, maar niet bevestigd worden omdat de bytes 2048-3071 er nog niet zijn. Segmenten kunnen onderweg ook zo lang vertraagd zijn dat de timer bij de zender afloopt en de zender ze nogmaals zendt. Als een opnieuw verzonden segment een andere route volgt dan het oorspronkelijke segment en anders wordt gefragmenteerd, kunnen brokstukken van het origineel en van het duplicaat aankomen, zodat er een zorgvuldige administratie nodig is om voor een betrouwbare bytestroom te zorgen. En ten slotte is het, met zoveel netwerken in het Internet, mogelijk dat een segment zo nu en dan terechtkomt in een netwerk met congestie (of een uitgevallen netwerk) op weg naar zijn bestemming.
...