crc fouten op vdsl

[Udo]

Beste xs4all'ers,

Hoeveel (crc) fouten op een vdsl lijn zijn 'normaal' en boven welke
aantallen mag ik de helpdesk gaan bellen?
(eerst wissel ik natuurlijk mijn 7360v2's om om zeker te zijn dat mijn
hardware OK is)

Groeten,
Udo

[FW]

Op Tue, 23 Feb 2016 15:31:37 +0100 schreef Udo <udovdh@xs4all>:

Als je meer dan 10 unrecoverable errors per uur (DSL Information >
Statistics) hebt, dan zie je haperingen in het beeld van IPTV. Dat vind ik
niet normaal/acceptabel en voldoende reden om de helpdesk te bellen.

[Erik (erikpuntnl)]

Op 23-2-2016 om 19:54 schreef FW:

Wanneer je iptv hebt dan zou dlm (*) toch al ingegrepen moeten hebben
voordat je haperingen in je beeld ziet?
Als de lijn dan slecht is dan zou je dat denk ik vooral gaan merken aan
het dalen van de snelheid.



(*) of de opvolger van dlm, er werd mij tenminste pas door een
helpdeskmedewerker verteld dat dlm is vervangen door een nieuwe lijn
management "tool".

[hwh]

On 23/02/16 20:15, Erik (erikpuntnl) wrote:
> (*) of de opvolger van dlm, er werd mij tenminste pas door een
> helpdeskmedewerker verteld dat dlm is vervangen door een nieuwe lijn
> management "tool".

Vectoring erop -> SRM. Die regelt continue bij.

gr, hwh

[Udo]

On 2016-02-23 19:54, FW wrote:
> Op Tue, 23 Feb 2016 15:31:37 +0100 schreef Udo <udovdh@xs4all>:

>> Hoeveel (crc) fouten op een vdsl lijn zijn 'normaal' en boven welke
>> aantallen mag ik de helpdesk gaan bellen?
>> (eerst wissel ik natuurlijk mijn 7360v2's om om zeker te zijn dat mijn
>> hardware OK is)
>

> Als je meer dan 10 unrecoverable errors per uur (DSL Information >
> Statistics) hebt, dan zie je haperingen in het beeld van IPTV. Dat vind
> ik niet normaal/acceptabel en voldoende reden om de helpdesk te bellen.

Hier geen IPTV dus eigenlijk nog geen functionele klachten en alleen de
getallen.
Er zijn momenten met tientallen fouten, maar zij zijn momenteel nog de
uitzondering.
Waarom krijg ik bij deze VDSL-lijn weer ADSL-achtige zaken in beeld?
Door de veel kortere lengte zou het lijnprobleem juist minder moeten zijn.
Wat kan ik zelf aan deze fouten doen behalve modem wisselen?

Udo

[FW]

Op Wed, 24 Feb 2016 10:28:22 +0100 schreef Udo <udovdh@xs4all>:

Toen ik nog VDSL had (zonder Vectoring), kon ik CRC-fouten geheel laten
verdwijnen door de Line Settings (DSL Information > Line Settings)
stapsgewijs richting Max. Stability te zetten.

[A. Dumas]

Hmm, steeds meer berichten over crc-fouten op vvdsl-lijnen. Misschien
toch structureel wat aan de hand, cq iets te proactief iedereen omhoog
gekrikt. Of de 7360 is op het randje qua specs.

[CaseYin]

Op 23-02-16 om 15:31 schreef Udo:

Beste andere XS4all-ers,

Ik heb al eerder geschreven in deze newsgroep. Ik hou de verbinding
dagelijks in de gaten en sinds mijn aansluiting januari vorige jaar liep
het fantastisch zonder fouten groot bereik 110/28. Sinds enkele weken
zie ik de DSL Central Exchange versie steeds veranderen en wordt er dus
gerommeld aan de software in de centrale zo hier en daar. DAT
veroorzaakt dat er nu sprake CRC fouten, instabiele IPTV en andere
fluctuaties. Dus laat je Frits! 7360 vooral ongemoeid voorlopig het is
de verbinding waar het een en ander mee gebeurt.

