Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: broadstairs on March 29, 2016, 08:10:16 AM
-
I did mention this in the G.INP and ECI thread but it has got worse.
Prior to G.INP being enabled on my line I was interleaved and saw the usual FEC errors downstream but my upstream was pretty quiet and had very very few errors of any sort apart from the odd burst.
Now since I had G.INP enabled downstream only the other morning I have seen huge (and I mean huge) numbers of UPSTREAM FEC errors usually during the peak evening hours, where there were very low levels before. Now this morning I can see that I have had about ~60000/min FECs continuously since about 19:40 yesterday evening. My router is a ZyXEL VMG8924-B10A running f/w version 11 if that has any effect on things!
What I dont understand is why my upstream now seems so noisy when in the past it was quite quiet and the vast majority of errors happened downstream. You can see my stats on MDWS as user broadstair (note no S on the end!).
Stuart
-
At work we used to regularly get 600,000 FEC on the down stream (can't remember what the US used to do), for weeks on end, then it would just disappear. Perhaps its g.inp related or just coincidence for you.
I'm still waiting for g.inp both at home and at work , I'm running a ZyXel at home so we'll see what happens when mine goes live, thought mine might have done by now seeing as we're not too far apart.
-
At work we used to regularly get 600,000 FEC on the down stream (can't remember what the US used to do), for weeks on end, then it would just disappear. Perhaps its g.inp related or just coincidence for you.
I'm still waiting for g.inp both at home and at work , I'm running a ZyXel at home so we'll see what happens when mine goes live, thought mine might have done by now seeing as we're not too far apart.
Yes it will be interesting to see another locally. As I said these errors are upstream which is something which has ONLY started to appear since my G.INP was enabled.
Stuart
-
I decided to take my router down and update it to V13 of the f/w (was V11), left for 30mins and back now. So we'll see if the errors being reported are still there.
Stuart
Edit: My FECs upstream have now dropped to zero so either the ZyXEL needs a reboot when G.INP is enabled or there might be a f/w bug. ANyway I'll see how it goes as the day(s) progress.
-
Well after about 24 hours since the reboot I am still seeing errors upstream during the evening. Now what I dont understand is why G.INP being activated downstream it has caused my upstream to start showing errors which did not happen pre G.INP. It makes no sense. Now I know everyone says FECs dont affect DLM but none the less any errors of this magnitude has to have some kind of performance impact and why on earth should the downstream G.INP affect upstream errors?
Stuart
-
FECs will have no performance impact but just work your modem (and dslam) harder to correct them.
Did none of the FEC related settings on your upstream get changed when g.inp got enabled?
-
FECs will have no performance impact but just work your modem (and dslam) harder to correct them.
Did none of the FEC related settings on your upstream get changed when g.inp got enabled?
Well if the router and dslam have to work harder then that in itself will have a performance impact.
Not sure where to look or what settings to look at.
Stuart
-
only if cpu is saturated which shouldnt be the case as these devices are designed to operate in such modes.
When I say work harder I mean slightly harder not significantly harder.
-
The sending end won't be working any harder, the FEC data is generated in advance of when it is used, so it will be doing the same amount of work regardless of if the FEC data ends up being used at the receiving end or not. The devices at each end will have dedicated hardware for doing things like the FEC process.
-
OK so lets assume no particular performance issues....
So why when pre G.INP my upstream was virtually error free do I now see during the evening peak times hundreds of thousands of FECs over a period of maybe a couple of hours. To me it makes no sense at all to suddenly see all these errors. Something has changed but how do I find out what and why?
Stuart
-
Do your stats have DSLAM/MSAN type: IFTN:0xb204 or IFTN:0xb206 ? There is a mention of "Increased Upstream FEC Count" in the list of fixes in a ECI NGA release notes (http://forum.kitz.co.uk/index.php/topic,15921.msg314605.html#msg314605) document.
-
Do your stats have DSLAM/MSAN type: IFTN:0xb204 or IFTN:0xb206 ? There is a mention of "Increased Upstream FEC Count" in the list of fixes in a ECI NGA release notes (http://forum.kitz.co.uk/index.php/topic,15921.msg314605.html#msg314605) document.
Good spot :)
-
So yes my DSLAM is IFTN 0xb204. So basically there is a bug in the DSLAM f/w which causes increased FECs upstream. My FECs started to increase tonight again at around 21:00 to tens of thousands per minute and has continued about every minute since.
I suspect a fix for this will be as rare as the proverbial rocking horse droppings!
Stuart
-
So yes my DSLAM is IFTN 0xb204. So basically there is a bug in the DSLAM f/w which causes increased FECs upstream. My FECs started to increase tonight again at around 21:00 to tens of thousands per minute and has continued about every minute since.
I suspect a fix for this will be as rare as the proverbial rocking horse droppings!
Stuart
Could it be they need a new G.INP fix Mk3 ::) for ECI
-
Do your stats have DSLAM/MSAN type: IFTN:0xb204 or IFTN:0xb206 ? There is a mention of "Increased Upstream FEC Count" in the list of fixes in a ECI NGA release notes (http://forum.kitz.co.uk/index.php/topic,15921.msg314605.html#msg314605) document.
Good spot :)
Good spot indeed, but it raises an interesting question...
Is that fault one which induces real FEC faults/corrections? Or is it a fault that causes a bad count to be reported?
-
As I said these errors are upstream which is something which has ONLY started to appear since my G.INP was enabled.
Funny enough I noticed that Im getting downstream FEC spikes since g.inp. For some reason they arent showing up too well on MDWS, but they do in DSLstats.
Before 23rd March I cant recall getting spikes and definitely not in the 10's of thousands mark.
Do your stats have DSLAM/MSAN type: IFTN:0xb204 or IFTN:0xb206 ? There is a mention of "Increased Upstream FEC Count" in the list of fixes in a ECI NGA release notes (http://forum.kitz.co.uk/index.php/topic,15921.msg314605.html#msg314605) document.
Good spot - Im also on 204 and not had the 206 update yet. - but since mine are downstream then obviously not related to this particular bug.
[Attached DSLstats graph - for some reason I cant get the clipping level to work at 40k and it defaults back to 10k - but these are at about 38k]
-
Actually I was about to delete the above post - thinking downstream - not related, but in view of wombats post
Is that fault one which induces real FEC faults/corrections? Or is it a fault that causes a bad count to be reported?
I thought it may be beneficial to leave it in place because Im supposedly not interleaved. However - on bearer1 (g.inp) I am - at a depth of 3.
Suggesting my FEC count is coming from the DTU. How it fits in with upstream I dont know though.
-
Interestingly since I installed V13 f/w on my 8924 my FEC bursts seem to last about an hour from 21:00 and the rest of the time I see very low error counts.
Stuart
-
You may find you will see more US errored seconds than normal when G.INP'd with this Mk2, we have seen this to be true on Huawei cabinets over the last year.
G.INP was designed to have both DS and US in retransmit mode at the same time so you can look at it this way G.INP Mk2 is only working at 50% and that is on the Downstream there is another 50% not being used and that's on the Upstream
-
Strange another set of FEC bursts between 21:00 and 22:00 tonight upstream.
Stuart
-
I've just noticed that on our works connection we have bursts of upstream FEC's, we've had 2752570 since G.Inp was applied 3 days and 9 hours and 54 minutes ago. Looking back over the last year there has only been the single odd upstream FEC. This is with a HG612.
My home line has just had G.Inp switched on, so we'll see what happens here.
-
I had a couple of bursts today during the day but sure as eggs is eggs it started again tonight around 21:00!
Stuart
-
I too have seen lots of es on my upstream since g.inp, was in amber zone today for us and still hovering between amber and green...it has recovered a little bit this evening it would appear.
-
Been watching carefully over the past few days and it is really strange that my FEC bursts start pretty much at 21:00 each night for almost exactly one hour, yes I do get the odd burst during the day but it is really strange that you can almost set your watch by these bursts. Nothing much happens here at home at this time to cause noise although I do run some software which uploads small amounts of data about 3-4 times per minute but that runs 24x7. Usually at the time these errors are happening we have settled down for the evening reading or watching TV (traditional TV not Internet TV). At this time of year there is no central heating on normally now and nothing else in use which might cause noise which is not on normally at other times anyway.
Now if there is a bug in the DSLAM f/w I would normally have expected it to happen at random times. So this I think is very strange, however I doubt I will be able to get anyone to take any notice of it unless it becomes and issue in future (which I think is unlikely). I don't like unexplained things like this even if they don't cause a problem (yet)!
Stuart
-
Been watching carefully over the past few days and it is really strange that my FEC bursts start pretty much at 21:00 each night for almost exactly one hour, yes I do get the odd burst during the day but it is really strange that you can almost set your watch by these bursts.
ER - have our lines got mixed up :o Almost identical from 21:00 since G.INP. Never had them before on upstream.
Also my sync has gone UP by 3Mb or so but actual D/L is about 10Mb lower than it should be (Sync is ~39, BT Speedtester and Speedtest report 29 :-X I can't get at my BT IP Profile as it seems to be bust for past 3 days but I suspect it's stuck. Plusnet says 33.4.
So down for an hour tomorrow morning along with MDWS of course to see if it can catch up.
Anyone else join this exclusive club?
-
I see that I have bursts of upstream FECs at the same times, and I'm on a Huawei cabinet. I hadn't noticed that before. How strange.
-
Eric might be worth changing the title of this thread to relate to the bursts of upstream FECs, that way we might find more folks with it.
Stuart
-
Good suggestion Stuart. Done.
-
It would appear I have the same at work, ECI cab with HG612, started as soon as we got G.INP. None on my home connection though.
-
My downstream spikes continue, but now at a lesser level.
They are also at exactly the same time each day.
-
For anyone looking at my stats for tonight (3rd April) we had quite a bad thunderstorm which caused a whole load of errors on my line from about 20:45 this evening for about an hour, so my line went a bit berserk!
Stuart
-
Does ateece on DSLWS look like they have 3db set as target for downstream?
The Downstream dropped to 3db but the Upstream stayed at 6db so it kinda looks like it to me, went from 55mbps to 66mbps so it's looking good!
-
Yep looks like it to me too. The increase in attainable wouldn't have gone up like that if it was still 6db.
Good spot :)
-
I had time today so went hunting :D
-
Roseway too by the looks, nobody else at the moment on DSLWS as far as I can see.
-
hmmm not certain about eric's. :hmm:
There's a strange SNRm spike at around the time of resync. Zooming in closer - at actual time of resync, it looks like for a very short moment at time at 6dB. Eric's could be his line resyncing slightly quicker than a one of his disturbers. His max attainable jumped on the 28th yet the resync was on the 26th.
-
No ECI users have the 3dB profile on MDWS yet :no:
-
No ECI users have the 3dB profile on MDWS yet :no:
Well there isnt as many of them, I've switched over to my HG612 so if I get a resync e-mail I can check asap I got G.INP early so maybe i'll get 3dB early.
-
hmmm not certain about eric's. :hmm:
There's a strange SNRm spike at around the time of resync. Zooming in closer - at actual time of resync, it looks like for a very short moment at time at 6dB. Eric's could be his line resyncing slightly quicker than a one of his disturbers. His max attainable jumped on the 28th yet the resync was on the 26th.
You're right. The resync happened after a power cut, and I was one of the first (maybe the first) users to start up when the power was restored. So I got the temporary benefit of an absence of crosstalk until the other users got going.
-
hmmm not certain about eric's. :hmm:
There's a strange SNRm spike at around the time of resync. Zooming in closer - at actual time of resync, it looks like for a very short moment at time at 6dB. Eric's could be his line resyncing slightly quicker than a one of his disturbers. His max attainable jumped on the 28th yet the resync was on the 26th.
It was the attainable on DS only jumping on the 28th that made me suspect it, note that the 3dB was applied on the 28th on ateece's line, however as Roseway was around 3dB i'm thinking DLM left him alone, also looking at the sNR now and the attainable being reported it may even be a 1dB profile.
-
They will more than likely be testing 3dB on ECI as we speak on the current expanded trial, the trial which was expanded just after G.INP was rolled out on ECI.
From the sounds of it 3dB on G.INP was always BT's intention, and there is absolutely no reason not to roll out 3dB on ECI unless there is a problem.
-
hmmm not certain about eric's. :hmm:
There's a strange SNRm spike at around the time of resync. Zooming in closer - at actual time of resync, it looks like for a very short moment at time at 6dB. Eric's could be his line resyncing slightly quicker than a one of his disturbers. His max attainable jumped on the 28th yet the resync was on the 26th.
It was the attainable on DS only jumping on the 28th that made me suspect it, note that the 3dB was applied on the 28th on ateece's line, however as Roseway was around 3dB i'm thinking DLM left him alone, also looking at the sNR now and the attainable being reported it may even be a 1dB profile.
No, I'm still on a 6 dB target SNRM, and the reason for the strange stats is as I explained in my previous message. Exactly the same has happened before, and when I forced a resync my stats returned to how they were before the power cut.
-
I hope I get a power cut soon :D
3dB looks nice though, I can't wait for it to rollout.
-
I've split a number of messages which veered off-topic into a separate thread: http://forum.kitz.co.uk/index.php/topic,17409.0.html
-
dont know if you guys recall but I have always had loads of upstream FECs on my line and its never caused an issue with DLM.
as for things happening around 9pm mark and carrying on for a bit before trailing off - seems an odd time for any kind of automated system to be triggered. Could be a bug I suppose, but bugs are not well known for being regular as clockwork every 24h (unless human error during setup is in the mix). From working at the other end of the pipes, that time period screams out to me "the time when the most streaming, browsing and porn watching is being done". food for thought.
-
dont know if you guys recall but I have always had loads of upstream FECs on my line and its never caused an issue with DLM.
as for things happening around 9pm mark and carrying on for a bit before trailing off - seems an odd time for any kind of automated system to be triggered. Could be a bug I suppose, but bugs are not well known for being regular as clockwork every 24h (unless human error during setup is in the mix). From working at the other end of the pipes, that time period screams out to me "the time when the most streaming, browsing and porn watching is being done". food for thought.
Well I can assure you that on my connection that is the quietest time of the day ...... ;)
Stuart
-
LOL :P Im sure you aren't doing pron at 9pm :P but dont forget all the other wires that your pair sits with on the way to the cab. Thats their busiest time, im pretty sure :)
-
Well my works connection went up at 21:00 and stayed up around the 78,000 mark all night, still there now.
-
Well my works connection went up at 21:00 and stayed up around the 78,000 mark all night, still there now.
That happened once for me since I went to G.INP. I decided to change to the latest F/W on the 8924 and rebooted (obviously) and since then it has always dropped back just around 22:00. I do still see the occasional burst of upstream FECs at other times but only a quick burst and they are very sparse.
Stuart
-
Well my works connection went up at 21:00 and stayed up around the 78,000 mark all night, still there now.
That happened once for me since I went to G.INP. I decided to change to the latest F/W on the 8924 and rebooted (obviously) and since then it has always dropped back just around 22:00. I do still see the occasional burst of upstream FECs at other times but only a quick burst and they are very sparse.
Stuart
So could still be down to heavy use. Have we considered DSM i or ii ? would be good to know if the upstream power changes during this time period.
-
Well my works connection went up at 21:00 and stayed up around the 78,000 mark all night, still there now.
I was taking a look at the lines with upstream bursts, and noticed this effect (the ongoing FEC count) on Ronski's work line.
I wonder what kind of percentage of all the RS blocks these FEC's coming from? My line seems to run at just over 600,000 RS blocks per minute; however the counter (in "--stats") resets to zero every 6-7 minutes. I just jotted down the RS and RSCorr counters for bearer 0 once a minute, each time DSLstats refreshed the "--stats" tab.
10:28 3,622,705 12,142
10:29 4,239,307 12,142
10:30 579,126 12,142
10:31 1,213,901 12,142
10:32 1,869,843 12,142
10:33 2,483,472 12,142
10:34 3,118,248 12,142
10:35 3,770,519 12,142
10:36 92,841 12,146
Could you take a similar snapshot of those values for your work line, Ronski? Just a few minutes will do.
-
I'll just add that I see the same pattern. The upstream RS count seems to wrap around at a number which looks suspiciously like 2^32 / 1000. The downstream counters wrap around at 2^32.
-
Does ateece on DSLWS look like they have 3db set as target for downstream?
The Downstream dropped to 3db but the Upstream stayed at 6db so it kinda looks like it to me, went from 55mbps to 66mbps so it's looking good!
I went to have a look at these, but the stats now only start on April 1st - the original drop to 3dB is lost, so I can't see anything else at the time of the resync.
However, the current graphs show that the attainable speed is about 8.3Mbps below the actual (of 66Mbps) when the SNRM is 3dB, and attainable is about 10Mbps below the actual when the SNRM is 2.5dB. Those attainable values strongly suggest the target is still around 6dB, and the line just happens to be running at a low speed.
Of course, we can still observe the line's behaviour with an actual SNRM of 3dB, to see what errors it is now incurring. That might give us some idea of how lines with a target of 3dB might behave in the future. Unfortunately, because the old stats are lost, we can't compare the errors seen now with a "before" picture.
So what do I see?
- The SNRM graph currently runs fairly steady at 3dB downstream, with notable troughs to 2.5dB on occasion
- The FEC graph shows low downstream counts when running at 3dB, but notably higher levels when SNRM drops to 2.5dB
- The ES and CRC graphs show little of concern at any time, with no obvious correlation to the times running at 3dB or 2.5dB.
- The G.INP TX and Corr graphs seem to show retransmission is in regular use.
- The G.INP Uncorr graph shows a few irregular peaks. Little to worry about, I think.
- The G.INP LEFTRS and Min-EFTR graphs equally show little of concern at any time.
The difference in the FEC graphs is interesting, when SNRM is either 3dB or 2.5dB. That a change of just 0.5dB can require much more reliance on FEC is telling. It makes we wonder whether BT will really "just" introduce a new margin of 3dB, or whether they will introduce levels of 3, 4 and 5 dB.
I await more evidence with baited breath...
-
I'll just add that I see the same pattern. The upstream RS count seems to wrap around at a number which looks suspiciously like 2^32 / 1000. The downstream counters wrap around at 2^32.
var init fail? :lol:
-
Could you take a similar snapshot of those values for your work line, Ronski? Just a few minutes will do.
I've attached a zipped spreadsheet with a couple of days data, spreadsheet shows the field names - you can import into the spreadsheet if you want.
-
My constant FEC's are still there on the works connection, but I did have a large peak in them around 21:00 last night.
There's no US FEC's on my home connection, but a few DS.
-
My constant FEC's are still there on the works connection, but I did have a large peak in them around 21:00 last night.
There's no US FEC's on my home connection, but a few DS.
I notice that your work u/s FEC counts increase during the 21:00 - 22:00 timeframe above what seems to be your base line. I also took a look at your home connection as well to compare it with mine. Our SNRMs are quite different, yours are around 6db for both where mine is a lot higher for d/s. Also my sync speeds are quite a lot higher than yours. I'm really just clutching at straws to try to see if there might be a reason why your home connection does not see these FECs. I can almost set my watch by the start and end times of the FEC bursts on my line.
Stuart
-
I've been through all the G.INP users on MDWS with ECI cabs and found 11 others with similar issues to mine and a couple of similar ones to Ronski's work where there is a solid level all the time and an additional number during the 21:00 to 22:00 period, I also found 4 users who do not have the problem on an ECI cab. Now I'm not sure if MDWS stores anywhere the cab f/w but I know DSLStats does get that data. Since I can not see any obvious correlation between all these users I was wondering if the users who do not have a problem are on different cab f/w to those who do. If this info is not on MDWS anywhere I'll list the users I've found who DONT have the problem and see what F?W their cab runs (hopefully).
Stuart
-
Could you take a similar snapshot of those values for your work line, Ronski? Just a few minutes will do.
I've attached a zipped spreadsheet with a couple of days data, spreadsheet shows the field names - you can import into the spreadsheet if you want.
I saw the post yesterday with no file, and slightly later, when you added the comment to say you'd removed it. For some reason, I didn't see that you'd added the file back again.
I'll try to look later.
Both of the phenomena that @broadstairs sought in MDWS are very strange. The precision of 9pm - 10pm on a wide array of hardware, widespread across the country, is very strange.
-
Added the wrong file, then the zipped spread sheet was too big :-[
-
The precision of 9pm - 10pm on a wide array of hardware, widespread across the country, is very strange.
Yes indeed.... I suspect it is the ECI cabinets which cause this hence my interest in the exact details obtainable by DSLStats and shown in the output of that program. If those who have the issue shows different cabinet details from those who do not then we might make some headway. Assuming we do see a difference we might then have a problem of getting anyone interested!
My DSLAM/MSAN Type shows as IFTN:0xb204 / v0xb204 this information is on the Stats page of DSLStats.
I'd be interested if any of the following MDWS users could post their information:-
Ronskiwork, Ronski, G3uiss, GaryM, rippong, robbyuk1, simon194, underzone and tbailey2
this is a mixture of those with and without the FEC problem as far as I can see in MDWS.
Stuart
-
Here is mine:
Stats recorded 07 Apr 2016 14:01:19
DSLAM/MSAN type: IFTN:0xb204 / v0xb204
Modem/router firmware: AnnexA version - A2pv6F038j.d24h
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 20 hours 2 min 48 sec
Resyncs: 0 (since 06 Apr 2016 18:01:16)
Downstream Upstream
Line attenuation (dB): 0.0 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 66737 20000
SNR margin (dB): 6.8 9.6
Power (dBm): 13.4 6.3
Interleave depth: 1 1
INP: 49.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): 0.0002 0.0002
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
adsl info --pbParams
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 25695 Kbps, Downstream rate = 69780 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 66737 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (33,857) (1218,1959) (2795,4083)
Medley Phase (Final) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (41,857) (1218,1959) (2795,4083)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 25695 kbps 69780 kbps
Actual Aggregate Tx Power: 6.3 dBm 13.4 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 0.6 20.0 30.3 N/A N/A 11.6 26.2 41.5
Signal Attenuation(dB): 0.4 19.9 30.2 N/A N/A 11.6 26.2 41.5
SNR Margin(dB): 13.1 10.4 9.2 N/A N/A 6.8 6.8 6.8
TX Power(dBm): -7.1 -23.8 6.1 N/A N/A 10.3 7.4 7.5
>
My FEC's seem to have dropped a lot due to trying some different (older) router firmware. More info here: http://www.billion.uk.com/forum/viewtopic.php?f=19&t=8744&p=19229#p19229 (http://www.billion.uk.com/forum/viewtopic.php?f=19&t=8744&p=19229#p19229)
-
Well, I can put paid to it being related to the chipset or version number, unless my use of different modems is affecting it, which I doubt as @Broadstairs is using a Zyxel as I am at home, mines just not the AC version.
Both at home and work it shows my chipset vendor ID as IFTN:0xb204 and the version as 0xb204, so they are both the same, sorry.
-
I'm IFTN:0xb204 / v0xb204 as already posted when it first went live... underzone is the same
-
Well also underzone stats confirms the same CAB as myself and Ronski and Ronskiwork, underzone and ronski both do NOT have the problem so it is not related to the CAB version.
Not sure if we are going to get anywhere with this uness we get very lucky. Annoying as I dont like unexplained things even if they don't actually cause a problem.
Stuart
-
Local pumping station it starts at 9pm ends at 10pm duration 1 hour that's my penny's worth
-
Local pumping station it starts at 9pm ends at 10pm duration 1 hour that's my penny's worth
Well if I were the only person here seeing this I could accept something like that. However because there are other folks on different exchanges in different parts of the country seeing this symptom it cannot be something like this. To my mind there is only one common denominator here and the is the CAB firmware.
Stuart
-
Local pumping station it starts at 9pm ends at 10pm duration 1 hour that's my penny's worth
I don't think it's this either, at work our cesspit is pumped into a neighboring tank, which pumps out automatically only when it gets full. Speaking to the guys that do this and maintain a lot of the waste water systems around here I clearly get the impression that most tanks are pumped on a float trigger system which makes sense. There's no guarantee how full the tank is at any given time, or that it's got enough contents to pump for an hour every night.
-
My home line has now stayed with high FECs since 9pm last night and not dropped, running at 60000+ per minute now more or less continuously.
Stuart
-
I wonder if you'll still get the peak at 21:00, ours at work is a constant 80,000 and peaks for an hour at 2100.
-
I hardly get any FEC's, but regular as clockwork Im still getting the downstream spike at about 10am each day.
Interestingly though a couple of days ago I got an upstream spike - at around 9:30pm
-
I wonder if you'll still get the peak at 21:00, ours at work is a constant 80,000 and peaks for an hour at 2100.
I'll check tonight.......
Stuart
-
It's goneupto between 85000 & 100000 after 9pm tonight. I'll check after 10pm to make sure it drops back again.
Stuart
-
Dropped back to about 63000 or so per minute at 10pm.
Stuart
-
Our works connection peaked as usual at 21:00 then at 22:00 dropped to zero ???
-
That's what normally happens to mine. I'll leave it a few days and see if mine goes back again.
Stuart
-
Ours started on the 5 April, so you may need to leave it more than a few days, although it would be interesting to see if a re-connection cure's it. I wonder if we'll still get the peak tonight.
-
My line has always had large impulse noise events often around the same times each day. The CAB is in a town centre and I have blamed things being switched on and off in shops and restaurants or someone leaning on the CAB making a mobile phone call. My Zyxel VMG1312 seems like previous Zyxel's worst at handling these events, on fast path it gave very large error events of sufficient size to annoy the DLM. Now with G.inp (on eci) I hoped for better and to a degree things are better but now I get the odd very large FEC spikes which don't worry me much but twice a resync with RDI-4 Misdetection has occured. Only some of this is on MDWS. I am giving the Zyxel one last chance today before it is consigned to dust gathering or ebay. When I use an HG612 the FEC spikes are roughly one hundredth of the size.
-
At my works line we're on a industrial estate so will be various sources of noise, and indeed when we were interleaved you could see this increase during working hours, now we're on g.inp we just get this strange peak at 21:00, this is an eci cab with HG612.
At home I'm using a ZyXel with ECI cab and G.Inp, but hardly any fec's.
-
The problem here is that we are seeing large bursts at the same exact hour every night between 21:00 and 22:00 on upstream only and this has ONLY started AFTER G.INP was enabled. Prior to this my upstream was very stable and my cab is in a residential area. Occasionally itseems that we can experience these FECs all the time but still with the same increase at 21:00.
Stuart
-
Our's has returned to the 80,000 level last night, and I see that @Broadstairs has stepped up a level to 120,000 ??? Most strange!
-
Our's has returned to the 80,000 level last night, and I see that @Broadstairs has stepped up a level to 120,000 ??? Most strange!
Yes not dropped back last night at 10pm. I'll give it another couple of days and if it has not recovered I'll reboot the router.
Stuart
-
Has anyone noticed problems with these FEC are they impacting bandwidth at all?
I have the same issue but I haven't noticed it day to day.
IFTN 0xb204 btw
-
They've never affected our works connection that used to around 600,000 per minute for weeks on end.
-
I can't say I've noticed any adverse effect either, however they should not be happening.
Stuart
-
I was not looking at my stats properly. I was using an older 5.4 version of dslstats which seemed not to upload any upstream FEC. I do in fact also get large bursts of upstream FEC and always from about 21:00 to 21:30.
I am surprised so many are possible with an interleaving depth of 1 and without any matching CRC increase. I tried moving from a speed capped HG612 to an uncapped Zyxel VMG1312. See below the two days one with each. The Zyxel get a lot more FEC some no doubt due to being uncapped in speed and perhaps some due to the different chipset.
The change in response may suggest the errors are in some way real. As you say "I can't say I've noticed any adverse effect either, however they should not be happening."
Given that I assume that we are geographically separate it is very very odd.
-
I was not looking at my stats properly. I was using an older 5.4 version of dslstats which seemed not to upload any upstream FEC. I do in fact also get large bursts of upstream FEC and always from about 21:00 to 21:30.
I am surprised so many are possible with an interleaving depth of 1 and without any matching CRC increase. I tried moving from a speed capped HG612 to an uncapped Zyxel VMG1312. See below the two days one with each. The Zyxel get a lot more FEC some no doubt due to being uncapped in speed and perhaps some due to the different chipset.
The change in response may suggest the errors are in some way real. As you say "I can't say I've noticed any adverse effect either, however they should not be happening."
Given that I assume that we are geographically separate is is very very odd.
I think this shows that while there is an increase using a ZyXEL the fact that some errors were still there using an HG612 shows that the problem is unlikely to be related to the modem.
I think the georgraphic assumption is likely to be correct as my screen name is indeed where I live ;)
William it is unlikely you will see tis issue as you are on a Huawei cab and so far this is only seen on ECI cabs with G.INP active.
Stuart
-
My upstream FEC bursts seem to have been removed by Openreach removing G.inp from my ECI DSLAM line. Does anyone else have the same experience? if so I wonder if this issue is in any way related to the G.INP/ECI mess.