Kitz Forum
Broadband Related => Broadband Technology => Topic started by: Bald_Eagle1 on November 01, 2011, 09:00:37 AM
-
Hi All,
I have recently been keeping an eye on the error count for my FTTC connection.
e.g. My connection has been up for 1 day, 2 hours, 45 minutes.
This is the error count:-
Path 0 Path 1
Downstream Upstream Downstream Upstream
Line rate (kbit/s) 25613 4699 0 0
CRC errors 1238192 0 0 0
FEC errors 13746 73 0 0
HEC errors 370523 0 0 0
From a re-sync / reboot, where SNRM is around 6dB during daylight hours, I see very few errors being reported.
However, from around 4:00pm onward, SNRM starts to drop & the error count starts to rise.
From around 8:00 am, the SNRM starts to rise again, & the increase in error count slows down again.
My questions are:-
1) Does the above error count look "normal" for the duration of my connection?
2) If the error count is indeed high, what sort of things could cause it?
3) I don't notice any deterioration in my internet usage, other than what I consider to be too low a speed for FTTC generally, as extensively documented in my other thread.
Is the error count shown above anything to be concerned about?
4) Could a high error count be a contributory factor in my current inability to sync at a higher speed?
I have only really noticed these errors since the switch to the new FTTC 17a profile, with my connection attempting to use higher frequencies on an already highly attenuated connection, but they MAY have been similar before the profile switch.
I don't currently have any way of monitoring/recording timed SNRM/error count fluctuations (Routerstats etc.), but that is being looked into.
Paul.
-
that type of sinusoidal behaviour with rising/falling snrm and error rates is pretty normal. They may be a bit on the high side for the uptime, but any form of bad weather, local interference, etc. could bump it up lots in a given time period. Without monitoring over a longer time period it's impossible to tell if it's a one-off "event" or a longer-term trend.
-
Hi
~ 12 CRCs a second a little surprised as most of the errors are being generated over a very short distance (only from cabinet). An average of 12 per second is one thing but importantly how much of an increase is there during peak periods .
The CRC will not affect your synch directly ,if they are too bad then your SNR margin will go up . With normal ADSL there is a limit of 15db. With VDSL I am not sure but I seem to have read it is similar.If you stay connected at a given synch rate with High CRCs then of course this will have an adverse affect on your throughput .
On my adsl line with an uptime of nearly 6 days I have a total of 1crc ,2.2 Km from the exchange .
Regards Jeff
-
Hi
~ 12 CRCs a second a little surprised as most of the errors are being generated over a very short distance (only from cabinet). An average of 12 per second is one thing but importantly how much of an increase is there during peak periods .
The CRC will not affect your synch directly ,if they are too bad then your SNR margin will go up . With normal ADSL there is a limit of 15db. With VDSL I am not sure but I seem to have read it is similar.If you stay connected at a given synch rate with High CRCs then of course this will have an adverse affect on your throughput .
On my adsl line with an uptime of nearly 6 days I have a total of 1crc ,2.2 Km from the exchange .
Regards Jeff
Thanks Fellas,
As reported elsewhere, I believe my connection is currently highly attenuated, compared to what it must have been when I achieved much higher speeds, & also compared to other users' stats for their good connections.
No matter how much I ask, I can't get BT, via Plusnet, to confirm whether it has been intentionally manually speed capped to provide stability or not.
I just get the response that DLM does all that automagically.
Assuming DLM is actually operating correctly based on the current condition of my D-side, it would appear that some sort of physical resistance or other "fault" is causing the high attenuation.
I would assume that other factors such as electrical "interference" could cause increased noise levels, but would not affect attenuation?
Nobody has been willing/able to confirm my D-side's actual length, so I have no idea what my attenuation levels SHOULD be, assuming a "typical" D-side condition.
I THINK my D-side could be anywhere between 600m & 850m.
So, could the resistance "fault" be the cause of the high error count, especially when reported SNRM levels drop at peak/night time periods?
My connection now appears quite stable otherwise, albeit at reduced speeds, & doesn't appear to lose any throughput speed (even at peak periods), which leads me to think there cannot be too many FTTC connections from my cabinet.
My reported SNRM level was 3.9dB at around 6:30 this morning & now at 08:25 it is 5dB
Now connected for 2 days, 2 hours, 42 minutes, the error count is:-
DS US
CRC errors 3369943 0
FEC errors 34398 130
HEC errors 996619 0
As soon as I can monitor error counts & SNRM overnight (with something quite similar to Routerstats), I will have a better indication of when things worsen.
I also hope to be able to test/measure my D-side length "unofficially" in the not too distant future.
Of course, all of this could be a complete waste of time, as even if I "prove" there is a fault on my D-side, my connection is still performing at "acceptable" levels for an "up to" 40Mb service (according to Plusnet), so convincing them/BT to do anything about it will be another uphill struggle.
Just a final thought (anyone?), I am not aware that the master socket (replaced & repositioned by the FTTC installing engineer) has been tested.
Could a filtering or other "fault" there cause such issues, & how could I test it?
The phone is always nice & quiet now when I do the quiet line test.
Paul.
-
Your CRC error count looks alarming at first sight. It looks like it's of the order of 1 million a day, which is about 10 a second. With that error rate on a conventional DSL connection, over TCP, you'd be soliciting data end-to-end retransmissions ten times a second, each one causing a delay of perhaps a few hundred milliseconds, the overall throughout would be near zero and completely useless.
So, assuming your line provides a useable service, it seems fair to assume the CRC counter does not have the same significance to which we are accustomed with old-style ADSL.
I'm not sure what technologies BT deploy for FTTC ... VDSL? VDSL2? I know that some of the VDSL technologies support PhyR (Physical layer retransmission), whereby corrupted data only has to be retransmitted from the remote end of the phone line, compared to TCP retransmissions which may have to be resent from across the world. I'm therefor guessing your CRC errors may perhaps relate to PhyR requests rather than failed IP checksums, which makes them a lot less alarming. It still seems a lot to me but I've no idea is to what is 'normal', or 'tolerable' for PhyR retransmissions. If your connection is working OK, with decent throughput and no 'pauses' then there may be no need to worry too much.
-
So, assuming your line provides a useable service, it seems fair to assume the CRC counter does not have the same significance to which we are accustomed with old-style ADSL.
I'm not sure what technologies BT deploy for FTTC ... VDSL? VDSL2? I know that some of the VDSL technologies support PhyR (Physical layer retransmission), whereby corrupted data only has to be retransmitted from the remote end of the phone line, compared to TCP retransmissions which may have to be resent from across the world. I'm therefor guessing your CRC errors may perhaps relate to PhyR requests rather than failed IP checksums, which makes them a lot less alarming. It still seems a lot to me but I've no idea is to what is 'normal', or 'tolerable' for PhyR retransmissions. If your connection is working OK, with decent throughput and no 'pauses' then there may be no need to worry too much.
Hi sevenlayermuddle,
BT uses VDSL2, originally profile 8c, gradually being switched to the higher frequency profile 17a, in readiness for next year's speed "doubling" to 80Mb.
I was switched to profile 17a quite recently, & the high error count may have started then. I didn't really notice a high count when I was on profile 8c.
It does work O.K., apart from the much lower speeds than I achieved what now seems such a long, long time ago.
I'll go & have a read up on PhyR requests as I haven't heard that term previously.
Paul.
-
I'll go & have a read up on PhyR requests.
Me too, I've got me interested :D
But I'm actually just about to be away on travels for a few days, so don't expect much more dialogue from me in the next few days. I'll add read up on VDSL & PhyR to the wishlist of things to do when I get back.
-
I also hope to be able to test/measure my D-side length "unofficially" in the not too distant future.
<snip>
Just a final thought (anyone?), I am not aware that the master socket (replaced & repositioned by the FTTC installing engineer) has been tested.
Could a filtering or other "fault" there cause such issues, & how could I test it?
The phone is always nice & quiet now when I do the quiet line test.
Hi Baldy_Bird,
(I think I can get away with that greeting as "The Cattery" is a number of counties away from Lancashire and, thus, my tail is out of pecking range . . . :P )
Your hope, quoted above, is interesting and on behalf of all of us who inhabit these fora, please let us know your findings and the method you used -- in due course.
With regards to your final thought, although I believe I have a good "overview" of your connection, I am still a little unclear on the intimate most details. For example, by inputting some data into Google Maps (and not getting distracted by some magnificent views of the countryside), a "street view" shows me a pair of semi-detached houses. I assume "The Aeire" is the right-hand one of the pair when viewed from the road. Unfortunately GM street view does not show me a clear image of where the drop-wire from the pole is attached to your house. I would be very interested to see clear photographs starting from that point and including the junction where the drop-wire transitions to the service cable, where the service cable is extended (the old location of the NTE5/A) to your office, the new location of the NTE5/A in your office and any extensions that may be run from there. I'm sure you know the sort of details that I like to see in photographs -- the colours of the wire cores that emanate from each cable and which coloured wire is connected to what-not, etc. As for "testing" of your relocated NTE5/A, the best method is a direct swap for a known, good device. Let me contemplate my last statement some more, once I have seen your photographs . . . :-\
-
Hi Baldy_Bird,
(I think I can get away with that greeting as "The Cattery" is a number of counties away from Lancashire and, thus, my tail is out of pecking range . . . :P )
Your hope, quoted above, is interesting and on behalf of all of us who inhabit these fora, please let us know your findings and the method you used -- in due course.
With regards to your final thought, although I believe I have a good "overview" of your connection, I am still a little unclear on the intimate most details. For example, by inputting some data into Google Maps (and not getting distracted by some magnificent views of the countryside), a "street view" shows me a pair of semi-detached houses. I assume "The Aeire" is the right-hand one of the pair when viewed from the road. Unfortunately GM street view does not show me a clear image of where the drop-wire from the pole is attached to your house. I would be very interested to see clear photographs starting from that point and including the junction where the drop-wire transitions to the service cable, where the service cable is extended (the old location of the NTE5/A) to your office, the new location of the NTE5/A in your office and any extensions that may be run from there. I'm sure you know the sort of details that I like to see in photographs -- the colours of the wire cores that emanate from each cable and which coloured wire is connected to what-not, etc. As for "testing" of your relocated NTE5/A, the best method is a direct swap for a known, good device. Let me contemplate my last statement some more, once I have seen your photographs . . . :-\
Hi b*cat,
In the same order as your catawaling, I respond as follows:-
Bald Eagles are rather large birds of prey & can fly a long way, getting hungrier & hungrier on their journey, a large black cat would simply suffice as an aperatif.
"The Aerie" is actually the left-hand one of the pair. The lead flashing to the porch is no longer an issue as some poor soul helped themself to it quite a while ago.
The drop wire can be seen by zooming in to the right-hand side of the furthermost left-hand upstairs window.
It enters at just above window cill level.
Dependent upon zoom level, the cable can be seen going off to the pole to the right of the semi, then across the road to another pole.
From there, it either goes underground down the road, past the front of the Filling Station toward the cabinet, or takes a detour up the path, overhead to near the row of houses, & then behind the Filling Station.
Whichever route it takes, it appears to go to the pole just past the white(ish) property that is being advertised "To Let" by someone who could be my father's brother's son.
Are you still with me on this?
From there, the engineer that allowed me to photograph his laptop display, (recall the map with the almost invisible dotted line, that turned out NOT to be a BT Network Record after all), thought it MUST continue down the same main road (H Road) to the Lane on which the cabinet is located (H Lane).
This would be the longer of 2 possible routes (820m apparently).
The FTTC installing engineer thought it MAY go down L T Lane (opposite the aforementioned white(ish) property), to the cabinet on H Lane (the shorter route).
Prior to the FTTC installation, the master socket (ADSL v1.0) was on the internal reveal of the upstairs window, with various hard-wired & plug in telephone extension cables bought from B & Q.
I had plugged into the DSL socket a 20m high quality, shielded, high speed data cable, bought from Maplins.
This went along the upstairs, through the house, & through the ceiling to the downstairs office (difficult to photograph).
The installing engineer cut off the male plug of my shielded cable at the old master socket & crimped a pair from the shielded cable to the incoming cable.
He then cut off the male plug at the other end of the shielded cable (downstairs) & hard-wired it into the new master socket downstairs.
He then connected a spare pair from the shielded cable into the new master socket which then ran back upstairs to what WAS the old master socket, converting the old master socket to a telephone only extension, with further extensions hard-wired & plugged in.
That may appear somewhat unconventional, but it worked perfectly.
On seeing the cabling, each visiting engineer has scratched his head & thought about it, (some have even disconnected the crimps & checked for moisture etc), thought about it some more & then commented with words such as "Well, that's not how I would have done it, but it is much better quality cable than we (BT) would have given you".
I had a fax machine, various telephones, sky box, connected via the various extensions from day 1.
Everything worked perfectly for the first month. I even disconnected everything apart from the broadband for a full week to check for "interference".
That produced no changes - still perfect, & at at the same broadband speeds.
Are you still with me?
I have telephone extensions all over the place; under floors, inside studded partitions, extensions plugged into extensions, double adapters etc. etc. etc.
All have been checked by engineers as O.K.
During the "troubles", I again disconnected the whole lot for a full week. This made absolutely no difference whatsoever.
Various photos are attached, but I could forward full resolution photos if required.
Images 004, 005, 006 show the new master socket.
Also see the next post for more photos.
Well, you did ask.............
Paul.
[attachment deleted by admin]
-
The other photos.....
(after losing a couple of Mb through disconnecting at a silly time of day) ;D
I hope the previous message was clear enough.
I lost myself a couple of times while composing it.
I had better read through it again to check ;)
Images 007,008,002 show the old master socket (now an extension)
Paul.
[attachment deleted by admin]
-
Your CRC error count looks alarming at first sight. It looks like it's of the order of 1 million a day, which is about 10 a second. With that error rate on a conventional DSL connection, over TCP, you'd be soliciting data end-to-end retransmissions ten times a second, each one causing a delay of perhaps a few hundred milliseconds, the overall throughout would be near zero and completely useless.
So, assuming your line provides a useable service, it seems fair to assume the CRC counter does not have the same significance to which we are accustomed with old-style ADSL.
I'm not sure what technologies BT deploy for FTTC ... VDSL? VDSL2? I know that some of the VDSL technologies support PhyR (Physical layer retransmission), whereby corrupted data only has to be retransmitted from the remote end of the phone line, compared to TCP retransmissions which may have to be resent from across the world. I'm therefor guessing your CRC errors may perhaps relate to PhyR requests rather than failed IP checksums, which makes them a lot less alarming. It still seems a lot to me but I've no idea is to what is 'normal', or 'tolerable' for PhyR retransmissions. If your connection is working OK, with decent throughput and no 'pauses' then there may be no need to worry too much.
Does anyone else find the high count of CRCs when compared to FEC's unusual?
Youd normally expect the FEC's to outnumber CRCs?
-
Does anyone else find the high count of CRCs when compared to FEC's unusual?
Youd normally expect the FEC's to outnumber CRCs?
Apologies, this response replaces another one that I just deleted it as I think I'm maybe confused.
My comments about CRC errors crippling the connection really refer to IP checksum errors.
Can we clarify the expected relationships, though...?
If CRC errors relate to ATM cells then surely they shuld outnumber FECs, yet they usually don't.
If they are IP header errors then surely HECs should outnumber CRCs, but I think they often don't.
I'm sure I once kew the answers to questions like that. :-[
My gut feeling remains that the high CRC count is in some way related to PhyR, but I'm further than I thought from adding any substance to the theory. ???
Anyway, I'm meant to be 'home' on holiday, must learn to shut up. :D
-
Hailing the Big Bird with not too many feathers "up top",
Are you still with me on this?
Yes. Your father's brother's son is your cousin! ::)
I've now studied your internal wiring photographs, thank you. I am surprised that the installing engineer left the original NTE5/A in situ, rather than swapping it out for an LJU3/3A or even an LJU5/3A -- both of which would have fitted the existing backing box of the old NTE5/A. (See the BT Phone Sockets (http://www.kitz.co.uk/adsl/btsockets.htm) page for details.) Perhaps he didn't have either of those sockets in his van? Do you know if he removed the surge suppressor, resistor and capacitor from the old NTE5/A? If he didn't, then the incoming pair is now doubly terminated. :-X I assume the new NTE5/A is situated in that location as being ideal for the HG612 and your Netgear router? That "wiring closet" is in your office, I assume. My other surprise is that the installing engineer did not fix the new NTE5/A backing box to a suitable surface but "left it floating". :-\ I'll echo what subsequent visiting engineers have said: "That's not how I would have done it."
Looking back to your post where you commented and asked --
Just a final thought (anyone?), I am not aware that the master socket (replaced & repositioned by the FTTC installing engineer) has been tested.
Could a filtering or other "fault" there cause such issues, & how could I test it?
-- we see that statement isn't strictly correct. The original NTE5/A has been left in situ and a new NTE5/A has been fitted downstairs in your office's "wiring closet". So you can test to see if the original NTE5/A is having any influence by removing the lower front half face-plate from the SSFP which is fitted to the new NTE5/A. By doing that, you will have disconnected all telephony sockets. (Almost a veritable rats nest, I shall say. :tongue: )
As I feel the need for a quick nap overwhelming me, I'll study the external aspect of "The Aeire" and the possible routes to the PCP + Fibre Cabinet tomorrow.
-
. . . as I think I'm maybe confused.
7LM is confused? With such a forum identity, I am very surprised! ;)
Now I'm going to throw a comment up into the air and see how it lands. Unlike the ADSL[2+] service with which we are all familiar, the VDSL2 service between the FTTC DSLAM and the active CPE (the HG612 modem) uses PPPoE, not PPPoA. Hence ATM cells are not part of the picture . . .
(I hope I've got that right.)
-
Hi b*cat,
Looking back to your post where you commented and asked --
Just a final thought (anyone?), I am not aware that the master socket (replaced & repositioned by the FTTC installing engineer) has been tested.
Could a filtering or other "fault" there cause such issues, & how could I test it?
-- we see that statement isn't strictly correct. The original NTE5/A has been left in situ and a new NTE5/A has been fitted downstairs in your office's "wiring closet". So you can test to see if the original NTE5/A is having any influence by removing the lower front half face-plate from the SSFP which is fitted to the new NTE5/A. By doing that, you will have disconnected all telephony sockets. (Almost a veritable rats nest, I shall say. :tongue: )
Just to clarify, that's what I meant I had done when I said I disconnected everything for a week during the "troubles".
TBH, I haven't tried it again since my line appears to have become stable, but I will do so.
The installation engineer was going to fix the new NTE5/A backing box to the wall, or the side of the built-in cupboard in my office, but I asked him not to do so.
He wasn't really happy about leaving it floating, but I convinced him that I would be removing the cupboard & repositioning everything on the wall (including the new NTE5/A) as part of my refurbishment works & that I would take all responsibility for anything that might happen due to leaving a floating socket.
I don't know if he removed the surge suppressor, resistor and capacitor from the old NTE5/A, but I could check later on.
Regardless of whether other engineers would have done it differently or not, it all worked perfectly for the 1st month, & none of the engineers have suggested it needs altering.
Paul.
-
. . . as I think I'm maybe confused.
7LM is confused? With such a forum identity, I am very surprised! ;)
Now I'm going to throw a comment up into the air and see how it lands. Unlike the ADSL[2+] service with which we are all familiar, the VDSL2 service between the FTTC DSLAM and the active CPE (the HG612 modem) uses PPPoE, not PPPoA. Hence ATM cells are not part of the picture . . .
(I hope I've got that right.)
Ah so I was right.... I am confused
At risk of emphaising that confusion further.... I though HEC errors referred to ATM headers, and Mr Eagle is getting HEC errors reported?
With that I shall hush. I have downloaded a copy of g.993.2 from www.itu.org and will attempt to get my head around it, but that could take some time with my limited attention span these days. In fact, it could keep me quiet for quite some weeks.
-
Actually 7LM.. I highlighted your post and italliced the PhyR, because I thought that you may have been on to something.
When I looked at the error count.. the thing that immediately stood out to me about the CRC's was that they vastly outnumber the FECs, which is something that Ive never seen before.
----
*Added to clarify the obvious..... on an interleaved line
-
Hi Mr. B*Eagle1,
(A certain scaredy cat dosen't like the look of that beak . . . :-X )
I'm not seeing any fault with your internal wiring from the OR installed gel-crimps, inwards, so when I agreed with what other visiting engineers had said, it was just that -- an echo.
However, after going to sleep with it present in my mind, I do now have one question to ask about your two pair, screened cable from the gel-crimps to the current NTE5/A. Is the metallic screening actually connected to a good earth? If not, you might have well just used CW1308 spec. cable . . . ::) To provide any benefit, you should earth the screening but only at one end. You don't want to set up any earth loops -- not a good idea. :no:
-
Hi b*cat,
However, after going to sleep with it present in my mind, I do now have one question to ask about your two pair, screened cable from the gel-crimps to the current NTE5/A. Is the metallic screening actually connected to a good earth? If not, you might have well just used CW1308 spec. cable . . . ::) To provide any benefit, you should earth the screening but only at one end. You don't want to set up any earth loops -- not a good idea. :no:
No, the screening isn't earthed.
I think it could be this cable http://www.maplin.co.uk/ultra-high-speed-adsl-cables-45164?ordercode=A97CG (http://www.maplin.co.uk/ultra-high-speed-adsl-cables-45164?ordercode=A97CG) or something very similar.
I just happened to be in Maplins, looking for something else, & noticed it on offer (nowhere near the price in the link - it might have been 1/2 price or less).
I got thinking about my cabling at the time (cheapo white stuff, probably 20 years old or more, in a number of short lengths jointed by twisting the wires together & wrapping selotape around the joint before stuffing it under the carpet.
So I bought it, thinking it might be better.
It appeared to make no difference to my (at that time) 1Mb connection whatsoever.
The modem log reported a re-sync at around 5:45 this morning, so I unplugged everything apart from the broadband & rebooted the modem.
This resulted in a slightly higher speed (Line rate (kbit/s) 26497 DS & 4670 US, SNRM 6.1dB).
The connection has been up for more or less 14 hours now.
SNRM has now dropped to 3.8dB
Error count is currently:-
DS US
CRC errors 119034 0
FEC errors 1216 24
HEC errors 35356 0
I'll plug everything back in tomorrow morning & see if the error count shoots up again.
Speedtest.net doesn't appear to be working tonight, so:-
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.mybroadbandspeed.co.uk%2Fresults%2F125637171.png&hash=b9708dc530a8ca4f965543ec3d28ecbc7f23ce35) (http://www.mybroadbandspeed.co.uk)
Paul.
-
No, the screening isn't earthed.
Well, it should be! >:(
When the original RJ11 plugs were attached to each end, I wonder what was done with the screening? I am beginning to suspect that it was nothing more than a marketing ploy to induce the gullible to part with more money -- "Never mind the quality, it is screened cable. (Just don't tell them that the screening is only for show.)"
I'm sure one of the other Wizards will be able to advise you on the sort of connector required to connect a earthing lead to the screening. ;)
As for analysis of your modem's data, I'll leave that to Kitz, 7LM, Oranged, Jeff or . . .
Yawn. Excuse me, a cat-nap is coming on.
-
I'll plug everything back in tomorrow morning & see if the error count shoots up again.
Speedtest.net doesn't appear to be working tonight, so:-
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.mybroadbandspeed.co.uk%2Fresults%2F125637171.png&hash=b9708dc530a8ca4f965543ec3d28ecbc7f23ce35) (http://www.mybroadbandspeed.co.uk)
Just for the record at 06:20 this morning, DS SNRM was 4.1dB
The modem has not re-synced overnight.
Throughput appears to be the same as yesterday:-
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F1572551869.png&hash=7f73442895ae642ffbf4a2548d855205a538c236) (http://www.speedtest.net)
Downstream Upstream
Line rate (kbit/s) 26497 4670
CRC errors 121443 0
FEC errors 1270 48
HEC errors 35921 0
Everything plugged back in at 06:40 (modem NOT rebooted).
I will monitor for errors etc. for 24 hours (assuming no re-sync events).
Paul.
-
No, the screening isn't earthed.
Well, it should be! >:(
When the original RJ11 plugs were attached to each end, I wonder what was done with the screening? I am beginning to suspect that it was nothing more than a marketing ploy to induce the gullible to part with more money -- "Never mind the quality, it is screened cable. (Just don't tell them that the screening is only for show.)"
I'm sure one of the other Wizards will be able to advise you on the sort of connector required to connect a earthing lead to the screening. ;)
Hi b*cat,
I see there was a discussion on this some time ago:-
http://forum.kitz.co.uk/index.php/topic,5028.0.html
If nothing else, I got rid of the cheap cable with selotaped joints, & the braided shielding will no doubt provide some protection against physical damage.
Paul.
-
I will monitor for errors etc. for 24 hours (assuming no re-sync events).
Hmmm,
Kiboshed in just 1 hour.
I noticed this in the modem's log:-
2011-11-4 7:32:36 Notice 104500 DSL activate succeed
2011-11-4 7:32:20 Notice 104500 DSL deactivate
As this re-sync event "on the fly" only took 16 seconds, it will not be recorded in Plusnet's logs.
I note the dynamically obtained IP address is unchanged.
I wonder if DLM finally gave up on the SNRM level of 4.1 dB, & decided I would be much better off with a lower speed & higher SNRM.
SNRM is now back up to 6.3 dB, but I have lost quite a bit on sync/download speeds.
Line Rate (sync speed) is now down from 26497 K to 23780 K
& download speeds down from 24.83 Mb:-
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F1572659668.png&hash=7b22d4064cf0f0e87aaf4f0a7254f1cf26dc47cd) (http://www.speedtest.net)
Ping has improved from 25 ms though.
The recent change of profile from 8c to 17a MAY have started the 10 day training period all over again (Plusnet don't know whether it has or not), so I won't keep rebooting the modem, just to eek a couple of Mb more out of my connection.
Apparently sync speeds CAN go up & down during the training period, although I do note that they never went down during the training period following the initial installation.
This re-sync MAY have been caused by "something" in my other internal wiring as I maintained a higher sync rate & associated higher download speeds for 24 hours or so with it all unplugged.
It looks like I will now have to monitor this over quite a prolonged period, plugging my other kit back in one piece at a time until I find a culprit (if there is one).
Now if only someone could develop RouterStats (or something similar) to automatically monitor my VDSL2 connection at regular intervals............
Paul.
-
Mr Eagle,
I see there was a discussion on this some time ago:-
http://forum.kitz.co.uk/index.php/topic,5028.0.html
Hmm, useful comments from both Eric and Walter. (And tips, from the latter, on how to electrocute a cow! Oops, mustn't laugh. :lol: )
If nothing else, I got rid of the cheap cable with selotaped joints, & the braided shielding will no doubt provide some protection against physical damage.
Indeedy. But b*cat would still prefer to know that the braiding is connected to a good earth.
Now if only someone could develop RouterStats (or something similar) to automatically monitor my VDSL2 connection at regular intervals............
That needs further thought because when one goes to the relevant page via the GUI, there is no corresponding URL displayed from which one could "curl" the data.
-
No, the screening isn't earthed.
Well, it should be! >:(
Without wanting to fall out with anyboidy else I agree, it should be. Although I'm aware that not every body is as convinced as B'Cat and I are.
The thing is, an ungrounded faraday cage can be effective providing the entire system is completely enclosed within the cage, but that's not the case for DSL. My theory at least. :)
That said, some of the 'super-cables' , regardless of their superfluous shielding, may offer other benefits such as increased twist-per inch, which would be quite relevant at higher speeds.
-
Hi b*cat,
That needs further thought because when one goes to the relevant page via the GUI, there is no corresponding URL displayed from which one could "curl" the data.
Just a thought, if one carefully hovers over the xDSL button inbetween screen refreshes, does that not reveal the elusive URL in the browser's status bar?
(http://192.168.1.1/html/status/xdslStatus.gz.html)
Paul.
-
if one carefully hovers over the xDSL button inbetween screen refreshes, does that not reveal the elusive URL in the browser's status bar?
S'pose that comes from having Eagle eyes! I've noted down that information on my (ever lengthening) "ToDo" list. ;)
-
Quite often, when a browser web interface doesn't display a unique URL for the stats page, this is because the stats are displayed via javascript on the main page. To get the details into Routerstats, see here. (http://www.vwlowen.co.uk/internet/routerstatshelp/routerstatshelp.htm) Click on 'Configuration section'.
-
Mr Eagle,
I have some not good news for you. After attempting to "curl" the relevant information from the HG612's page, I discovered that the device does indeed use javascript to display the information . . . just as Eric has mentioned. So a very simple "bash" script will not be able to obtain the SNRM at regular intervals, suitable for plotting versus time. :(
-
Thanks b*cat,
I have discovered that this page does appear to provide SNRM, sync & other information:-
http://192.168.1.1/html/status/xdslStatus.asp
var DSLCfg = new Array(new stDsl("InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig","Up","VDSL2","","4999","24153","0","0","5297","26756","66","44","0","0","63","109","G.992.3_Annex_K_PTM"),null);
var DSLStats = new Array(new stStats("InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.Stats.Showtime","232585","0","797750","0","7537","32","0","0","0","0","0","0"),null);
var DslUpTime = "53903";
var time = 1;
I thought I had cracked it to be able to use Routerstats.
But, in Routerstats it appears to wrap the details differently when it refreshes, thus giving spurious results for SNRM.
(Possibly something to do with the newline character - or lack of?)
Maybe it could be controlled a bit better in a bash script?
Paul.
EDIT:
It was interesting to note that I appear to be able to obtain the stats WITHOUT the need to log in to the modem itself, or the need to enable Telnet etc.
I wonder if a similar method could be used for automating the obtaining all the other stats that are used for the bit loading graphs etc.
-
Thanks b*cat,
I have discovered that this page does appear to provide SNRM, sync & other information:-
http://192.168.1.1/html/status/xdslStatus.asp
Maybe it could be controlled a bit better in a bash script?
Paul.
EDIT:
It was interesting to note that I appear to be able to obtain the stats WITHOUT the need to log in to the modem itself, or the need to enable Telnet etc.
I wonder if a similar method could be used for automating the obtaining all the other stats that are used for the bit loading graphs etc.
Just a quick update Folks:-
I couldn't get RouterStats to work correctly in the end.
So, with a lot of help from others who shall remain nameless (unless they wish me to name them) I have developed a batch file to gather the stats from http://192.168.1.1/html/status/xdslStatus.asp, & use a Linux script for now to graph them.
For your delight, entertainment & comment, I have attached the graphs.
I only have a few hours worth recorded for now as I only got it working in the early hours of this morning.
I believe the BT modem HAS to be unlocked to obtain this detail.
Paul.
[attachment deleted by admin]
-
Hmm, someone has definitely made significant progress. :)
The graph formats look vaguely familiar . . . I'm sure I've seen similar, elsewhere. ;)
Putting that aside, I am concerned with the sudden drops in the SNRM this morning. Do they correlate with any electrical activity from within your domain ("The Aerie")? :-\
-
Putting that aside, I am concerned with the sudden drops in the SNRM this morning. Do they correlate with any electrical activity from within your domain ("The Aerie")? :-\
Hi b*cat,
They do indeed DIRECTLY relate to land line phone calls that Mrs. Eagle made (dialing out, not answering).
It appears that whenever any handset is picked up, SNRM drops significantly & rises again as soon as the handset is replaced.
I have today tried adding brand new, previously unused filters that came with previous ADSL modems.
The additional filtering had no effect whatsover in resolving the dropping SNRM levels.
These events have not all been captured in the modem log/graphs as data is currently only captured every 2 minutes.
I might increase that to capture data every minute.
I currently just have 3 telephones connected:-
1 is plugged directly into the "new" SSFP AT the "new" NTE/5 Master socket (downstairs).
1 is plugged in upstairs via a double adaptor at what is now an extension socket (was the master socket prior to FTTC being installed).
This extension is hard wired from the "new" master socket along a spare pair in the braided cable mentioned previously (connected by the FTTC installing engineer).
1 is plugged in downstairs at the end of another extension, from the upstairs double adapter.
I have disconnected the Sky box & FAX machine, so the total REN is now 3, but SNRM still drops immediately a handset is lifted.
During the previous documented troubles I checked all this as a potential cause.
I never noticed SNRM dropping during phone calls.
I have only noticed this phenomenon very recently.
It may have coincided with the profile switch to 17a, but I can't be 100% sure.
CRC errors are currently almost 2 Million, following 1 day 12 hours broadband connection time.
My throughput speeds do NOT seem to be affected during phone calls & the FTTC connection is maintained despite dropping SNRM levels.
I wonder if the filtering in the SSFP is "faulty" (could lightning have damaged it?), or simply not suitable for the higher frequency 17a profile.
Am I correct in assuming the SSFP filtering should work both ways?
i.e. it SHOULD stop the broadband messing up phone connections & SHOULD also stop phone connections messing up the broadband?
Could THIS be a pointer to the issue that has attenuated my sync/throughput speeds for the last few months?
A graph of now around 19 hours worth of connection time is attached.
The most recent SNRM drop was at around 8:30 this evening, when I simply picked up the handset that is plugged directly into the SSFP at the "new" master socket, with just the dial tone until it cut off.
Paul.
[attachment deleted by admin]
-
Something is not right. :no: (Apart from your scale on the X-axis of the graphs, that is. Perhaps you should awk '{ print NR+2, $4 }' or something similar . . . probably an easy fix.)
The SSFP filtering should, indeed, be operating "both ways". Just a moment -- I've had a sudden thought. Remembering discussions from the past with Messrs Ezzer & Razpag, I think what you are describing is symptomatic of an HR joint in the D-side cabling. Loop the line by picking up a handset and some current then flows around the circuit. Iffy joint, either HR or semi-conducting, reacts to the loop current and changes characteristics. Hence change in observed SNRM. I wonder if, by a spot of "fiddle faddle", you could log and then graph the downstream attenuation. (I'm sure Mrs Eagle wouldn't mind helping with the test by making telephone calls to her sister, first cousin once removed, great uncle Horace, hairdresser, etc. :-X )
Perhaps a weeks worth of graphs, both SNRM and Attenuation, presented to Plusnet will finally provide them with the evidence that OR will have to trace your D-side from the PCP to your NTE5/A, remaking each and every joint along the way! ::)
Finally, if I lived in your "Aerie" rather than my "Cattery", I would: (a) replace the front of the old NTE5/A (upstairs) with an LJU3/3A or, even better, an LJU4/3A (see this page (http://www.kitz.co.uk/adsl/btsockets.htm)) (b) earth the screening on your "link cable" (discussed above). :P
-
Something is not right. :no: (Apart from your scale on the X-axis of the graphs, that is. Perhaps you should awk '{ print NR+2, $4 }' or something similar . . . probably an easy fix.)
Hi b*cat,
Thanks for spotting my "deliberate" mistake ;)
I have now done it again using '{ print NR*2, $4 } & correctly shown 1440 minutes for a full 24 hours (not the 720 I had before) ;D
I think it looks right now?
Graphing downstream attenuation might be a bit tricky as we don't have a single value for VDSL2. It is split over 3 frequency band plans now with profile 17a.
I suppose I could include all 3 into one graph.
The highest frequency band will be really easy to graph for my connection though.
The attenuation at those frequencies is that high it is classad as N/A :D
Paul.
[attachment deleted by admin]
-
Thanks for spotting my "deliberate" mistake ;)
My pleasure. :)
I have now done it again using '{ print NR*2, $4 } & correctly shown 1440 minutes for a full 24 hours (not the 720 I had before) ;D
I am pleased to note that you spotted my "deliberate misguidance" which, of course, I inserted to ensure that you pay attention. :lol:
I think it looks right now?
It looks very useful evidence, indeed. :thumbs:
Graphing downstream attenuation might be a bit tricky as we don't have a single value for VDSL2. It is split over 3 frequency band plans now with profile 17a.
I suppose I could include all 3 into one graph.
The highest frequency band will be really easy to graph for my connection though.
The attenuation at those frequencies is that high it is classad as N/A :D
Go on. Just do it. You know you want to do so! :silly:
-
It looks very useful evidence, indeed. :thumbs:
All forwarded to Plusnet.
There had been a re-sync during the early hours of this morning - result was lower sync & higher SNRM, with errors currently quite low.
The attached graph shows matters following a modem reboot with the some stuff still connected & a subsequent reboot with nothing connected
The drop in SNRM at around 1320 minutes was with everything else disconnected (SSFP removed, so not even the extension to upstairs connected).
I tried a couple of handsets in the master socket's test socket (next to my PC) & made a couple of phone calls.
The drop in SNRM lasted for the exact duration of the phone calls.
Paul.
[attachment deleted by admin]
-
It looks very useful evidence, indeed. :thumbs:
On the basis of that evidence, along with evidence of a "massive" error count (over 2 Million CRC errors in a 38 hour period), Plusnet agree that an engineer's visit is now required to test my line again.
Just take a look at today's graph (attached).
All the weirdness occured AFTER I had posted the previous evidence to Plusnet.
The net result is that I am a good few Mb down on DS throughput compared to this time yesterday.
Thanks again to the unnamed people who developed the initial stats collecting / graphing scripts & modem unlocking methods.
Without their help I would have absolutely no evidence to work with.
Paul.
[attachment deleted by admin]
-
The attached graph shows matters following a modem reboot with the some stuff still connected & a subsequent reboot with nothing connected
The drop in SNRM at around 1320 minutes was with everything else disconnected (SSFP removed, so not even the extension to upstairs connected).
I tried a couple of handsets in the master socket's test socket (next to my PC) & made a couple of phone calls.
Sorry but you have confused the b*cat. ??? Your "master socket" is the NTE5/A at the end of the shielded cable. With the SSFP removed, how is the HG612 connected to the line? With an adaptor in the the NTE5/A's test socket? How was a telephone connected? Dingle-dangle microfilter, perhaps? With the lower front panel removed from the SSFP, all telephony wiring is disconnected. You could then plug a telephone into the socket, now exposed, in the lower half of the SSFP. The HG612 would still be connected to the upper, data, socket of the SSFP.
If necessary you could send some photographs of your office wiring, NTE5/A onwards towards the telephone and 'puter, for my consideration at "The Cattery". :-\
-
On the basis of that evidence, along with evidence of a "massive" error count (over 2 Million CRC errors in a 38 hour period), Plusnet agree that an engineer's visit is now required to test my line again.
If only you could have an OR engineer with either Messrs Ezzer's or Pag's knowledge and ability, this saga might just be drawing to a close. :-X
-
Sorry but you have confused the b*cat. ??? Your "master socket" is the NTE5/A at the end of the shielded cable. With the SSFP removed, how is the HG612 connected to the line? With an adaptor in the the NTE5/A's test socket? How was a telephone connected? Dingle-dangle microfilter, perhaps? With the lower front panel removed from the SSFP, all telephony wiring is disconnected. You could then plug a telephone into the socket, now exposed, in the lower half of the SSFP. The HG612 would still be connected to the upper, data, socket of the SSFP.
If necessary you could send some photographs of your office wiring, NTE5/A onwards towards the telephone and 'puter, for my consideration at "The Cattery". :-\
Hi b*cat,
I'm getting really good at confusing people.
What I really meant was:-
With the lower front panel removed from the SSFP, all telephony wiring was disconnected.
I then pluged a telephone into the socket, now exposed, in the lower half of the SSFP.
The HG612 WAS still connected to the upper, data, socket of the SSFP.
I incorrectly stated the SSFP was removed, when I should have stated the lower front panel was removed from the SSFP.
My bad :(
No photos necessary.
Paul.
-
If only you could have an OR engineer with either Messrs Ezzer's or Pag's knowledge and ability, this saga might just be drawing to a close. :-X
I have every confidence that the right sort of engineer will be sent, with the right sort of equipment, the right sort of tests will be carried out, the right sort of repair will be effected, & the right sort of re-tests will be carried out just to make sure ALL faults have been rectified, thus returning my connection to me in A-1 working condition.
& Voila! 40Mb for the Baldy one :-\
Paul.
-
& Voila! 40Mb for the Baldy one :-\
"And the band played 'Believe It If You Like'." :swoon:
-
Hi Paul,
We seem to have exactly the same issue. The only difference is mine was cured by switching to 17a and yours was caused by switching to 17a. Weird..
On 8c I accumulated 12 CRC and 4 HEC errors every second of every day or roughly 1 million CRC errors every 24 hours. As soon as I was on 17a instead of 12 CRC errors every second it dropped to 0.02 CRC errors a second.
I've put together a quick screen shot to demonstrate the dramatic reduction in errors below -
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fimg.photobucket.com%2Falbums%2Fv427%2Fgriff_90%2Fef3bfb4f.jpg&hash=90e92c5ae34b9b409df9d2698b079fdf05dd25b9)
-
Yes, mine is/was the opposite way around, the deterioration possibly starting with the switch to profile 17a (still not 100% sure though).
Unfortunately, I don't really have any records of error counts from when they were recently exceeding 1 Million per day.
With the aid aid a batch file & graphing script, I have very recently started logging errors / SNRM / Sync.
I have collected the stats at every 2 minutes over a period of a few days & attached graphs from one 24 hour period, with the CRC errors provisionally shown as the average errors per second.
This doesn't really highlight when the errors peaked or by how much.
e.g. At 10:17 this morning, following an earlier automated re-sync, CRC errors were running at 677 over 4965 seconds = an average of 0.136 errors per second.
However, 2 minutes later, CRC errors had shot up to 11430 over 5085 seconds = an average of 2.247 errors per second.
That doesn't sound too bad, until considering that 10753 errors had occured in only 120 seconds = 89.6 errors per second.
Between 10:43 & 10:45, errors shot up again from 24883 to 57099 somewhere within the 2 minute sample.
That equates to 268.467 errors per second, but only shows as an overall average of 8.592 in the graph.
As these errors probably occured in less than 2 minutes, the burst count is probably very high indeed.
At 20:47, the total CRC errors was 58174 over 42765 seconds = an overall average of only 1.36 errors per second for the whole duration of the VDSL2 connection since the last re-sync.
I think, to prove a point to Tuesday's engineer, the bursts of CRC errors & loosely associated SNRM fluctuations & re-syns etc. would carry more weight.
Any thoughts anyone regarding the best/most typical method of showing errors to aid with fault diagnosis, & is anyone interested in helping to code this for graphing purposes (prior to Tuesday's visit)?
Log snippets:-
13/11/2011 10:17 19904 4999 4.3 6.3 10.9 6.3 21596 5168 G.992.3_Annex_K_PTM) 677 0 16 0 200 0 4965 0.136
13/11/2011 10:19 19904 4999 4.9 6.3 10.8 6.3 22208 5194 G.992.3_Annex_K_PTM) 11430 0 156 0 4351 0 5085 2.247
:
:
:
13/11/2011 10:43 19904 4999 5.2 6.4 10.9 6.3 22432 5209 G.992.3_Annex_K_PTM) 24883 0 278 13 8516 0 6525 3.813
13/11/2011 10:45 19904 4999 7.3 6.6 10.9 6.3 24560 5334 G.992.3_Annex_K_PTM) 57099 0 440 13 14957 0 6645 8.592
:
:
:
13/11/2011 20:45 19904 4999 9.3 6.8 10.8 6.3 26468 5401 G.992.3_Annex_K_PTM) 58174 0 469 42 15184 0 42645 1.364
13/11/2011 20:47 19904 4999 9.1 6.8 10.8 6.3 26224 5389 G.992.3_Annex_K_PTM) 58174 0 469 42 15184 0 42765 1.36
Paul.
Edit:
Can everyone actually see the graph curves?
They are dark blue & dark red, but may display as much paler colours for some.
[attachment deleted by admin]
-
Hi Paul,
The graphs very clear and the colours match your descriptions using Chrome on a Mac.
It's useful to see there were significant fluctuations over a two hour period which must surely demonstrate that the disturbances are not blips due to your sampling rate.
Let's hope you get an engineer who is prepared to take note of your graphs.
Kind regards,
Walter
-
I wonder if it might be more appropriate to plot the first derivative of the CRC errors? By doing that, you could clearly show the sudden increase in the error rate. :hmm:
No. of CRC Errors Delta Time
e1 - t1
e2 e2 - e1 t2
e3 e3 - e2 t3
e4 e4 - e3 t4
e5 e5 - e4 t5
e6 e6 - e5 t6
e7 e7 - e6 t7
Then plot the absolute value of the Delta (y-axis) versus Time (x-axis).
[Edited on Novemeber 14, 2011, 1712 hours to insert the words "absolute value of the" into the last sentence.]
-
I wonder if it might be more appropriate to plot the first derivative of the CRC errors? By doing that, you could clearly show the sudden increase in the error rate. :hmm:
No. of CRC Errors Delta Time
e1 - t1
e2 e2 - e1 t2
e3 e3 - e2 t3
e4 e4 - e3 t4
e5 e5 - e4 t5
e6 e6 - e5 t6
e7 e7 - e6 t7
Then plot the Delta (y-axis) versus Time (x-axis).
Hi b*cat,
It would also clearly show the more realistic position of when there were no (or very few) errors over time.
Currently, it suggests a gradual tailing off of errors whichs isn't really the case.
In a strange way, I would prefer to be still registering over 1 Million errors per 24 hour period.
Unfortunately, I don't have the error data from when that was occuring in my log file.
The current reduction in the error rate is no doubt due to the reduction in sync speed from 25991 K to to the current 19904 K.
Paul.
-
Hi Folks,
Following this morning's engineer's visit, rather than repeat it all I have posted an update in my original thread at
http://forum.kitz.co.uk/index.php/topic,9726.msg204424.html#msg204424
Quick summary - Things are a bit better than they have been for a long time, & according to the engineer MIGHT improve further given time, but they are still not what they were at first.
Paul.
-
Good evening All,
Quick summary - Things are a bit better than they have been for a long time, & according to the engineer MIGHT improve further given time, but they are still not what they were at first.
Just a quick update & a query:-
After SNRM dropping overnight to 4.2 dB, it only peaked at 4.8 dB during today, & has tailed off since 3:00 pm to currently 3.8 dB.
A few CRC errors have also started to appear since around 5:00 pm.
Is this normal behaviour, or should I have expected it to go back up to around 6dB some time this afternoon?
I haven't forced a re-sync yet, as I thought it may be wise to prove my "repaired" connection's stability (or instability) first.
Paul.
[attachment deleted by admin]
-
Knowing you, as well as I now do, I shall say: "No fiddling!" :P
-
Knowing you, as well as I now do, I shall say: "No fiddling!" :P
;D ;D ;D
-
Hi
Stats look good :)
I was wondering whether it would be possible to show your CRCs not as an average over the connection time but as say errors in each 15 minute block . This would be a better indication of any problems and would Identify problematic times of the day . As it is your graph has shown an increase at about &:30 but how significant is it , The same rate occurring after say 3 days would be barely noticeable .
Regards Jeff
[attachment deleted by admin]
-
Hi
Stats look good :)
I was wondering whether it would be possible to show your CRCs not as an average over the connection time but as say errors in each 15 minute block . This would be a better indication of any problems and would Identify problematic times of the day . As it is your graph has shown an increase at about &:30 but how significant is it , The same rate occurring after say 3 days would be barely noticeable .
Regards Jeff
Hi jeffbb,
I/we have realised the limitations / inaccuracies of the current graphs & have been working on another version.
It's not completed yet, but when it is, it will show DS CRC errors in each 2 minute block to give a more realistic representation of the connection.
I have attached an example of where I am up to at the moment.
It doesn't show that much as total errors per 2 minute sample due to the scale of the graph (the lesser No. of errors are almost lost at the x axis, so I might end up showing it as average errors per second in each 2 minute sample........
Paul.
EDIT:
e.g. 2726 errors in the 2minutes between 17:03 & 17:05 today equates to 22.7 errors per second on average.
Whereas 179 errors between 07:37 & 07:39 equates to approximately 1.5 errors per second.
The graph's scale would then be only 0 to 23 on the y axis instead of 0 to 3000, & the errors per second would be a lot more visible.
[attachment deleted by admin]
-
How about a logarithmic scale? :-\
log10(delta of CRC) versus Time ???
-
I'm not sure about a logarithmic scale as it might distort the comparison between the good time & the bad times.
Now there is a bit more data, I think the graphs have a bit of meaning as they are, without bothering to display them as errors per second.
Maybe tomorrow the modem will re-sync itself & give me a bit more download speed?
I'm not holding my breath waiting for that though.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F1598226841.png&hash=9c57e15abfd116f961e32894dd75968deafe7064)
Paul.
[attachment deleted by admin]
-
Hmm. :hmm: I think you are right in rejecting the idea of a logarithmic scale. It was not one of my good suggestions. :no:
As for the graphs' creation, I think you have done a great job, leaning new techniques in the process. Sync speed and SNRM graphs I can read with ease. As for what your three error graphs are saying, I would be interested to know what someone like Jeff (for example) will make of them. :-\
-
Hmm. :hmm: I think you are right in rejecting the idea of a logarithmic scale. It was not one of my good ideas. :no:
As for the graphs' creation, I think you have done a great job, leaning new techniques in the process. Sync speed and SNRM graphs I can read with ease. As for what your three error graphs are saying, I would be interested to know what someone like Jeff (for example) will make of them. :-\
& here are this morning's graphs, showing an on the fly re-sync at 05:43.
DS Sync is up by 300 K, DS SNRM went back to 6dB, but is already tailing off a bit.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fspeedtest.net%2Fresult%2F1598565458.png&hash=81a5b020f2c4b4f1117e8f64dd1cda2fac1dd636)
I'll have to add some code on the lines of:- if previous error count was greater than current error count, then show current difference as zero (to properly accomodate a re-sync, when all counters are initially reset to zero).
Paul.
EDIT:
The second example shows the stats with the log manually edited to show all zeros immediately following the re-sync.
[attachment deleted by admin]
-
Hi
These graphs now really do show clearly when the CRCs are significantly above average ;D .
Much more illuminating than previous graphs . They show that generally your line is very quiet ,but during some specific times there is significant increase in noise .
Regards Jeff
-
These graphs now really do show clearly when the CRCs are significantly above average ;D .
Much more illuminating than previous graphs . They show that generally your line is very quiet ,but during some specific times there is significant increase in noise .
Hi jeffbb,
I have attached a couple of graphs.
The first set of graphs covers the last 8 day period (just to show the really high error count & other "instability".
(It was much worse the previous week, but I didn't have the means to record/graph the stats then).
The second set of graphs covers the last 2 days.
FYI, the engineer replaced some of the drop-wire & SSFP etc. Tuesday 15th.
The improvement is clear to see, but do you have any suggestions as to what could still be causing the error spikes?
This time next week I will have a collected lot more data theat may determine a pattern (or not).
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F1600668134.png&hash=bb6a748438a175fa88c52f8c5da032c6c4090b11)
FYI, The re-syncs as shown in the graphs (apart from when the engineer was working on the line) all happened "on the fly". i.e. the connection's dynamically obtained IP address remained the same, & Plusnet do not detect these as a loss of connection (& neither does my modem's log event log other than:-
2011-11-18 5:42:59 Notice 104500 DSL activate succeed
2011-11-18 5:42:43 Notice 104500 DSL deactivate).
Paul.
[attachment deleted by admin]
[attachment deleted by admin]
-
Hi
Definite improvement over the last few days ,It also seems to be a little better in the last 24 hrs of the 2 day graphs ,since that resynch Just before 0600Hrs ,CRCs seem to be generally down to < half of the previous 24 hrs eveen thogh the synch rate is a little higher .
Regards Jeff
Edit as you say a pattern may now emerge
-
Dear All,
Just a quick update following the engineer's visit of 15th November:-
The connection now appears stable, & is now hardly affected at all by incoming/outgoing phone calls.
Sync speed has also shown a SLIGHT improvement, but is still well below its original level.
14 day, 24 hour, & this morning's graphs can be seen at this link ( too large to upload here without losing definition):-
https://docs.google.com/open?id=0B7Kcea04kkOENTc2NDdhOTctMTM0MS00MzUzLWIzMjYtMjYzMTRhYmU3YTZm (https://docs.google.com/open?id=0B7Kcea04kkOENTc2NDdhOTctMTM0MS00MzUzLWIzMjYtMjYzMTRhYmU3YTZm)
Paul.
-
Hi
Problem is my eyesight isn't what it used to be :)
Regards Jeff
-
Hi
Problem is my eyesight isn't what it used to be :)
Regards Jeff
Neither is mine. I goosed without my reding glasses these days.
If you download the document (about 1 Mb), you can zoom into it to see the details with any picture viewer.
(unless you have already done that & are still struggling) ;)
Paul.
-
If you download the document (about 1 Mb), you can zoom into it to see the details with any picture viewer.
Hmm. Not very well thought out and is now, in all honesty, just data overload. :-X
Could it be that someone is just doing it because they are able to do so? :-\
To be able to look at all of your data, I had to: (1) download the file (2) cut out each individual graph (3) expand each graph to a suitable size (4) then view. :(
I know Eagles supposedly have excellent eyesight but that is a bit silly. :thumbdown:
-
To be able to look at all of your data, I had to: (1) download the file (2) cut out each individual graph (3) expand each graph to a suitable size (4) then view. :(
Really?
Sorry about that.
With my Windows PC with Windows Photo Viewer already installed it was a simple download (opened not saved) & zoom in & out action to see everything in detail usng the wheel mouse.
The point was that I was celebrating & displaying the fact that a BT engineer had actually made a visible improvement to my connection's stability.
Paul.
-
Really?
Really. :help:
Sorry about that.
No worries. I've forgotten about it already. :)
The point was that I was celebrating & displaying the fact that a BT engineer had actually made a visible improvement to my connection's stability.
Which is definitely worth celebrating. :drink:
-
Right, Here we go folks.
Since the last engineer's visit, my connection has remained quite stable with slight daily fluctuations in SNRM levels (between 4dB & 5dB), & vey few re-syncs.
Indeed it has remained in sync for over 130 hours (roughly 5.5 days) at the last count.
This is pretty much an all time record when looking back over the last few months.
My queries are:-
1) Does the error count (as shown in the attached 8 day graphs) look reasonable, or is it a little on the high side?
2) I see more than a passing resemblance between the shapes of the CRC & HEC error graphs.
Are they usually so closely related (differing values, but similar frequencies)?
3) If the error count IS still actually significant, what sort of things could be causing them, especially as there doesn't really seem to be a relationship to peak internet usage hours (between 16:00 & 0:00 each day)?
e.g. I'm not aware that I used the internet any more on the evening of day 3 than any other evening.
Paul.
[attachment deleted by admin]
-
I'm not going to attempt to answer your queries (I'll leave it to someone like Jeff ;D ) but say that I would expect to see a similar shape in the rate of change graphs of CRC, FEC & HEC counts.
CRC (http://en.wikipedia.org/wiki/Cyclic_redundancy_check)
FEC (http://en.wikipedia.org/wiki/Forward_error_correction)
HEC (http://en.wikipedia.org/wiki/Header_Error_Correction)
-
Hi
quote I'm not aware that I used the internet any more on the evening of day 3 than any other evening.
Slight misconception here . Its not just when you are using the internet that the errors occur.Errors will occur from the time the router connects to the Internet till the time the router is shut down .
Depending on the router some errors are reset after a Wan loss but CRCs may not be reset except by a reboot .
Whilst your router connection is live then whether your PC is connected or not does not change anything . The exchange and your router are still talking to each other . Just that there is no actual data been carried .
Regards Jeff
-
Hi All,
I am still a little curious to know whether or not my current & ongoing error count points to some sort of connection problem that is potentially still restricting my speeds to an extent.
As I lay in bed this morning at around 07:30 ish, listening to my FM radio alarm, I heard a few seconds burst of what sounded like static interference.
I have never heard this sound of static interference before (at this house), mainly as I usually arise before the alarm starts, & we don't have any other radios in the house.
I have heard it previously at a different house though.
I was at one time somewhere between a CB-er & a rdio ham (I couldn't be bothered to take the exam).
Exactly the same sort of static interference was so bad at that house (prolonged & extremely regular occurences) that I ended up packing in the radio communications hobby.
I only had a 56K modem at the time so it wasn't really affecting my broadband service at all.
So, of course, I dived out of bed (or dove out, for the benefit of any of our trans-Atlantic readers) just to see what effect, if any, it had on my SNRM & error count levels.
Lo & behold, there was quite a spike in error levels.
The last 24 hours of graphs are shown below (hopefully in a format that can be easily viewed).
As I thought my DS SNRM had been running a little lower than the 6 dB target for a while, I decided to re-sync the modem around 30 minutes or so later.
The result was a hike in SNRM to just over 6 dB, & a very slight increase in DS sync speed, along with a very slight increase in download speed.
Apart from this forced re-sync, my modem has not re-synced since 18th November, & SNRM levels have been pretty consistent, but at around 4 dB to 4.5 dB.
I might just try a full modem reboot later on.
So, for anyone who is in the know regarding error levels, do these errors as shown in the graphs point to an ongoing issue to be concerned about?
From other forums, I have seen other users reporting FTTC errors in their tens, or hundreds, over a period of a few days/weeks. Unlike mine where I am now getting much lowe levels than I was, but still experience a couple of thousand or so CRC errors in one hit.
There doesn't appear to be a definite pattern of increase in errors at 07:30 each day.
My central heating switches on at 6:30 every day & the pump runs continuously.
The street lights don't switch on & off at 7:30.
The fridge switches on & off regularly.
Mrs. Eagle hoovers & does other women's household stuff at differing times.
None of the appear to have much (if any) effect upon SNRM or error level spikes.
FYI, I am now collecting my stats every minute rather than every 2 minutes (can't get any more frequent than that for the time being), but I can now see that the errors always occur as a sudden burst within the one minute, rather than prolonged episodes over the space of a few minutes or so.
Paul.
[attachment deleted by admin]
-
Very interesting. :-\
Could those bursts of RFI be emanating from within Doris' domain (next door)?
I'm sure you will make good use of the current situation as a means of avoiding all those little tasks that Mrs Eagle has lined up for you. (Re-point the chimney stack. Re-furbish the kitchen and her utility room. Plant a crop of cabbages. Paint the landing. Clean the windows. Etc.) :lol:
-
Very interesting. :-\
Could those bursts of RFI be emanating from within Doris' domain (next door)?
That was a suspicion, but she has been away for the last few days, unless she has programmed her c/heating to come on at a different time while she is away.
She is usually a very early riser (5:00 am or so), & I can't say I have picked up a definitive pattern anywhere, apart from possibly around peak breakfast, evening meal & other types of general public use of electrical equipment times.
It might not actually be having any effect on speed or stability matters anyway, but the error count just looks a bit too high when compared against other users' error counts.
I'm sure you will make good use of the current situation as a means of avoiding all those little tasks that Mrs Eagle has lined up for you. (Re-point the chimney stack. Re-furbish the kitchen and her utility room. Plant a crop of cabbages. Paint the landing. Clean the windows. Etc.) :lol:
'Fraid not, my time for messing about like this expired some time ago, & the Christmas deadline for getting it all finisg=hed is looming far too quickly.
I'm already very much in the doghouse as it is :(
EDIT:
I notice the following from one sample at 21:38 this evening:-
16578 DS CRC errors
216 DS FEC errors
5150 DS HEC errors
I have absolutely no idea what could have caused them. Nothing coincided with that specific time in my house, & Doris is still away.
-
Hi jeffbb,
Hi
quote I'm not aware that I used the internet any more on the evening of day 3 than any other evening.
Slight misconception here . Its not just when you are using the internet that the errors occur.Errors will occur from the time the router connects to the Internet till the time the router is shut down .
I believe my latest 4 day stats clearly demonstrate the point you made.
I didn't use the internet much at all yesterday/last night, but just look at the bunch of errors from 18:30 onward last night that continued right up the the connection re-syncing in the early hours of this morning, along with the massive DS CRC error hit (approaching 250,000) while the PC was unattended at 11:58, 10th December.
Can any of you suggest what may have caused the errors, especially the big bunch of them from last night, & more importantly what can I do about them?
Please note the "messiness" from 9th December was a direct result of me swapping modems/rebooting/re-syncing etc. so I have no concerns about that period.
Plusnet don't appear to think my error count has any real effect upon sync speeds etc.
I would suggest that these stats demonstrate that they can have/do have some effect, otherwise, why would the connection have re-synced at 05:42 this morning (while I was still tucked up in bed)?
I note that since the re-sync, my error count is much lower, but so is my sync speed, along with DS SNRM being somehat higher.
DS SNRM actually suddenly peaked at 8.1 dB some 16 minutes after the re-sync.
It is currently running at 6.6 dB, but was typically running at an average of around 4.5 dB prior to this morning's re-sync.
Paul.
[attachment deleted by admin]
-
I'll be brief and say that it is the time of year for flashing Christmas lights. :-\
Perhaps you should take walks via both potential cable routes to the PCP & Fibre cabinet in H* Lane, noting any visible signs along the way?
-
Hi
What could have caused it ?? ,not really able to say as BK suggests Xmas ligths is one of many possibilities . But this problem has not just started its been with you for a long time . When errors get very high that Bit swapping can no longer take place then a resynch is bound to happen . At that point the connection stats will be negotiated . so often as you have experienced Synch drops and SNR margin is reset to target.
quote I note that since the re-sync, my error count is much lower, but so is my sync speed, along with DS SNRM being somehat higher.
Your SNR margin had been less than the target due to some general noise on the line ,before the resynch
DS SNRM actually suddenly peaked at 8.1 dB some 16 minutes after the re-sync.
during this period the general noise on the line dropped by a few dbs
It is currently running at 6.6 dB,
general noise on the line has increased slightly
but was typically running at an average of around 4.5 dB prior to this morning's re-sync.
that was with the higher synch rate
These sorts of changes are quite normal 2 to 3db changes are quite normal the only problem is when yo have massive errors forcing a resynch.
Regards Jeff
-
Just a quick update:-
It appears that the BT supplied modem (Huawei HG612) incorrectly reports some of its statistics in its GUI, particlularly error counts.
It seems to get FEC & CRC errors mixed up with each other, & maybe neither of them are the "true" values anyway.
For now, I have started to graph exactly what is reported in the GUI, & also what is reported via the various xdslcmd info --xxxx commands from a telnet session (please see the attached 16 day graphs - apologies if it is hard to view without downloading it first).
Some of the completely blank parts of the graphs are due to the fact that I wasn't logging the relevent data at the time.
The error count appears to have reduced overall since the engineer's visit in mid-November, but the sudden bursts of various errors does occasionally cause a re-sync, which also adds / removes DS interleaving at various differing levels.
The sudden & large bursts of errors have masked out all the other less severe error counts due to the scale/size of the graphs.
The current totals for a 52 hour connection up time are:-
DS CRC 462902 (also reported as RSUnCorr via xdslcmd)
DS FEC 7197 (also reported as OHFErr via xdslcmd)
DS HEC 136565 (also reported as HEC via xdslcmd)
From looking at other users' FTTC connection stats (almost zero error counts across the board - a few hundred maximum), these error counts still loook excessive to me, indicating an ongoing & reportable D-side line "fault".
Of course, Plusnet don't see it that way as I am "currently achieving reasonable stability & my speeds exceed the estimated speeds".
Is it at all possible that something on my side of the BT modem could be causing the errors/re-transmissions, such as the router or my PC itself?
Paul.
[attachment deleted by admin]
-
Is it at all possible that something on my side of the BT modem could be causing the errors/re-transmissions, such as the router or my PC itself?
No. :no:
A simple test. Remove the Netgear router by physically disconnecting it. Connect your main desktop workstation to the Huawei HG612 modem's LAN2 port only, just so that you can monitor the statistics. Do without Internet access for 24 hours. Any usage of that VDSL2 link will be just the normal conversational dialogue between the Huawei DSLAM in the FTTC and the Huawei HG612 in your office. What do the statistics look like when you are not using the link?