Sinds gisteren heb ik overigens geconstateerd dat mijn carrier record is
gewijzigd van A43 naar J43 en dat lijkt een stuk stabieler te zijn
(bijna geen fouten).

[Rob]

Op mijn Draytek zie ik in ieder geval geen probleem:

> adsl status
---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
Running Mode : 17A State : SHOWTIME
DS Actual Rate : 50778000 bps US Actual Rate : 22336000 bps
DS Attainable Rate :104488000 bps US Attainable Rate : 38640000 bps
DS Path Mode : Fast US Path Mode : Interleave
DS Interleave Depth : 1 US Interleave Depth : 203
NE Current Attenuation : 13 dB Cur SNR Margin : 22 dB
DS actual PSD : 5. 0 dB US actual PSD : 12. 9 dB
NE CRC Count : 0 FE CRC Count : 303
NE ES Count : 2 FE ES Count : 19
Xdsl Reset Times : 0 Xdsl Link Times : 1
ITU Version[0] : b5004946 ITU Version[1] : 544e0000
VDSL Firmware Version : 05-07-01-0A-01-07 [with Vectoring support]
Power Management Mode : DSL_G997_PMS_L0
Test Mode : DISABLE
-------------------------------- ATU-C Info ---------------------------------
Far Current Attenuation : 0 dB Far SNR Margin : 7 dB
CO ITU Version[0] : b5004244 CO ITU Version[1] : 434db0c7
DSLAM CHIPSET VENDOR : < BDCM >

(dit is na een maand uptime)

[A. Dumas]

On 24-02-16 13:07, CaseYin wrote:
> Sinds gisteren heb ik overigens geconstateerd dat mijn carrier record is
> gewijzigd van A43 naar J43 en dat lijkt een stuk stabieler te zijn
> (bijna geen fouten).

Daar switcht ie volgens mij tussen heen en weer na elke connectie-reset
door errors. Bij mij ging het in elk geval A43->J43->A43 bij de laatste
twee resets. Volgens mij verschillen die profielen alleen in het
gebruikte spectrum voor uploads, snelheden komen uiteindelijk (na een
minuutje of wat DLM) hetzelfde uit bij mij.

[Erik (erikpuntnl)]

Op 23-2-2016 om 21:11 schreef hwh:

Dank, ben ik weer bij.

Gr.

Erik

[Udo]

nu 5 en 6 dB SNR.
Line settings op max performance gezien de info van even terug.
Ik zou daar de SNR een tandje terug kunnen zetten om te zien of dat iets
verandert.

[Sylvester]

Op 24-02-16 om 16:04 schreef Udo:

Gewoon de helpdesk bellen (uiteraard eerst nieuw modem testen). Max.
performance is leuk als het weekend is (en KPN niets doet met
individuele tickets) en als tijdelijke oplossing. Op termijn lost het
niets op en helpdesk/kpn krijgen verkeerde informatie over je lijn.

[Wessel van Norel]

Op vrijdag 26 februari 2016 07:33:16 UTC+1 schreef Sylvester:

Ik, als nieuwe klant, had ook last van "veel" CRC errors (genoeg om storing op de TV te hebben, niet genoeg voor een "echt" instabiele lijn). Vandaag KPN monteur 6 gesproken. Deze was door XS4ALL expliciet aangestuurd om een poort wissel uit te voeren. Dit is echter niet gedaan, maar wat men wel gedaan heeft is de poort "resetten / history wissen". De monteur gaf aan dat er nog trainings data van een vorige klant op de poort aanwezig was en dat dit voor deze CRC errors zou kunnen zorgen. En het lijkt er i.d.d. op dat dit geholpen heeft, want tot nu toe zie ik 0 CRC errors.

