Chello "knijpt" usenet providers/verkeer

[bjck]

Bart-01 schreef op maandag 16 oktober 2006 @ 11:55:
[...]


Tsja dan hebben ze bij UPC niet goed nagedacht over hun product. Iemand kiest immers niet voor een 20Mb abo om alleen maar wat te browsen / emailen, dat kun je namelijk prima met een 4Mb abo....

Dat de snelheid onder de 10% (met nntp verkeer) zakt is wel heel droevig, want op hetzelfde moment haal je nog wel de volle snelheid met http verkeer....

Blijkbaar hadden ze er niet zo op gerekend

Maar er zijn ook mensen die incidenteel wat downloaden en dat graag op dat moment snel willen hebben en daarvoor een snelle lijn nemen. Een andere groep is die veel willen downloaden en daarom een snelle lijn nemen.

Veel downloaden kan ook op een 8Mb verbinding natuurlijk, dus het is niet gezegd dat alle 'veel downloaders' 20Mb hebben. En het is niet gezegd dat iedereen die 20Mb heeft een 'veel downloader' is. UPC/Chello kan de 20Mb wel geintroduceerd hebben voor de mensen die af en toe iets snel willen hebben in plaats van veel downloaden. Maar verwachten konden ze het wel natuurlijk

Powermage schreef op maandag 16 oktober 2006 @ 12:06:
Tuurlijk is prio geven normaal, echter wanneer je verkeer gewoon een periode lang 'strak' tegen een bepaalde limiet aan staat valt het voor mij niet meer onder prio maar onder een cap, en dat doet UPC dus wel degelijk.

Je kan alleen van een 'cap' spreken als:

• Het constant tegen een bepaalde maximale snelheid zit, dus 's avonds en 's ochtends gelijk.
• Je iedere avond tussen exacte tijdstippen dit merkt dat het van maximaal naar 10% schiet en weer terug.

Als het ook maar iets schommelt of het is soms minder dan anders of een avond niet is er geen 'cap'. Dan is het de werking van prioriteit (QoS) gewoon.

Punica- schreef op maandag 16 oktober 2006 @ 12:06:
[...]


Ben ik met je eens.

Maar (nofi) dit is veroorzaakt door versatel, welke mongool brengt 'r nou een 20Mbit abbo voor 30 euro op de maand en verwacht dan niet dat dat enorm heavy leechers aantrekt.

Chello rekent dan nog een 'redelijke normale' prijs voor 20mbit, maar naar mijn mening nog steeds veel te laag, het is iig blijkbaar niet genoeg om het netwerk dusdanig op orde te houden dat men die 20Mbit ook kan (/mag) gebruiken.

De vraag is wat is nog acceptabel aan snelheid met deze priorisering van verkeerstype. Als het soms zakt naar 60% voor een half uurtje in de piektijd is het misschien meer acceptabel. Maar de hele avond en het hele weekend ook overdag + avond op 10% is wel 'vrij heftig' ja.

[Punica-]

bjck schreef op maandag 16 oktober 2006 @ 12:21:

Je kan alleen van een 'cap' spreken als:

• Het constant tegen een bepaalde maximale snelheid zit, dus 's avonds en 's ochtends gelijk.
• Je iedere avond tussen exacte tijdstippen dit merkt dat het van maximaal naar 10% schiet en weer terug.

Als het ook maar iets schommelt of het is soms minder dan anders of een avond niet is er geen 'cap'. Dan is het de werking van prioriteit (QoS) gewoon.

Niet helemaal mee eens, op je eerste punt.

1. Er kan een algehele cap staan op Usenet verkeer, dan kan het best schommelen, klant A gaat offline, dus klant B heeft meer bandbreedte en een hogere snelheid.

[Bart-01]

Volgens de definitie die hier wordt gegeven is er sprake van capping:

