Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[kitz]

With ADSL the payload frame contains 2 channels.  FAST or Interleaved. 

Since 21CN, BT doesnt appear to use the FAST channel (FAST path) at all, and all data within the frame uses the Interleaved channel.  (Its up to the Network provider how they construct their framing parameters).

However a depth of 1 interleaving means thats bits are contiguous and not chopped up, therefore almost the equivalent of FAST.

Error Correction (RS Coding) and INP is a separate configuration to Interleaving. Historically if Interleaving was switched on (ie move from fast path to interleaved path), then Error Correction (RS) would be switched on too.  With FTTC (and 21CN adsl2+) because all data is sent in the interleaved channel then its possible for the DLM to use INP, Error Correction & Interleaving depth as 3 separate configurations.    So you can see Error Correction occur without any changes in interleaving depth.   

With FTTC Error Correction appears to occur 'on the fly' & whether its something to do with INP & PhyR  - Ive not looked in to.

[kitz]

Thanks Eric.

I am still in two minds over what to do now. I might dig out the HG622 and HG612 and see how I set them up as modem only so I can still use the ZyXEL as a router, I an also get stats from either as they are unlocked. I'll definitely leave it for now and see how it goes for a few days. The error count now is less than it was and actually using the connection seems fine. In a week or so I might try one of the Huawei routers as a modem and check the difference in error rates. Dont really want two devices but as a test it is fine for a while.

Stuart

It would be interesting to see a comparison if you do.   Not all of us have seen this behaviour.  Practically all users of the Zyxel get a higher bit rate (higher sync speed). afaik theres only les... and I think chrys who said there was a slight increase in his errors.

Not all see the increased errors - I certainly dont.  In fact when I recently had a line issue when BT mucked something up, I put the HG612 back on for a while, but I soon put the Zyxel back on because the line was slightly better.   Ronski's line appears to perform  better with the Zyxel - his isnt a short line and its historically prone to getting lots of CRCs.

Ive also got 2 lantiq based routers that perform much worse on my line.  Because Ive very recently picked up a x-talk disturber who knocked 5Mbps from my overhead, Ive no doubt that if I put either of those routers on today that Id be able to sync at the full 80/20 - despite me being on an ECI cab.  :/

I think it may just be a case of suck it and see as to which router performs best on your individual line :/

PS.  The first time I was interleaved was by using one of the lantiq based routers.

[les-70]

   @kitz Your right to question my view of the Zyxel. You may recall that when I had it, I observed almost the same error rate with as the Hg612 except in what I guess are odd SHINE events when the Zyxel just went crazy but the HG612 showed just a moderate error burst. I concluded that your line was free from SHINE but mine suffered from it making the Zyxel unsuitable. From mydslwebstats broadstairs looked to suffer from similar error busts to the ones I had with the Zyxel.  He hit ~600ES in just one hour which had just two CRC spikes -- not good!

[kitz]

Thats interesting that you mention SHINE, because at about the same time I picked up the bad disturber, Ive also been seeing periodic bursts of SHINE. 
 
My line holds on through these burst of SHINE & although I do get a lot of CRCs, because it is such a short burst fortunately I dont get too many ErrSecs.   What is amusing is that  its quite clear that my disturber doesnt....  I can tell exactly when his router is switched off or resyncing as my SNRm immediately blips higher as does my max attainable, and both of these figures go back up to exactly what they were before.  Its happened too many times now to be a co-incidence. 

The last one happened yesterday morning.. presumably it will be evident on MDWS 

[les-70]

 I have never had a resync (except with the Xyxel) on my FTTC line due to errors but the CRC bursts are accompanied by up a hundred or ES, so it must be a persistent thing for a minute or so.  The typical timing seems to have moved as it has got darker and I suspect it may be something like big tube fluorescent lights flickering as they take a minute or so to properly start.   None in my house though.

   I can't see anything on your line re SHINE in the last day or so but I have wondered whether everything get picked up properly for CRC on mydslwebstats.  I find that for CRC  it does not always seem to quite match the dslststs doing the uploading.

   