Ik weet niet of een van jullie hier iets aan heeft, voor mij zou het fijn zijn geweest als ze dit veel eerder in het traject al een keer geprobeerd zouden hebben.

[Wessel van Norel]

Op vrijdag 26 februari 2016 20:46:43 UTC+1 schreef Wessel van Norel:

> want tot nu toe zie ik 0 CRC errors.

... Don't jinx it. Zojuist weer de eerste "piek" van 14 CRC errors binnen gekregen. Hopelijk was het een hickup, maar ben bang dat we toch weer verder moeten met de KPN monteurs.

FRITZ!Box 9 8 0.14 14
Central exchange 0 0 0 0

[BUSSIE]

Heb hier exact hetzelfde probleem.

KPN monteur is langgeweest en heeft e.e.a. aangepast in centrale en leek
even goed te zijn.

Is weer mis.

Gebeld met XS4ALL en weer het bekende riedeltje eerst aflopen van
kabeltjes enz enz terwijl dat al gebeurd is.

Opnieuw KPN-monteur laten opdraven wil men niet zo maar doen.

Moet eerst weer een paar dagen het aanzien, hoe stabiel is de boel.

De lijn is er al weer 2 keer uitgeklapt binnen 2 dagen.

Begin er echt moe van te worden van deze instabiele situatie (duurt nu
al zeker 4 maanden)

Dinsdag wordt ik weer gebeld door XS4ALL. Ben benieuwd wat men dan gaat
doen als men ziet dat de boel er weer meerdere keren uitgeklapt is.

Tijd om terug te gaan naar non-vectoring? Ze zorgen er maar voor dat dat
kan. Toen was de boel super-stabiel.
Dan wat maar minder hoge upload.

Groet,

BUSSIE

[Udo]

Seconds with Unrecoverable errors (CRC)
errors (ES) many Errors (SES) per minute Last 15 minutes
FRITZ!Box 18 15 7933 0
Central exchange 1 1 0 0

Wat is er aan de hand? Het /was/ veel stabieler.

[Dirk T. Verbeek]

Op 27-02-16 om 14:29 schreef Udo:

Er zit bij jou in de buurt een Rus of Chinees die op dat moment een
sterke kortegolfzender gebruikt?

[BUSSIE]

Ik heb dit de laatste tijd ook.

Vandaag gebeld met XS4ALL omdat problemen maar blijven aanhouden en KPN
kan niks vinden.

Krijg nieuwe Fritzbox 7369 toegestuurd (heb nu de 7360).

Ben benieuwd of dat eventueel de oplossing is.

Groet,

BUSSIE

[Udo]

On 2016-02-27 15:19, Dirk T. Verbeek wrote:
>> Seconds with Unrecoverable errors (CRC)
>> errors (ES) many Errors (SES) per minute Last 15 minutes
>> FRITZ!Box 18 15 7933 0
>> Central exchange 1 1 0 0
>>
>> Wat is er aan de hand? Het /was/ veel stabieler.
>>
> Er zit bij jou in de buurt een Rus of Chinees die op dat moment een
> sterke kortegolfzender gebruikt?

Hoe dat effectief aan te tonen?
(dvb-T stick en beperkte tooling bij de hand...)


Udo

[Udo]

On 2016-02-27 15:19, Dirk T. Verbeek wrote:

>> Seconds with Unrecoverable errors (CRC)
>> errors (ES) many Errors (SES) per minute Last 15 minutes
>> FRITZ!Box 18 15 7933 0
>> Central exchange 1 1 0 0
>>
>> Wat is er aan de hand? Het /was/ veel stabieler.
>>
> Er zit bij jou in de buurt een Rus of Chinees die op dat moment een
> sterke kortegolfzender gebruikt?

