
Hier de resultaten:
Your current download speed:
2864kbit/s
or
358kbyte/s
Your current upload speed:
159kbit/s
or
20kbyte/s
Dat snap ik ja, ik heb het niet speciaal nog es uitgevoerd. Gisteren of zo waren het die getallen die ik zoëven had doorgebrieft. Ik was gewoon te lui om nog eens de test te doen.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
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.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.
Is idd geen goed resultaat. Aangezien je een Speed Touch Home hebt zou ik je eens aan raden als dit zich voor doet eens in de modem te kijken naar je lijngegevens, zo kan je zien of je modem juist synct en of je lijn echt wel in orde is. Indien daar alles in orde is ligt het probleem hoogst waarschijnlijk bij je provider of bij je pc (er zijn verschillende redenen waardoor je pc je internet traffiek kan vertragen of het kan gewoon een fout zijn bij skynet die je op 'smallband' zet door een fout in hun systeem ofzo).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
Integendeel, vreselijk slecht zelfsHallo, hieronder het resultaat van uw snelheidstest, dit lijkt vrij goed.
Resultaten die onder de 128kbit/s zitten voor de download test worden niet op genomen op de last 40 page aangezien deze aanzien worden als smallband resultaten.Volgens het uur wat je in uw bericht aangeeft moet dit uw test zijn. > Skynet 2852 107 16:06 10/09/2003
Het is duidelijk dat ze je op 1.1Mbit/s hebben gezet omdat je de 3.3Mbit/s net niet aan kon.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
Het is toch wel vreemd dat je niet kan syncen op 3360kbit. Ik heb ongeveer dezelfde attenuation en noisemarge en haal zonder problemen 3360kbit. Bovendien ligt de noise margin ver boven de 6dB (logaritmische schaal) dus er scheelt blijkbaar iets met je modem.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
Ik weet niet waar je die onzin haalt, maar laat me toe je uit te leggen waarom 16kbyte/s niet mogelijk zal zijn op je traditionele go abo met een upstream cap van 128kbit/s.The Oddity schreef: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.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.
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.
Tja, wat is een verkeerde MTU ? Op een perfect controleerbaar netwerk kan je die perfect op elkaar afstemmen, maar op het internet is dat niet altijd evident.The Oddity schreef:het feit dat die mtu véél snelheids problemen oplost, als die verkeerd zou staan..
Euh... al die chatters en gamers nu die packetjes versturen van een paar tot enkele honderden bytes (welke nu eigenlijk al een enorme overhead is binnen een MTU van 1500 bytes) gaan dan plotseling allemaal packetten hebben van 16k.nck schreef:Een MTU van 16k zou misschien een beetje beter zijn.
Zijn hier practische problemen die ik over het hoofd zie ?
Hopelijk maakt het een paar dingen duidelijk (staat er erg netjes, duidelijk en makkelijk uitgelegd)...
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.
...