Article View: nl.internet.dsl
Article #35Re: Maximale afstand wijkcentrale - DSL aansluitpunt?
From: Jan Bredenbeek
Date: Sun, 22 Jun 2003 13:25
Date: Sun, 22 Jun 2003 13:25
134 lines
9228 bytes
9228 bytes
Kryz wrote: > On Mon, 09 Jun 2003 10:50:27 +0000, Ruben van der Leij wrote: > > >>>Mensen kunnen de kwaliteit van de lijn uit hun 3 kwartjes modem van de >>>Gamma aflezen en jij wil zeggen dat dat niet kan als je een DSLAM van >>>"meerdere tonnen" hebt? >> >>Dit lijkt me meer een geval van 'een kinderhand is gauw gevuld'. > > > <snip bekende data> > >>Asteblief. Nou jij mij vertellen wat er mis is. Hoe snel is deze lijn, >>en hoe snel kan 'ie maximaal? > > > Hoe snel ie is, stond er in te lezen (8064/512), en hoe snel ie kan, dat > staat er niet. Maar die info is er zeker wel. ;-) > > Echter, heeft iemand hier ooit wel eens gehoord van de uitspraak "in het > verleden behaalde resultaten bieden geen garantie voor de toekomst"? Je > verbinding kan nog zo goed zijn, er zijn vreselijk veel omstandigheden die > de kwaliteit van de verbinding kunnen aantasten. Zoals Ruben ergens anders > ook al zei: het betreft een momentopname. Daarbij valt uit deze data nog > niet een lijnlengte te halen, toch echt wel de belangrijkste factor in de > kwaliteit van een lijn (of je lijn moet echt brak/stuk zijn). > > Klein overzicht over wat zaken die interessant zijn in dit opzicht: > > - Aanvraag komt, postcode/huisnummer combinatie geven verwachte > lijnlengte, gebaseerd op straat-afstanden (niet op werkelijke > kabellengte) > - bbned kan zelf geen lijnlengte test doen op dit punt, dit kan pas als de > lijn overgezet is, of als de lijn telefonie heeft zou het eventueel met > een 4tel meting (KPN meting over telefoniefrequentie) kunnen > - Lijn wordt omgezet, nu zien we echt wat de kwaliteit van de lijn is; > lijnlengte kan alleen gemeten worden via 4tel (KPN telefonie via > linesharing) of door monteur bbned (duur) > - Lijnkwaliteit lijkt goed, maar lijn is volgens postcodecheck > 3km lang; > mogelijkheid tot upgraden geven? Merk op: > 1 Beperking op upgraden lijn voor te lange lijnen is gebaseerd op > postcodedata, dit omdat dit de enige (!!) informatie is die _zeker_ > automatisch beschikbaar is > 2 Lijn die kwalitatief goed is bij oplevering (momentopname!), kan nog > steeds (te) lang zijn, en daardoor vreselijk gevoelig zijn voor > verandering in kwaliteit; denk aan het opleveren van meer xDSL lijnen > in de buurt > 3 Gezien (1) moet de postcodedata aangepast worden om de automatische > systemen mogelijkheid te geven de lijn te upgraden; postcodedata gaat > nooit per lijn, maar altijd per adres, en verschillende lijnen op 1 > adres kunnen grote verschillen in lijnlengte vertonen > 4 De actie bij (3) is een handmatige actie; niet erg leuk (duur) in een > automatisch proces > - Stel, postcodedata wordt geupdate, lijnlengte is korter dan 3km in die > database, lijn wordt geupgrade. Lijn werkt na 6 maanden niet meer > (goed), lijnmeting moet uitgevoerd worden: dit betekent meteen een > flinke hoeveelheid kosten voor die lijn, waardoor er minder/geen winst, > of verlies op die lijn gemaakt wordt; daarbij is de klant ontevreden > (maakt niet uit hoe goed de klant op de hoogte is van de risico's) Ja, en nu mijn eigen situatie: 1. Ik vergelijk DSL-aanbod voor mijn postcode; KPN zegt dat ik te ver woon, Demon (toen nog babyxl) zegt ja (onder voorbehoud uiteraard), Cistron (bbned) zegt ook ja onder voorbehoud, zonder dat een beperking qua snelheid genoemd wordt. Ik kies vervolgens voor Cistron vanwege de prijs/prestatieverhouding, dit in de veronderstelling dat MAXX mogelijk is en anders neem ik ook wel genoegen met 2048 of 1024. 2. Na een maand krijg ik van Cistron bericht dat bbned zegt dat ik te ver woon en dat ze alleen 512 willen leveren. Na wat heen en weer mailen krijg ik de toezegging dat er eventueel geupgrade kan worden na oplevering. Ik akkoord, lijn wordt opgeleverd op 512. 3. Cistron kijkt via provisioning systeem wat de maximaal mogelijke line rate is, komt uit op 8Mbit, wil upgrade doen en komt er dan achter dat dit bij bbned niet mogelijk is. 4. Een paar maanden later maakt bbned een fout en heb ik een week lang zonder problemen 1024. Technisch bewijs dat er meer mogelijk is geleverd :-|. BBned heeft dus blijkbaar 'beleid' dat er op meer dan 3km slechts 512 geleverd wordt, ongeacht de werkelijke omstandigheden. Helaas kom ik daar dus pas achter op het moment dat er opgeleverd is. Het zou beter zijn geweest als ik dat *vooraf* had kunnen weten, dan was de keuze destijds misschien wel anders uitgevallen. Let wel: ik beschuldig hier niemand, maar ik vind wel dat dit soort dingen vooraf duidelijk gemaakt moeten worden aan klanten die het aangaat en niet achteraf. > Opmerking van Jan in een ander deel van deze thread: "Er wordt AFAIK nog > altijd vooraf een meting gedaan, zelfs al zit je volgens de > postcodedatabase binnen de inzetregel." KPN doet dit, via 4tel (lang niet > altijd succesvol overigens), en bbned kan dit niet, of hopelijk _nog_ > niet. > > De enige logische optie wat mij betreft in dit verhaal is: het > implementeren van een automatische 4tel meting van KPN op alle lijnen die > bbned levert of geleverd heeft, en deze data verwerken per lijn, in plaats > van per adres. Jammer genoeg dekt 4tel slechts een deel van de lijnen > (voor oplevering: alle lijnen met KPN telefonie, dus niet New Line Service > (NLS), en ook niet de lijnen die in gesprek zijn of om andere technische > redenen voor 4tel onmeetbaar zijn; na oplevering: alle lijnen met KPN > linesharing die niet in gesprek zijn etc.), wat betekent dat je op twee > waardes moet gaan controleren (postcodedata en 4tel, waarbij eventueel > beschikbare 4tel voorrang heeft op postcodedata). Je zou eventueel alle > lijnen die je vanwege storingen door een monteur laat meten, ook nog een > lengte kunnen toewijzen via dit systeem, dat voorrang krijgt over de > postcodedata. > > Dit is echter een systeem implementeren dat veel geld gaat kosten (dit > heeft een enorme impact in de werking van een erg groot, bestaand en > draaiend systeem), waarmee je uitzonderingssituaties gaat proberen te > dekken. De vraag is simpelweg: levert dit meer op dan het kost, ja of nee? > Ik denk dat de belangrijkste winst niet financieel zal zijn (dit haal je > nooit uit die paar extra lijnen die je op een hogere snelheid kan leveren; > je gaat namelijk via dit systeem ook sommige lijnen juist beperken), maar > een bepaalde vorm van tevredenheid van de partners en eindgebruikers. > Zeker niet onbelangrijk, maar hoe meet je of dit in je budget past? En als je nu eens klanten *voor eigen risico* laat upgraden, met de uitdrukkelijke mededeling dat er geen garanties worden gegeven? BBned levert nu toch ook al die MAXX-lijnen zonder garantie op 8Mbit? Ik wil best ervoor tekenen dat ik afzie van iedere claim op een gegarandeerde snelheid boven 512k. Maar het lijkt erop dat ik zit te praten tegen een paar ambtenaren die beslissen over mijn asielaanvraag, i.p.v. een commercieel bedrijf dat diensten levert waarvoor ik iedere maand betaal. groet, Jan. > (kleine crosspost naar cistron.broadband vanwege enige interesse daar, FUP > wel naar nl.internet.dsl) toch maar even cistron.broadband toegevoegd omdat het hier ook over Cistron gaat.
Technical Details
Message-ID:
<bd4ahc$i0j$1@news.cistron.nl>Path:
arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-xit-09!supernews.com!64.152.100.70.MISMATCH!sjc70.webusenet.com!news.webusenet.com!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!news3.cistron.nl!news.cistron.nl!not-for-mailReferences:
<3eda651e$0$45376$1b62eedf@news.wanadoo.nl> <Pine.LNX.4.44.0306012338240.12593-100000@proteus.bredenbeek.net> <slrnbdlucm.1h3.ruben-news@its.blacklisted.nl> <Pine.LNX.4.44.0306021227550.13353-100000@proteus.bredenbeek.net> <slrnbdnc8m.7hi.ruben-news@its.blacklisted.nl> <bOlEa.10630$KF1.239438@amstwist00> <Pine.LNX.4.44.0306080243550.19564-100000@proteus.bredenbeek.net> <slrnbe8ksr.nv1.ruben-news@its.blacklisted.nl> <bc1lht$b3l$3@news.tudelft.nl> <slrnbe8pjj.oi5.ruben-news@its.blacklisted.nl> <pan.2003.06.22.03.57.09.467352@kryz.org.invalid>Show Full Headers
Complete Article Headers
X-Google-Language: DUTCH,ASCII-7-bit X-Google-Thread: 11258e,934c1e5a2c6270f2 X-Google-Attributes: gid11258e,public X-Google-Thread: f498c,3bfddfec5ac1c3eb X-Google-Attributes: gidf498c,public X-Google-ArrivalTime: 2003-06-22 06:21:50 PST Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-xit-09!supernews.com!64.152.100.70.MISMATCH!sjc70.webusenet.com!news.webusenet.com!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!news3.cistron.nl!news.cistron.nl!not-for-mail From: Jan Bredenbeek <not-for-mail@bredenbeek.net> Newsgroups: nl.internet.dsl,cistron.broadband Subject: Re: Maximale afstand wijkcentrale - DSL aansluitpunt? Date: Sun, 22 Jun 2003 15:25:04 +0200 Organization: Cistron Lines: 135 Message-ID: <bd4ahc$i0j$1@news.cistron.nl> References: <3eda651e$0$45376$1b62eedf@news.wanadoo.nl> <Pine.LNX.4.44.0306012338240.12593-100000@proteus.bredenbeek.net> <slrnbdlucm.1h3.ruben-news@its.blacklisted.nl> <Pine.LNX.4.44.0306021227550.13353-100000@proteus.bredenbeek.net> <slrnbdnc8m.7hi.ruben-news@its.blacklisted.nl> <bOlEa.10630$KF1.239438@amstwist00> <Pine.LNX.4.44.0306080243550.19564-100000@proteus.bredenbeek.net> <slrnbe8ksr.nv1.ruben-news@its.blacklisted.nl> <bc1lht$b3l$3@news.tudelft.nl> <slrnbe8pjj.oi5.ruben-news@its.blacklisted.nl> <pan.2003.06.22.03.57.09.467352@kryz.org.invalid> Reply-To: jan@bredenbeek.net NNTP-Posting-Host: cust.91.244.adsl.cistron.nl Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ncc1701.cistron.net 1056288108 18451 195.64.91.244 (22 Jun 2003 13:21:48 GMT) X-Complaints-To: abuse@cistron.nl NNTP-Posting-Date: Sun, 22 Jun 2003 13:21:48 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en In-Reply-To: <pan.2003.06.22.03.57.09.467352@kryz.org.invalid>