Waarom ziet KPN/xs4all dit ook niet en wordt er niet op geacteerd?
Hoe lastig is het om een lijstje te maken van alle lijnen van type X
waarop meer dan Y fouten per Z tijd voorkomen?
Het is 2015 geweest....!


Udo

[Dirk T. Verbeek]

Op 27-02-16 om 15:52 schreef Udo:

Ik bedoelde het enigszins humoristisch.

Maar heb ook het tegengestelde meegemaakt.
Een flat boven een datacenter, radio-ontvangst was onmogelijk.

Voor m'n werk leer ik m'n nieuwe collega's altijd om tijdelijke
dataverbindingen niet eventjes 'snel' door een goot met dikke
stroomkabels te gooien, het geeft gegarandeerd storing.

[Roeland Jansen]

ik win. Ik heb er ondertussen 7 gehad. "Gelukkig" heeft buurman een paar huizen verderop hetzelfde probleem...

Ondertussen begint hier de irritatie te kwispelen na een maand of 8 rommel.

[Wessel van Norel]

Op maandag 29 februari 2016 09:36:08 UTC+1 schreef Roeland Jansen:

Gelukkig heb ik sinds die tijd nog 1x een hikje van 16 CRC errors gehad en daarna helemaal niet meer. Het "schoonmaken" van mijn poort heeft daadwerkelijk geholpen.

[FW]

Op Mon, 29 Feb 2016 10:42:45 +0100 schreef Wessel van Norel
<delg...@gmail.com>:

Nog meer (helaas): vandaag 156 CRC-error tussen 11 en 12 uur:

http://s11.postimg.org/8bi56ge43/29_02_2016_1241.jpg

[Dirk T. Verbeek]

Op 29-02-16 om 12:45 schreef FW:

Zie ik dat nou goed, 19:00 en net voor de middag?
Dan denk ik aan iemand die z'n magnetron aanzet.
Of een andere oven of kookplaat met een nare voeding.

[FW]

Op Mon, 29 Feb 2016 16:47:35 +0100 schreef Dirk T. Verbeek
<dver...@xs4all.nl>:

Zou kunnen. Maar dan heeft die magnetron wel erg lang aangestaan. Zie de
'score' van afgelopen avond: 3960 CRC errors van 22 tot 23 uur:

http://s13.postimg.org/uctd02rqv/01_03_2016_0021.jpg

Gelukkig was ik niet thuis, zodat ik me niet kapot hoefde te ergeren voor
een tv met stilstaande beelden.

[Udo]

On 2016-02-24 16:04, Udo wrote:
> nu 5 en 6 dB SNR.
> Line settings op max performance gezien de info van even terug.
> Ik zou daar de SNR een tandje terug kunnen zetten om te zien of dat iets
> verandert.

Bij de Line Settings nu de 'intended SNR'voor de 'receive direction' een
tandje lager gezet...
'ns Bezien wat dat oplevert.

Udo

[Udo]

On 2016-03-01 05:50, Udo wrote:
> Bij de Line Settings nu de 'intended SNR'voor de 'receive direction' een
> tandje lager gezet...
> 'ns Bezien wat dat oplevert.

Niet veel:
Net tweede tandje omlaag geprobeerd.
Wat ik dan zie is een lijn die opkomt met 90/33 en 9 om 6dB SNR.
De 90 loopt dan op en de SNR gaat dan richting 5 om 6 dB.
Dus wederom lang leve de beroerde DSl-technologie die NIETS is veranderd
sinds ADSl-0:
Als er nog steeds geen enkele effectieve controle is op snelheid versus
SNR, wat blijft er dan nog over aan verkooprehotriek m.b.t. VDSL?

Groeten,
Udo

[Udo]

On 02-03-16 09:38, Udo wrote:
> Dus wederom lang leve de beroerde DSl-technologie die NIETS is veranderd
> sinds ADSl-0:

