VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 2.7 12.6 19.1 N/A 7.0 14.3 22.2
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 24713 Kbps, Downstream rate = 77612 Kbps
Path: 0, Upstream rate = 19499 Kbps, Downstream rate = 64601 Kbps
Test Outcome Pass
Test Outcome Code GTC_FTTC_SERVICE_0000
Description GEA service test completed and no fault found .
Main Fault Location OK
Sync Status In Sync
Downstream Speed 65.5 Mbps
Upstream Speed 20.0 Mbps
Appointment Required N
Fault Target Fix Time null
Fault Report Advised N
NTE Power Status PowerOn
Voice Line Test Result Pass
Bridge Tap Not Detected
Radio Frequency Ingress Not Detected
Repetitive Electrical Impulse Noise Not Detected
Cross Talk Not Detected
Profile Name 37M-74M Downstream, Interleaving Low - 10M-20M Upstream, Interleaving Off
Time Stamp 2013-09-23T03:00:00
Parameters MIN MAX AVG
Down Stream Line Rate 64.5 Mbps 80.0 Mbps 71.1 Mbps
Up Stream Line Rate 18.8 Mbps 20.0 Mbps 19.7 Mbps
Up Time 21577 Sec 86394 Sec 76967 Sec
Retrains 0 5 0
What is the difference between 'path' and 'max' ?
Down Stream Line Rate 64.5 Mbps 80.0 Mbps 71.1 Mbps
Up Stream Line Rate 18.8 Mbps 20.0 Mbps 19.7 Mbps
That would indicate to me that you currently have surplus SNRm and if you restarted your modem at the time those figures where taken you would sync at a higher speed
Looks like you may have an intermittent fault and your SNRm is all over the show
Per second Per minute Per hour Per day
CRC Up 0.03 1.75 105 2519
Down 0 0 0 0
FEC Up 0.23 14.0 837 20094
Down 0.86 51.8 3108 74601
HEC Up 0 0 0 0
Down 0 0 0 0
ES Up 0.01 0.47 28.2 676
Down 0 0 0 0
I did restart the FTTC modem,
they corresponded exactly to when I lifted the receiver
DSLstats is normally very stable.
The only time it crashes for me sometimes if I disconnect the modem. I run windows, but eric may be able to comment more for linux. b*cat also uses it successfully on linux.
Eric (Roseway) will possibly see this early tomorrow (or should that be today!).
Obviously I didn't realise you ran linux, unfortunately the install for HG612_stats is for windows. BaldEagle (the author) runs Linux so he may be able to help give you some information to get it running on debian. He is normally around in the evenings.
xdslcmd info --Bits
xdslcmd info --linediag
xdslcmd info --pbParams
xdslcmd info --show
If only Baldy Bird did use an OS with a Linux kernel it would make things so much easier for me! That is a long-winded way of saying that Kitz has been on my cat-mint . . . :crazy: Sorry Kitz but the Featherless Avian is totally devoted to BGW. :-X
I ran DSLstats and got data into the graphs. So I left it for a few hours, but upon my return discovered it had crashed after just 20 mins. It wouldn't even respond to closing the app, but it did log blank graphs for every hour still. Weird! I've sent a stacktrace from the output to the developer.
I did restart the FTTC modem, even though path 0 sync is now 66mbps, the max sync speed is still ~11mbps higher.
Please find attached the SNR Margin, Bitswaps, bitswaps per min and the SNR graph. These are just over 15 minutes of sampling, DSLstats doesn't seem to get passed 20 mins of sampling without throwing an access violation (I run debian unstable so maybe its something in the new kernel)
I also noticed the SNRm per tone seems to show 0DB for tones 1-30, yet bitloading shows those tones in use. Is this just a limitation of the modem reporting?
this morning at 6:58 the upstream SNRm went to 1.6dB for about 5 minutes.
Morning B*cat and thanks for the graphs :) hope you had a pleasant catnap.
>> m quite surprised to see all of the CRC errors and significant SNRm changes are only happening on the upstream. Any initial hunch as to why that is?
Usually an indication of filters, internal wiring, or a physical line fault (HR).
I'm also getting a feeling of deja-vu... its a shame HG612 modem stats wont work on linux.
When I last used the HG6xx_stats utility, I had it executing on a Raspberry Pi. Once sufficient data had been harvested from my HG622 modem/router (operating in ADSL2+ mode), I passed a copy of the log file to No-Feathers and he processed it with his code, running on BGW.
Quotethis morning at 6:58 the upstream SNRm went to 1.6dB for about 5 minutes.
That is the type of thing I was looking for... because that is what will cause your line to drop and resync at lower speeds. Once thats happened a few times then the DLM will start to take over and restrict attainable speeds.
I have already considered the possibility that your speeds may be banded, due to at one point seeing some surplus SNRm, but you said a resync didnt give you any higher speed. We'd need more information over a longer period though to say this for sure.
If you can get a pattern forming from DSLstats then it gives you something to go back to Plusnet with.
although the speed loss HAS been put down to crosstalk (probably)Im still not convinced BE, IMHO thats rather a lot to suddenly lose from x-talk. :( I guess you will find out - if vectoring ever gets rolled out. :/
Im still not convinced BE, IMHO thats rather a lot to suddenly lose from x-talk. :( I guess you will find out - if vectoring ever gets rolled out. :/
** HG612 stats doesnt ever show my U1 band because its too low for the graph... I keep forgetting to ask if theres any way I can adjust the 'y' axis graphing parameters.
Not sure about the SNRM change on US from 10am today, all the kids were out and I was asleep :D
BE - would be good to see if PN can pull the crosstalk test results for you to give an answer there for sure. They seem to have the data available to them!
From a very quick look about -28.5dBm.
Yes I concur - big gaps in that time period for other things too!
That just looks like a gap in the data harvesting rather than anything to be concerned about connection-wise.
I have attached a recent version of HG612_stats.exe that you may wish to use in place of the existing one from the v 1.1 download.
BE - would be good to see if PN can pull the crosstalk test results for you to give an answer there for sure. They seem to have the data available to them!
I've now made the Y axis for DS Power & US Power include down to -30dBm.
An amended version of graphpd.exe is attached.
<snip>
You can use BTs ringback service test on 14070. Whilst there may as well try the quiet line test to see if you can hear any noise.
<snip>
Do you still have DSLstats running
sorry about the digressions in your thread
Did you ever try as I suggested earlier to observe the SNRm when the phone rang
I think you require the services of an Analytical Eagle. ::)
Now where could he be? :-\ Subjected to the dominating, steely glare of Mrs Eagle, perhaps? :-X
suggesting some sort of general & continuous US interferenece (despite US Interleaving depth being 1 - i.e. fastpath)
possibly something being switched on/off, possibly even in a close neighbour's house?
Is there any evidence of anything untoward in the ROUTER's logs from around the times of the larger dips?
I prefer to plot the graphs using multiples of 1,2,3,4,6,8 days,Thanks for the tip, ill do a few days in future :)
more people have connected to the fibre service in your area and as such your line has dropped to a more realistic level or it could be down to the copper cabling in your area not being able to handle the full speeds.
No ISP has access to interleaving status on FTTC.
It is all controlled by the DLM which is the only arbiter of whether it is on or off.
ISP cannot switch it on or off for you.
This is different from ADSL - I know.
I have requested they move me to the speed DLM profile specified by BTW on the GEA FTTC factsheet.
I have looked over the graphs that you have attached. I'm unable to advise on the Quiet Line test as this isn't something that we ever see any results. In regards to the SNR graph that you have attached this isn't something that I would be concerned over as on Fibre your connection isn't really affected by the SNR like it is on a copper connection.
Plusnet are now offering a phone line engineer to come and check the line in their latest reply. What do you good folks here make of this statement they have made though?QuoteI have looked over the graphs that you have attached. I'm unable to advise on the Quiet Line test as this isn't something that we ever see any results. In regards to the SNR graph that you have attached this isn't something that I would be concerned over as on Fibre your connection isn't really affected by the SNR like it is on a copper connection.
30 errored seconds per hour is ok. As long as none are SES.#
ES: 13 1750
SES: 5 18
UAS: 29 29
AS: 247716
I reads as if that statement has been made by a new employee who has not yet finished her/his training course! >:(
If I had a Plusnet service and that statement had been made to me, I would be referring it back to Bob Pullen (http://forum.kitz.co.uk/index.php?action=profile;u=834) or Chris Parr (http://forum.kitz.co.uk/index.php?action=profile;u=460) for remedial action.
From your description of the state of the external joints where (I assume) the service feed joins the internal cabling it reads as if they need to be remade (re-crimped). Flag up the 'manky-ness' of the joints with Plusnet and accept the Openreach engineering offer.
Hi Kitz,
Plusnet reported back to me that all plusnet customers are automatically placed on the 'speed' DLM profile and you are only moved off from this by request. Therefore, my line is already on the 'speed' DLM profile apprently. With 1045+ interleaving this is surprising.
*edit* Plusnet also confirm the DLM policy here http://community.plus.net/forum/index.php/topic,116753.msg1009493.html#msg1009493 (http://community.plus.net/forum/index.php/topic,116753.msg1009493.html#msg1009493)
Sorry should have clarified. "Standard" *is* the "Speed" profile, the only other two options we have are "Stable" or "Super Stable".
So, by default we do supply customers on the fastest profile available.
Meow and thank you BC! I too thought it an odd statement to make ;) Sadly chris and bob seem no longer active on this forum from their profile stats, but I will certainly try to raise them on the PN forums soon. I asked PN to send a SFI (fingers crossed) but lets see what they say in return.
BOT - FTTC Logged Faults - Post SFI until this time.
Ive just given up, its not worth my time arguing with plusnet and I can pay to exit the contract and switch to a better ISP once FTTPoD is available in this area
Per second Per minute Per hour Per day
CRC Up 0.01 0.58 35.0 841
Down 0.39 23.7 1421 34102
FEC Up 0.17 10.0 603 14462
Down 10.6 634 38053 913275
HEC Up 0 0 0 0
Down 0 0 0 0
ES Up 0.01 0.42 25.0 600
Down 0 0.04 2.47 59.2
Are you able to see the computer monitor displaying the real-time SNRM graph, as produced by Eric's DSLstats utility, when using the telephone?
If so, use the phone and call 17070, option 2. Listen to what should be a quiet line whilst watching the monitor. When you get bored with that, clear down the call and re-initiate it, this time taking option 1, ring-back. When prompted, return the handset to the rest and watch the monitor as the ringing voltage is applied to the line.
What, if anything, is shown by the SNRM graph? :-\
That graph attached (*edit* in last post), around 17:30 was an incoming call, ring for maybe 20 s then a few mins chat. The US SNRM went to 0. DS SNRM was unaffected.
Ill do another test Tuesday when im home using 17070 (kids asleep now) to see if we get any DS change now - by using your exact instructions !
Per second Per minute Per hour Per day
CRC Up 0 0.28 16.7 402
Down 0.01 0.76 45.8 1100
FEC Up 0.09 5.24 314 7542
Down 0 0 0 0
HEC Up 0 0 0 0
Down 0.01 0.81 48.8 1170
ES Up 0 0.14 8.22 197
Down 0.01 0.44 26.1 627
Think he was SFI, not sure. Said he'd been doing it 17 years and he arrived in one of the huge vans with all kinds of gubbins in the back.
As for your current statistics, I really can't say. Perhaps the owner of a VDSL2-experienced eye will be able to comment?
I'll try and 'whistle up' an Eagle for you . . . (https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.centos.toracat.org%2Fajb%2Ftmp%2Fwhistling.gif&hash=49d306bbfb8d35e3e1ad0bd9933b01750a81d0eb)
I have heard that FTTC involves traffic sharing the fibre between the cabinet and the exchange. and that the greater the number of users of the fibre, the more the speed tends to diminish. I infer that FTTC is more susceptible to contention issues. I understand that people who connect to the cabinet first get the full bandwidth of the fibre. As more use FTTC through that cabinet, the pioneer FTTC users may believe that their connection is getting slower.
Someone please disabuse me if this understanding if I am mistaken.
I find PlusNet extremely helpful and they have been consistently so over the eleven years I have been a customer. They are beholden to BT Wholesale and Openreach.
... too tired to check for typos :-[
Hi folks,One day one my PlusNet speed was 57Mbps, with no problems, but on day 10 it went down to 47Mbps and as they guessed it would be 47 they would not help and I've had to stick with that :(
Was hoping for a bit of advice here as I seem to be going in circles with plusnet support.
I had a new line installed from plusnet when I moved to my new home. The choice of home was made in part by the location to a FTTC enabled cabinet, as I am particularly throughput hungry in my line of work. The cabinet is approx 200m (300 tops) in terms of actual line length from the home and the BT line speed estimator is 71.9mbps. Its a new estate (8 years) with all new wiring. My in laws live next door, have ADSL2+ and their attenuation is around the 7db mark direct to exchange one 600 metres away.
for the first 14 days of my line being installed, it ran at a sync of 78mbps solid. Did not change once and throughput was fine (though there was some throughput decreases during peak periods, the vdsl2 line sync rate did not change and off peak was full throughput). Ping was a steady 8ms.
About 5 days after the email from plusnet saying my line speed (after training) was 78mbps, the line speed started to go down. At first it was 76mbps, then 72, then 68, then 65, then 64 and today its down further to 62mbps. Upstream has remained solid at 20mbps sync rate with 20mbps ip profile (though throughput is only about 15mbps). Ping has shot up to mid 20's.
The attenuation stats of the line areQuoteVDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 2.7 12.6 19.1 N/A 7.0 14.3 22.2
Which seems very high on D1 for the wire going just around the corner. We also have people reporting its very hard to hear us on a voice call (though we hear them just fine). We have tried different handsets and the same result.
Also saw this on the HG612 last time I pulled the stats when it dropped to 64mbps sync.Quotexdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 24713 Kbps, Downstream rate = 77612 Kbps
Path: 0, Upstream rate = 19499 Kbps, Downstream rate = 64601 Kbps
What is the difference between 'path' and 'max' ? Why would my path be lower than my 'max' ? Plusnet said that 'max' just means the capability of the cabinet, not my line (which seems odd).
Plusnet are saying that as throughput is actually at near line sync rate, there is not a problem. Even though I have demonstrated line sync rate was high but is deteriorating over time they state (via their faults checker) that my line just cannot support the throughput it originally had and there is no way they can raise a BTW fault until my throughput is 50% of the sync speed (which as the sync speed just keeps decreasing over time, seems like a catch 22). As a techie, it bugs the hell out of me that something 'did' work then deteriorates, but is actually 'operating correctly'...
There are no extensions wired in to phone socket, its straight to the NTE. Theres the FTTC faceplate on there direct to modem. Speed tests have all been carried out via BTW checker using Ethernet on my side not wireless. Quiet line test seems fine, I cant hear any buzz, crackles or hum. I have changed both the VDSL2 modem and the router itself and the problem remains, so I am pretty confident this is not a CPE side issue.
You can see from plusnets own diagnostics (taken before the recent line sync rate drop to 62mbps) that things appear OK, though I do note that the connection uptime was at this highest speed the longest.QuoteTest Outcome Pass
Test Outcome Code GTC_FTTC_SERVICE_0000
Description GEA service test completed and no fault found .
Main Fault Location OK
Sync Status In Sync
Downstream Speed 65.5 Mbps
Upstream Speed 20.0 Mbps
Appointment Required N
Fault Target Fix Time null
Fault Report Advised N
NTE Power Status PowerOn
Voice Line Test Result Pass
Bridge Tap Not Detected
Radio Frequency Ingress Not Detected
Repetitive Electrical Impulse Noise Not Detected
Cross Talk Not Detected
Profile Name 37M-74M Downstream, Interleaving Low - 10M-20M Upstream, Interleaving Off
Time Stamp 2013-09-23T03:00:00
Parameters MIN MAX AVG
Down Stream Line Rate 64.5 Mbps 80.0 Mbps 71.1 Mbps
Up Stream Line Rate 18.8 Mbps 20.0 Mbps 19.7 Mbps
Up Time 21577 Sec 86394 Sec 76967 Sec
Retrains 0 5 0
Ive demonstrated to plusnet via the ticket that the speeds were stable, but are now deteriorating. They are just saying this is normal and until my throughput is 50% of sync speed there is nothing that can be done, which seems stupid if the sync speed just keeps decreasing. Right now I get throughput of about 58mbps down, which means essentially I am paying them 50% more than their 40mbps product for 18mbps of gain (which im sure as the situation continues will end up being even less).
Does anyone have any advice here? I feel like im banging my head off a brick wall with their support team.