UPC knijpt dataverkeer nieuwsservers [deel 3]

Postcode 1019 is ook weer eens de dupe...
Ik word er niet goed van, heb net wel een mailtje naar hitnews gestuurd te vragen of zij hievan op de hoogte zijn.
Lijkt mij eerlijk als zij net als Eweka even op de frontpage een status bericht plaatsen.

Meestal stijgt de snelheid hier rond 12 uur weer. Maar voor wie morgen moet werken/school is dit geen optie.

mijn verhoging naar 60mbit gelijk weer geannuleerd... heb 60mbit niet nodig om mijn mail te bekijken en als ssl gecapt wordt houdt het ook snel op

Down 1,5mb/s en upload valt steeds weg naar usenet, komt niet ook boven de 60kb/s als die al wat doet.
Slim om net hetzelfde aan t ehouden als dat adsl biedt.
Ook de mail gehad van de klachtenlijn, er zou lichte daling merkbaar moeten zijn en ondezoek naar daling in de avond uren.....tuurlijk.
Ik vermoed dat ze lichte daling in hun klantenbestand bedoelen.....

guess2007 zei:

Down 1,5mb/s en upload valt steeds weg naar usenet, komt niet ook boven de 60kb/s als die al wat doet.
Slim om net hetzelfde aan t ehouden als dat adsl biedt.
Ook de mail gehad van de klachtenlijn, er zou lichte daling merkbaar moeten zijn en ondezoek naar daling in de avond uren.....tuurlijk.
Ik vermoed dat ze lichte daling in hun klantenbestand bedoelen.....

Klik om te vergroten...

Ergens op pagina 8 of 9 staat een brief die je naar upc kan sturen.
Ik heb de mijne net uitgeprint en zal deze vandaag nog op de post doen.
Het antwoord wat ik ook mijn eerdere mail aan upc heb gekregen staat ook ergens een paar pagina's terug.
Er is volgens upc spraken van korte en lichte daling in snelheid ))))) grappemakers

Ik heb een 10 Mb abo en haal maar 100 tot 175 kb/sec ipv 1,25 Mb

dat is gemiddeld goed 10% van de snelheid die ik zou moeten halen.
Nee ik ben er klaar mee na ruim 10 jaar ga ik weg bij upc.

Toch vreemd. Ik heb ook een 10MB verbinding en haal 700 a 800 kb. Als ze knijpen zou je verwachten dat iedere 10MB verbinding rond 700 a 800 zit en niet dat de 1 op 700 zit en de ander op 100

Michiel_XS zei:

Er staat blijkbaar een ratelimit te strak afgesteld. We maken hiervoor gebruik van een berekening die perfect past bij ADSL klanten (waar een deel overhead in zit), maar op de kabel rekenen ze die overhead niet mee. Ik doe morgenochtend wat aanpassingen en dan hoor ik graag wat je bevindingen zijn.

Overigens, welke snelheid haal je als je https://noc.xsnews.nl/100mb.bin binnenhaalt?

Klik om te vergroten...

@Michiel, het bestand van noc.xsnews.nl kan ik in het geheel niet binnenhalen, ik krijg dan alleen maar een blank scherm en zie de zandloper af en toe.

Het downloaden gaat iets beter, i.p.v. 5,3MB/s haal ik nu 5,8MB/s. Bij de buren nog steeds 7+MB/s maar dan wel overdag hoor, 'savonds zit de nachtportier van UPC met de knopjes te spelen.

Het lijkt mij beter een ticket bij jullie te openen omdat dit topic een beetje druk wordt om bovengenoemde redenen

den Tsaar zei:

@Michiel, het bestand van noc.xsnews.nl kan ik in het geheel niet binnenhalen, ik krijg dan alleen maar een blank scherm en zie de zandloper af en toe.

Klik om te vergroten...

https://noc.xsnews.nl/100mb.bin > rechter muis 'save target as / opslaan als' werkt in dat geval waarschijnlijk wel.

René [Mr. Jinx] zei:

https://noc.xsnews.nl/100mb.bin > rechter muis 'save target as / opslaan als' werkt in dat geval waarschijnlijk wel.

Klik om te vergroten...

René, voor de tweede keer vandaag

Overdrachtsnelheid: 50,0 MB/s

Is dat niet dezelfde IP-range als de newsservers? Daar gaat theorie nummer 1..... Als UPC op range zou shapen zoals XSnews aangeeft zou je dan ook geen vertraging op lopen met dat bin bestand? Of heeft Xsnews meerdere ranges compleet gescheiden van haar newsservers?

Met SSL kan je in principe de inhoud van de datapakketjes niet controleren. Je kan dus ook niet controleren op NNTP headers in een packet zitten (zitten namelijk hoger in het OSI-model en wel op laag 6). Geloof hier dus ook niet echt in....

Wat vinden jullie van deze theorie: UPC "vlagt" protocollen die men wel kent. Zoals HTTP, SIP, SMTP, FTP enz. Al het overige krijgt dan automatisch een lagere prioriteit en kan eventueel geshaped worden. Of zeg ik nu iets raars?

René [Mr. Jinx] zei:

Want?
Er zijn in nederland slechts een paar grote usenetproviders, de rest zijn allemaal resellers maar daar merk je als consument verder weinig van.
UPC kan precies zien welke externe adressen extreem veel dataverkeer genereren op het UPC netwerk. Waarschijnlijk pikken ze zo de usenet providers eruit.
Simpel weg encryptie? Laat dat simpel maar weg
Juist door de encryptie kun je niet achterhalen wat er in dat pakketje zit, dus ook niet welk protocol. Je ziet alleen dat het een SSL pakketje is. Daarom encrypt je het juist. UPC kan natuurlijk wel al het SSL verkeer knijpen, maar dan krijg je weer hele andere problemen.
Hoe betrouwbaar is deze test geweest dan? Weet je zeker dat je op het nieuwe IP adres connect, zat dat adres in een compleet andere range en had je wel SSL aanstaan?

Klik om te vergroten...

Ik merk dat je iets weet alleen jammer dat je mijn stelling wat zo relatief is als de pest benaderd met een argument die je niet eens onderbouwt, wat voor mij simpel is is wellicht voor jou complex, dat heet relativiteit.

En mijn metafoor voor de minder onlegde techneut gebaseerd op spaans en nl is een goede want encryptie zorgt ervoor dat hij niet 1,2,3 uit te lezen is, maar zoals ik al aangaf dat het maar een "theorie" is dat UPC wellicht geavanceerd hardware heeft vanwege IPv6 kan zodanig duur/ "complex" zijn dat die door de SSL heen leest want daar is dus mijn layer theorie op gebaseerd, kijkt op ander niveau naar pakket.

Hoe betrouwbaar is die test, het is geen officiele test anders had je dat wel kunnen teruglezen, maar aangezien ik op deze forum zit deel ik het mee.

Enige logica wat ik herken in jouw theorie is die over adressen die veel dataverkeer genereren.