Als ik met een SNR van 5 dB de voornoemde observaties kan doen
(crc-fouten, hersynchronisatie, etc), hoe kan ik dan regelen dat 'men'
een dBtje meer signaal op de lijn zet?

(andere mogelijkheden heb ik kennelijk niet gezien de toegeaste technologie)

Udo

[FW]

Op Wed, 16 Mar 2016 15:11:54 +0100 schreef Udo <udovdh@xs4all>:

Als je CRC-fouten blijft zien, zou ik onder Internet -> DSL Information ->
Line Settings -> 'Use previous DSL version' eens proberen. Deze
'workaround' werkt bij mij.

[Udo]

On 16-03-16 16:37, FW wrote:
>> (andere mogelijkheden heb ik kennelijk niet gezien de toegepaste

>> technologie)
>
> Als je CRC-fouten blijft zien, zou ik onder Internet -> DSL Information
> -> Line Settings -> 'Use previous DSL version' eens proberen. Deze
> 'workaround' werkt bij mij.

Dit dan maar gedaan. (dank voor de tip!)
Het bizarre is dat de Line Settings, Receive direction,
Intended signal-to-noise ratio hier wel lijken te werken!
Ik zie in ieder geval met standje 'midden' dat de snelheid op 87107
blijft steken en dat de SNR op 12 blijft.
De snelheid loopt dus niet verder op en de SNR blijft constant.
12 dB is wat aan de ruime kant dus we gaan een stapje naar rechts...


Udo

[Udo]

On 19-03-16 15:55, Udo wrote:
> De snelheid loopt dus niet verder op en de SNR blijft constant.
> 12 dB is wat aan de ruime kant dus we gaan een stapje naar rechts...

Op max snelheid blijft de SNR op 10 dB steken. Nog steeds wat aan de
hoge kant maar we gaan nu de stabiliteit m.b.t. CRC fouten en
synchronisatie observeren.

Udo

[Udo]

On 19-03-16 16:17, Udo wrote:
> Op max snelheid blijft de SNR op 10 dB steken. Nog steeds wat aan de
> hoge kant maar we gaan nu de stabiliteit m.b.t. CRC fouten en
> synchronisatie observeren.

In de korte tijd tot nu:
Véél minder fouten. Geen hersynchronisaties.
Wel een rare 0 dB 'Line attenuation' in de ' send direction'.
De ontvangstrichtign staat nu op 9 dB SNR bij 94047 KBit/s.

Udo

[FW]

Op Mon, 21 Mar 2016 16:12:29 +0100 schreef Udo <udovdh@xs4all>:

Line attenuation (send) staat hier ook op 0 dB.

In de nacht van zondag op maandag is hier 1 resync geweest (niet door mij
gedaan).
De SNR (receive) is daarna van 16 naar 14 dB gegaan en current van 49
Mbit/s naar 68 Mbit/s.

Het aantal CRC-fouten blijft al twee weken op nul staan :)

Max. DSLAM throughput kbit/s 111216 33032
Min. DSLAM throughput kbit/s 784 232
Attainable throughput kbit/s 97350 41271
Current throughput kbit/s 68194 30749
Seamless rate adaptation off off

Latency 4 ms 8 ms
Impulse noise protection 73 2
G.INP on off

Signal-to-noise ratio dB 14 5
Bitswap on on
Line attenuation dB 14 0

Profile 17a
G.Vector full full

Carrier record A43 A43

[Udo]

On 21-03-16 16:12, Udo wrote:
> In de korte tijd tot nu:
> Véél minder fouten. Geen hersynchronisaties.
> Wel een rare 0 dB 'Line attenuation' in de ' send direction'.

> De ontvangstrichting staat nu op 9 dB SNR bij 94047 KBit/s.

Tot nu toe:
Geen hersynchronisaties.
Een enkele 'unrecoverable error' per uur, zo af en toe.
9 dB SNR.
Seamless rate adaptation staat `off` (was `on` met de normale dsl firmware)