[broadstairs]

I've been watching my errors today and I'm seeing bursts of about 1000 CRCs roughly every 20 to 30 minutes or so with some 45-75 ES per hour for those hours. In between the bursts are some periods of 100-300 CRCs per minute as well. Still zero FECs since I moved to the 80/20 despite seeing some bursts on 40/2!

Stuart

[kitz]

On 80/20 you are pushing the line to its limits, so its no big surprise that errors will differentiate between the 2.  I'd expect to see more errors whilst on the higher speed product.

Not sure if MDWS is showing the correct information as this looks a bit weird, ie I'd expect the blue line to drop suddenly at midnight, not give that slope - see BaldEagles for comparison.   Are you using HG612 stats or DSLstats to upload your linestats? 

As things stand and based on that graph it looks like you are remaining under the DLM amount.  Its does look like you have SHINE type noise.  Interleaving is about as much use as a chocolate teapot when it comes to SHINE because the bursts come to rapid and at a high rate.   Its also entirely possible that the noise bursts are occurring at a frequency not used for 40/2 which is why you only see them happen when on 80/20.  The higher the frequency then the more susceptible it is to noise ingress.

[broadstairs]

I am using DSLStats. They may look a bit odd as I reset them the other day when I restricted the max sync speed.

Not sure what could be causing my interference as there are no business premises anywhere near me, the likely cable route or cab. The only thing I do wonder about is the substation just down the road (about 100 metres).

I'd love to know if one of my neighbours has errors like mine, he is on the same cabinet and I think FTTC, but I doubt he has any stats available and I would not want to suggest he messes with his connection.

Stuart

Just checked my stats and my CRCs have dropped to under 10 per minute since about 17:10 this evening and my ES rate is now around 20 per hour so something changed but I have no idea what!

[kitz]

I am using DSLStats. They may look a bit odd as I reset them the other day when I restricted the max sync speed.

Ive no idea what its recording, but those figures dont look right.  MDWS is supposed to reset the totals at midnight but hasnt..  and look how it graphs to a point.  It shouldnt do that. [img3]

Then look at how its graphing the past 24hrs [img 2].  Its a smooth increase - more like cumulative figures rather than the peaks and troughs it should be - Compare yours to mine and BE's which gets the figures from HG612 stats..   Im beginning to wonder what info DSL stats is recording and sending to MDWS, because something just doesnt look right. 

[NewtronStar]

I am using DSLstats RPI version to upload stats and it looks ok from my perspective, don't think DSLstats is the cause it must be on the EU's side.

[kitz]

Thanks NS for confirming that.

As a test Ive just swapped my logging from HG612 to DSLstats and see what happens for me.. as Im using the same router.

[roseway]

Mine looks quite normal too (using DSLstats):

[les-70]

   That fumy plot occurs when only odd bit of data are uploaded.  I used to get plots like that when i did not upload 24/7.  bitswaps/min is good to show data gaps.  dslststs sseems some times, when a router is swapped or a resync is forced, to need to have the upload option reset and the login info rechecked.

[broadstairs]

Sorry to have confused you all but Newtronstar is correct it was my fault. I am in the process of moving my weather station software from an old W2K and slow AMD processor PC to a spare i5 laptop. As this system runs 24x7 it is where I run DSLStats, as part of the move I stopped the upload and forgot to turn it back on  There might be a few more interrupts over the coming days as I finish the move but no more than a few minutes at a time while I reboot etc.

So now things should look better in a few days time when it has had time to upload more data.

Stuart

[broadstairs]

I have had just one more thought about my interference. My neighbour at the back has a bank of solar panels on his roof facing us and these generate electicity (not water heating). Is there any evidence that these can cause problems?

Stuart