- de snelheid zakt terug van 2400 naar 1200 naar 800 naar 200.
- deze stappen gebeuren met tijdsintervallen
- de snelheid schommelt niet maar blijf constant op de snelheid zitten (in het weekend van s' ochtends 1100 tot 1300, 1200KB/s daarna tot middernacht 800KB/s. Het weekend daarvoor het hele weekend 200KB/s)
- ergens na middernacht is de snelheid weer maximaal

[DeluxZ]

Leuk.. Ik was dus even aan het searchen naar het grote usenet topic, omdat ik ook problemen heb met mijn snelheid. Ik heb payserver bij usenet4u en haal ook max 217kb/s at the moment. Paar maanden terug haalde ik gewoon met 1000kb/s alles binnen. Hopelijk gaan ze dit gauw fixxen bij chello anders komt er dus mooi een andere ISP, ik ga geen geld betalen als ik niet de volledige snelheid behaal door chello's toedoen

Even tracert gedaan naar usenet server

tracert news3.usenet4u.nl

Bezig met het traceren van de route naar news3.usenet4u.nl [66.250.146.191]
via maximaal 30 hops:

1 <1 ms <1 ms <1 ms my.router [192.168.1.1]
2 6 ms 6 ms 11 ms 10.50.0.1
3 9 ms 7 ms 8 ms p15225.net.upc.nl [212.142.15.225]
4 21 ms 12 ms 11 ms p14232093.net.upc.nl [212.142.32.93]
5 12 ms 13 ms 13 ms 213.46.183.93
6 18 ms 30 ms 20 ms se-sto-rc-01-ge-2-2.chellonetwork.com [213.46.16
0.214]
7 101 ms 100 ms 98 ms us-was02a-rd1-pos-1-0.aorta.net [213.46.160.106]

8 113 ms 101 ms 107 ms us-was02a-ri1-gig-1-0-0.aorta.net [213.46.190.19
4]
9 114 ms 147 ms 107 ms 63.220.220.225
10 * * 108 ms news3.usenet4u.nl [66.250.146.191]

De trace is voltooid.

Gelukkig zie ik nu dat ze het ook op andere poorten aanbieden kijken of dat wel werkt

Poort 8000, 9000, 7000 en 80 werken allemaal niet max 200kb/s

[ Voor 55% gewijzigd door DeluxZ op 18-10-2006 21:58 ]

[Bart-01]

Dit weekend (21+22 okt) was de snelheid prima. Hopen dat het zo blijft.

[Ibidem]

Vandaag overgestapt van UNS naar Eweka, omdat dit een NL aanbieder is en vanwege de goede berichten over Eweka, merk nu alleen dat ik max 366 kb/sec kan downloaden via Chello Classic

Via UNS ging dat altijd met een max van 730 kb. Dit is dus een 50% verlies... Werkt Eweka niet met andere poorten dan de standaard 119 poort?

[Bart-01]

Tekn0z schreef op maandag 23 oktober 2006 @ 12:09:
Vandaag overgestapt van UNS naar Eweka, omdat dit een NL aanbieder is en vanwege de goede berichten over Eweka, merk nu alleen dat ik max 366 kb/sec kan downloaden via Chello Classic

Via UNS ging dat altijd met een max van 730 kb. Dit is dus een 50% verlies... Werkt Eweka niet met andere poorten dan de standaard 119 poort?

Check dit topic eens: http://www.chelloo.com/forum/index.php?topic=14216.0

Overigens heb ik Giganews die werd ook gecapped. Giganews biedt ook andere poorten aan, maar het resultaat tijdens het cappen veranderde niet.

Ik ga binnenkort ook Eweka proberen, ben benieuwd of die een lagere download snelheid heeft dan Giganews

[Anoniem: 194129]

Hier in Heereveen is het sinds een week weer helemaal top, na ook maanden slachtoffer geweest te zijn van het cappen van het usenetverkeer (of traffic shaping, zoals chello zegt).

Tijden ben ik niet boven de 300kB uitgekomen met een chello extreem abo. Terwijl het via http altijd full speed gaat (dag en nacht). Maar usenet (via usernetserver, met 16 threads over 5 verschillende poorten) was dus niet vooruit te branden.

Maar sinds vorige week, van de een op de andere dag, is het weer met 18mbit downloaden geblazen, gewoon met 8 threads over 1 poort. Zou een chello netwerk issue geweest kunnen zijn, maar ik geloof daar niet zo in na alle horrorverhalen te hebben gelezen.

Nou maar hopen dat het zo blijft.

[SmoothTweaker]

Heb je wel eens in het weekend op de avond van een FTP proberen te download precies 500Kb/s

[Bartjeee]

Ik moet zeggen dat de snelheid hier flink verbeterd is, in de drukkere uren 600kB/sec en daarbuiten 950kB/sec. Hier kan ik wel mee leven .

[mdfa]

Er wordt aan bandwidth limiting gedaam bij UPC; ze zullen dat nooit publiek bekend maken, maar het gebeurt wel.

[devil-strike]

En hier is het weer raak 215KB/ps via usenet buurman met adsl2+ 12Mbit max van zijn adsl.
Als het zo doorgaat ga ik ook knijpen in me geld naar upc toe.

[devil-strike]

SmoothTweaker schreef op maandag 23 oktober 2006 @ 14:43:
Heb je wel eens in het weekend op de avond van een FTP proberen te download precies 500Kb/s

Heb wel gedownload via ftp en gewoon volle 20Mbit (2400KB/ps) dus die word niet gecapped.

[FireStarter]

Ik kan sinds gister geen gebruik meer maken van poort 119

Ligt dit aan chello ofniet?

Ik kan gelukkig wel via 1 payserver connecten via poort 1720.

Wel klote want de supersearch werkt nu ook niet.

[Strike_2]

Ik kom zelf meestal rond 9 uur 's avonds thuis en merk dat de laatste week of 2 ernstig is gesneden in mijn downloadsnelheid m.b..t. NNTP.

Het is duidelijk 'aktief beheer', omdat het meestal rond 10 uur 's nachts terug schiet naar volle snelheid.
UPC zegt zelf dat NNTP onderaan de QoS lijst komt, maat het verschil is te drastisch.

Het lijkt erop, dat ze de lijn letterlijk door zijn overboekingsfactor hakken, ongeacht het 'echte' gebruik.
(Ik merk geen verschil in HTTP snelheid met of het 'cappen' van NNTP.

Ik zou er minder problemen mee hebben als ze het verkeer naar servers -met peering- niet zouden limiteren, gezien dit geen bandbreedte kost op de AMS-IX uplink.
Als ze naar de nieuwe DOCSIS standaard willen, zullen ze -toch- de tussenliggende infra moeten upgraden, anders bezwijkt het netwerk onder de belasting die alle nieuwe 'snelle' lijnen genereren.
(en niet achteraf bijkopen, in de hoop dat de klant wel blijft...)

Ik heb zo een idee, dat KPN de komende paar maanden gouden zaken gaat doen.


Voetnoot 1: Ja het ligt dus aan UPC en niet aan de Usenet provider.
Voetnoot 2: Supersearch is vrij regelmatig instabiel. Kijk even op de SS website/forum voor updates.
Voetnoot 3: Heeft iemand al giganews met SSL geprobeerd?

[ Voor 9% gewijzigd door Strike_2 op 02-02-2008 01:46 ]

[dion_b]

Je constateert dat het aan UPC zou liggen puur en alleen omdat het rond een uur of 10 's avonds omhoog schiet.

Dat is een voorbarige conclusie - pas als je bij meerdere USP's tegelijk exact hetzelfde gedrag merkt kun je die conclusie trekken. En dan nog is de vraag of de extreme teruggang van snelheid wat je ziet door "aktief beheer" komt en niet door simpele ouderwetse capaciteitsproblemen.

Probeer het eens met een andere USP (XSNews heeft bijvoorbeeld een gratis weekabo - wel opletten want ze werken met een smerige stilzwijgende omzetting in betaalde abo...). Als de snelheid van de verbinding exact tegelijkertijd op XSNews en je huidige provider terugvalt kun je met aan zekerheid grenzende waarschijnlijkheid zeggen dat het aan UPC's kant ligt. Valt XSNews niet, of iig niet tegelijkertijd terug, dan ligt het vrijwel zeker niet aan UPC's kant, maar bij de USP, danwel de interconnect die die USP met UPC heeft.

Als het er sterk op lijkt dat het bij UPC ligt is het nog voorbarig om het effect toe te schrijven aan 'aktief beheer' - maar ook daar kun je zelf een redelijke inschatting doen. Op moment dat het op alle avonden exact even laat begint en de vertraging naar exact dezelfde waarde afglijdt, dan is je vermoeden gegrond. Begint het op verschillende tijdstippen, of is de graad van vertraging anders, dan lijkt het veel meer op een capaciteitsbottleneck - en dat ligt hoogstwaarschijnlijk *juist* op DOCSIS-vlak, dus alle reden om te upgraden - niet om 150Mbit/s aan te bieden, maar om betrouwbaarder normale snelheden aan te bieden door channel bonding.

Kortom, het moge duidelijk zijn dat je een probleem hebt die *iemand* hoort op te lossen, maar je mag even een beetje meer info napluizen/hier posten voordat je die conclusie mag stellen

[MeNTaL_TO]

dion_b schreef op zaterdag 02 februari 2008 @ 19:23:
Je constateert dat het aan UPC zou liggen puur en alleen omdat het rond een uur of 10 's avonds omhoog schiet.

Dat is een voorbarige conclusie - pas als je bij meerdere USP's tegelijk exact hetzelfde gedrag merkt kun je die conclusie trekken. En dan nog is de vraag of de extreme teruggang van snelheid wat je ziet door "aktief beheer" komt en niet door simpele ouderwetse capaciteitsproblemen.

Probeer het eens met een andere USP (XSNews heeft bijvoorbeeld een gratis weekabo - wel opletten want ze werken met een smerige stilzwijgende omzetting in betaalde abo...). Als de snelheid van de verbinding exact tegelijkertijd op XSNews en je huidige provider terugvalt kun je met aan zekerheid grenzende waarschijnlijkheid zeggen dat het aan UPC's kant ligt. Valt XSNews niet, of iig niet tegelijkertijd terug, dan ligt het vrijwel zeker niet aan UPC's kant, maar bij de USP, danwel de interconnect die die USP met UPC heeft.

Als het er sterk op lijkt dat het bij UPC ligt is het nog voorbarig om het effect toe te schrijven aan 'aktief beheer' - maar ook daar kun je zelf een redelijke inschatting doen. Op moment dat het op alle avonden exact even laat begint en de vertraging naar exact dezelfde waarde afglijdt, dan is je vermoeden gegrond. Begint het op verschillende tijdstippen, of is de graad van vertraging anders, dan lijkt het veel meer op een capaciteitsbottleneck - en dat ligt hoogstwaarschijnlijk *juist* op DOCSIS-vlak, dus alle reden om te upgraden - niet om 150Mbit/s aan te bieden, maar om betrouwbaarder normale snelheden aan te bieden door channel bonding.

Kortom, het moge duidelijk zijn dat je een probleem hebt die *iemand* hoort op te lossen, maar je mag even een beetje meer info napluizen/hier posten voordat je die conclusie mag stellen

Het is actief beheer, met SSL aan gaat het gewoon met 1,8 MB/s, zonder SSL naar dezelfde giganewsserver met een kb of 700 per seconde.

[blaCkduSt]

Strike_2 schreef op zaterdag 02 februari 2008 @ 01:43:
Voetnoot 3: Heeft iemand al giganews met SSL geprobeerd?

HitNews met SSL houdt mijn UPC Extreme verbinding strak op 2,35~2,37mb/s. Zonder SSL kom ik regelmatig niet boven de 400kb/s uit, dus het maakt hier echt duidelijk verschil.

[Anoniem: 7998]

XSNews heeft bijvoorbeeld een gratis weekabo - wel opletten want ze werken met een smerige stilzwijgende omzetting in betaalde abo...

Volgens mij had ik in het vorige topic er al op gewezen dat dit gewoon op de aanmeldpagina vermeld staat..

Overigens wordt de uplink (na maanden van bakkeleien) naar UPC maandagnacht ge-upgrade. Onze kant is klaar, alleen UPC wil het perse in hun maintenance window doen, en dat is maandag 01.00-04.00 uur..

[Anoniem: 98985]

Misschien onnodig om te melden... (of juist heel bruiknaar)
Ik had problemen met UPC, die knijpen poort 119 van de nieuwsgroepen. Ben er achter gekomen dat ik via ssl.eweka.nl (en dan je gewone login gebruiken) *nog* niet geknepen wordt... en dus de maximale snelheid uit mijn 16Mb lijn haal..... Vond dit ergens op i-net, en wilde dit zeker met jullie delen.....