errors (ES) many Errors (SES) per minute Last 15 minutes

FRITZ!Box 17 0 0 0
Central exchange 100 0 0.03 5

Minder beroerd dan het was.

[Udo]

On 25-03-16 10:52, Udo wrote:
> Minder beroerd dan het was.

Gisteravond was de lijn kennelijk weer even plat.
7 dB SNR omlaag met 101 Mbit/s.

42821 fouten per minuut nu.
Dat is een fors verschil voor die paar Mbit verhoging; ook heb ik niet
om deze verandering gevraagd.
Dus waarom doet a.d. 2016 dit soort eenvoudige technologie zo beroerd
zijn werk?

Wat moet er geburen voordat KPN/xs4all een tikje meer signaal door de
straatkasten op de lijn laat zetten?


Udo

[Udo]

On 27-03-16 12:23, Udo wrote:
> Wat moet er geburen voordat KPN/xs4all een tikje meer signaal door de
> straatkasten op de lijn laat zetten?

Vannacht om even na 2 uur maar ook vanmiddag om even na 13:00 uur was er
een onderbreking.
Nu staat de lijn op 94 Mbit met 10 dB SNR omlaag.
ALs de oudere firmware stabieler is, waarom dan geen seamless rate
adaption met werkende line settings zonder onderbrekingen?
Kortom: ofwel de dslam ofwel de fritzbox ofwel beide maken er maar een
potje van.
Kan een van de experts uitleggen waarom zoiets normaal gevonden moet worden?

Udo


PS:

Receive direction Send direction

Max. DSLAM throughput kbit/s 111216 33032
Min. DSLAM throughput kbit/s 784 232

Attainable throughput kbit/s 109702 38674
Current throughput kbit/s 94372 30654

Seamless rate adaptation off off

Latency 4 ms 8 ms
Impulse noise protection 73 2
G.INP on off

Signal-to-noise ratio dB 10 5
Bitswap off off
Line attenuation dB 4 0

[Udo]

De lijn hersynchroniseert elke paar dagen, zo lijkt het.
Nu is het weer (even, 2.5 dag) stabiel.

Door een betrokken collega werd ik geattendeerd op deze url:
https://pqcc.soap.dslorder.nl/pqcc/v7.0/pqcc.aspx

Kan iemand in nederlands uitleggen wat ik met die info kan?

Groeten,
Udo

[Timo]

Niets. Het is een SOAP interface naar een availability checker, dat wordt
door provisioning systemen gebruikt om voorafgaand aan een bestelling te
bepalen welke WBA paketten leverbaar zijn op het opgegeven adres.

--

Timo

[Coen]

On 7-4-2016 15:11, Udo wrote:
>
> https://pqcc.soap.dslorder.nl/pqcc/v7.0/pqcc.aspx

Grappig,
je kan per huisnummer zien of ze breedband van KPN hebben.

Iemand zin om de hele postcode database er even doorheen te halen?

[Udo]

Geef me een lijstje postcodes en ik maak een scriptje...


Udo

[Paul Slootman]

In bash:

echo {1..9}{0..9}{0..9}{0..9}{A..Z}{A..Z}

:-)


Paul

[Udo]

xs4allers,

Na een soortgelijk debakel op vrijdagavond rond 18:04, zonet (zondag
10-4-2016) weer wat:

Er was een stabiel-te-achten sessie van 93/33 met 9 dB SNR omlaag.
Maar:

~15:34 carrier weg (geen sync, geen trainng)
15:41 training
Daarna, na wat minuten weer een ppp sessie.
En er kon gepingd worden.
Daarna weer even niet.
En even later weer wel.

Wat voor fijne indruk moet men dan krijgen van het xs4all/kpn netwerk?
Allereerst de carrier: waarom moest die volledig weg?
Dan het achterliggende netwerk: hoe labiel is dat wel niet?

