🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: nl.internet.dsl
Article #34

Re: Maximale afstand wijkcentrale - DSL aansluitpunt?

#34
From: Kryz
Date: Sun, 22 Jun 2003 03:57
108 lines
7381 bytes
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)

Klinkt allemaal heel makkelijk, "dan pas je toch gewoon de postcode
database aan", maar misschien komt er toch net iets meer bij kijken.

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?

Daarbij is een 4tel meting nu nog niet automatisch te doen voor bbned,
zoals ik al zei, en zou deze ook nog eens geld kunnen kosten.

Overigens, Ruben, reageerde ik op jouw posting omdat je data en
vraagstelling een goede instap waren, niet omdat ik dacht dat jij het
oneens was met de gestelde beperkingen van bbned. Je andere postings geven
voor mij duidelijk aan dat jij het _wel_ begrepen hebt. ;-)

Greetz,

Kryz

(kleine crosspost naar cistron.broadband vanwege enige interesse daar, FUP
wel naar nl.internet.dsl)

-- 
Iedereen heeft recht op mijn mening.
http://kryz.org
Technical Details
Message-ID: <pan.2003.06.22.03.57.09.467352@kryz.org.invalid>
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-xit-09!supernews.com!diablo.theplanet.net!mephistopheles.news.clara.net!news.clara.net!ecngs!feeder.ecngs.de!193.190.198.58.MISMATCH!aotearoa.belnet.be!news.belnet.be!news2.kpn.net!news.kpn.net!news.hollandcasino.net!news.cistron.nl!not-for-mail
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>

Show Full Headers
Complete Article Headers
X-Google-Language: DUTCH,ASCII-7-bit
X-Google-Thread: f498c,3bfddfec5ac1c3eb
X-Google-Attributes: gidf498c,public
X-Google-Thread: 11258e,934c1e5a2c6270f2,start
X-Google-Attributes: gid11258e,public
X-Google-ArrivalTime: 2003-06-21 20:57:11 PST
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-xit-09!supernews.com!diablo.theplanet.net!mephistopheles.news.clara.net!news.clara.net!ecngs!feeder.ecngs.de!193.190.198.58.MISMATCH!aotearoa.belnet.be!news.belnet.be!news2.kpn.net!news.kpn.net!news.hollandcasino.net!news.cistron.nl!not-for-mail
From: Kryz <me@kryz.org.invalid>
Newsgroups: nl.internet.dsl,cistron.broadband
Subject: Re: Maximale afstand wijkcentrale - DSL aansluitpunt?
Followup-To: nl.internet.dsl
Date: Sun, 22 Jun 2003 05:57:09 +0200
Organization: Cistron
Lines: 109
Message-ID: <pan.2003.06.22.03.57.09.467352@kryz.org.invalid>
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>
NNTP-Posting-Host: anduril.freshdot.net
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: ncc1701.cistron.net 1056254229 2380 195.64.85.38 (22 Jun 2003 03:57:09 GMT)
X-Complaints-To: abuse@cistron.nl
NNTP-Posting-Date: Sun, 22 Jun 2003 03:57:09 +0000 (UTC)
User-Agent: Pan/0.14.0 (I'm Being Nibbled to Death by Cats!)