Welke insiders kunnen uitwijden?
Wat is hier aan de hand?

[Rob]

Udo <udovdh@xs4all> wrote:
> Wat is hier aan de hand?

Er is iemand een beetje aan het zeiken geloof ik...

[Udo]

Als je een gegrond probleem op die manier beschrijft vermoed ik dat je
woordkeus meer op jou van toepassing is.

Udo

[Rob]

Ik heb het met name op het woordgebruik in jouw posting...

[Miquel van Smoorenburg]

In article <570a5a69$0$4026$e4fe...@newszilla.xs4all.nl>,

Dit soort dingen ligt niet aan het netwerk, maar is altijd een
individuele issue van het pad tussen je modem en de DSLAM.
Modem defect, interne bekabeling niet in orde, storing in de
externe bekabeling, storing in de poort op de DSLAM, dat soort
dingen. Dat is niet vanuit de nieuwsgroepen verder te analyseren.

Mike.

[Udo]

On 11-04-16 09:46, Miquel van Smoorenburg wrote:
>> Wat voor fijne indruk moet men dan krijgen van het xs4all/kpn netwerk?
>> Allereerst de carrier: waarom moest die volledig weg?
>> Dan het achterliggende netwerk: hoe labiel is dat wel niet?
>
> Dit soort dingen ligt niet aan het netwerk, maar is altijd een
> individuele issue van het pad tussen je modem en de DSLAM.

Gaat die verbinding er dan vier minuten tussenuit en stoppen de
kabouters dan dat touwtje weer terug?

> Modem defect,

Uit te sluiten en uitgesloten (!). Ik heb er twee.

> interne bekabeling niet in orde,

Al maanden hetzelfde korte draadje van minder dan een meter.

> storing in de
> externe bekabeling,

Is er daardoor minuten lang geen enkele sync?
Xs4all wist over oorzaak/aanleiding niets te melden.
Hoe moet ik dan de reden/oorzaak iets boven tafel krijgen?

> storing in de poort op de DSLAM,

Dat is des KPNs/xs4alls.

dat soort
> dingen. Dat is niet vanuit de nieuwsgroepen verder te analyseren.

Ik zie in dee storingen een trend die ernstiger zichtbaar werd, niet
alleen bij mij, vanaf het moment dat we naar snelheden boven 50/5 gingen.

Ik begrijp de samenhang tussen vermogen en overspraak voor een deel maar
laat ons dan een stabiele verbinding hebben!
Kies andere apparatuur, andere firmware, andere instellingen; ik ben de
klant dus hoef dat niet uit te zoeken.
Deze *DSL ruikt nog even brak als bij ADSL-1 en 2+.
/Dat/ is de drijfveer voor mijn geschrijf.

Groeten,
Udo

[FW]

Op Mon, 11 Apr 2016 15:39:38 +0200 schreef Udo <udovdh@xs4all>:

> Gaat die verbinding er dan vier minuten tussenuit en stoppen de
> kabouters dan dat touwtje weer terug?

Heb je die problemen ook bij gebruik van Previous DSL version?

[Udo]

On 11-04-16 17:13, FW wrote:
>> Gaat die verbinding er dan vier minuten tussenuit en stoppen de
>> kabouters dan dat touwtje weer terug?
>
> Heb je die problemen ook bij gebruik van Previous DSL version?

Inderdaad.
Nu weer andere modem er aan, die draait met de normale DSL versie.
(hang met de desk aan de telefoon)

Groeten,
Udo

[Udo]

On 11-04-16 17:47, Udo wrote:
> Nu weer andere modem er aan, die draait met de normale DSL versie.

Seamless rate adaption is hier uit voor up en downlink.
Is dat normaal geworden?
Of waarvan afhankelijk?

Udo

[Udo]

On 11-04-16 17:48, Udo wrote:
> Is dat normaal geworden?
> Of waarvan afhankelijk?

Gisteravond (eind van de middag) was de DSLAM na krap 24 uur 'up' zijn
van de lijn de weg helemaal kwijt.
Tien minutne geen sync, daarna een 9/1 Mbit verbinding zonder vectoring
die niet lang in standbleef, afgebroken synchronisaties, etc.
Sinds circa vannacht half een is de verbinding weer normaal en voorzien
van seamless rate adaption.
Werkt KPN 's nachts door of is dit een teken dat de inpandige straatkast
te warm was?

Udo

[A. Dumas]

On 13-04-16 05:45, Udo wrote:
> Werkt KPN 's nachts door

Zie news:xs4all.announce

[Udo]

Dank, maar er staan in Gorinchem vast meerdere DSLAMs.
De storingsmelding is dus weinig specifiek... :-)

Udo

[A. Dumas]

Het gaat om aankondigingen van onderhoud en de daarin vermelde
tijdstippen. Dat is vrijwel altijd 's nachts, ja.

[Udo]

On 13-04-16 05:45, Udo wrote:

> Gisteravond (eind van de middag) was de DSLAM na krap 24 uur 'up' zijn
> van de lijn de weg helemaal kwijt.

> Tien minuten geen sync, daarna een 9/1 Mbit verbinding zonder vectoring

> die niet lang in standbleef, afgebroken synchronisaties, etc.
> Sinds circa vannacht half een is de verbinding weer normaal en voorzien
> van seamless rate adaption.
> Werkt KPN 's nachts door of is dit een teken dat de inpandige straatkast
> te warm was?

Sindsdien verstreken 3 dagen en 12 uur zonder een enkele fout, zonder
hersynchronisatie, etc.

Groeten,
Udo

[Udo]

On 2016-04-16 13:11, Udo wrote:
> Sindsdien verstreken 3 dagen en 12 uur zonder een enkele fout, zonder
> hersynchronisatie, etc.

Maar net nu dus WEL een hersynchronisatie. Waarom dan toch asl we
seamless rate gedoe hebben?

Udo

[Udo]

On 2016-04-18 09:20, Udo wrote:
> Maar net nu dus WEL een hersynchronisatie. Waarom dan toch als we
> seamless rate gedoe hebben?

En wat is Carrier record A43c? Tot nu toe alleen A43 en J43 ofzo?
De c is nieuw...

Udo

[Wim_TC]

Op woensdag 20 april 2016 16:01:04 UTC+2 schreef Udo:

Bij een Clean Start op van xDSL kunnen de Carrier Sets A43, J43 en A43c gebruikt worden. In de carrier sets worden de sub-carriers nummers aangegeven die gebruikt worden bij de opbouw van je xDSL verbinding. In die fase worden de kenmerken van de verbinding afgetast. Meestal is er een Carrier set swap na een verbroken verbinding. Dus A43->J43->A43- enz. Daarbij komt in dit ritueel ook A43c wel voor.

[Wim_TC]

Op woensdag 20 april 2016 20:21:30 UTC+2 schreef Wim_TC:

> > En wat is Carrier record A43c? Tot nu toe alleen A43 en J43 ofzo?
> > De c is nieuw...

------------------------------------------------------------
Carrier set Upstream Downstream
Freq Ind. Pwr Freq Ind. Pwr TX mode
------------------------------------------------------------
A43 9 17 25 -1.65 40 56 64 -3.65 duplex only
A43C (Note 1) 9 17 25 -1.65 257 293 337 -3.65 duplex only
J43 9 17 25 -1.65 72 88 96 -3.65 duplex only
------------------------------------------------------------

Note 1:
In some jurisdictions it may be necessary to limit the maximum
downstream power level, for example -23.65 dBm/carrier where
the PSD is limited to -60 dBm/Hz.

Bron:
Document: TBPUJ702/MC-128R3.pdf

=-=

[Paul]

de z.g. rituele aftasting :P
P.