Print

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

[plexy]

Hi folks,
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 are

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

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.

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

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.

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

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.

[kitz]

Hi and welcome

What is the difference between 'path' and 'max' ?

Max is the maximum estimated speed by your router that you line is capable of.  Path is the current sync speed.
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.

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

Looks like you may have an intermittent fault and your SNRm is all over the show.   From your comments, its even possible that the SNRm could be dipping when the phone is in use.

Grab a copy of HG612_Modem Stats or DSLstats.. or both!  We need to see if your SNRm is fluctuating as I suspect it will be from what you've said.   The problem is proving it.. and thats where HG612stats and DSLstats come into their own.

Plusnet is one of the ISPs that will accept & recognise  HG612 stats as diagnostics. 

[plexy]

Thanks for the welcome and reply Kitz!

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

Thats what I thought too, but a modem restart (unplug, wait 30 seconds, plug back in) results int he sync staying at the 'path 0' speed. The higher max speed is never hit.

Looks like you may have an intermittent fault and your SNRm is all over the show

Good to have some independent verification that this is not a 'normal' case Thanks very much for that. I will get the stats rolling as soon as I get a switch wired up to port 2 on the modem (ive only one ethernet port at the modem side back to the rack so need to put a switch in). Im on linux at home so I guess its DSLstats for me!

Thanks again for the support. Ill get the graphing going this evening once im home and let it run for a couple of days.

[renluop]

As to getting things done at PN, though they are very good, it can be beneficial to post in the members' forum. Often a staffer will pick it up and run with it. I'm sure Kitz will not mind me saying so, and defo no detraction from this forum.

[plexy]

Hi folks
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)

The house is pretty quiet here tonight, all others are in bed so all major electrical items in the house are off/standby (this computer excluded). The phone line has no extensions wired in behind the faceplate and I have removed the sky box extension that plus into the front of the FTTC faceplate before commencing the stats gathering.

Kitz, it looks like you were right about your hunch - my SNR margin changes when I use the phone. They are the three dips clearly visible there and they corresponded exactly to when I lifted the receiver vs when I was on hook. The phone test was an outgoing call to 17070 and opting for quiet line test.

Error stats:

      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   

Thanks again for the super help!

[plexy]

adding more graphs in case they are of use.

[kitz]

I did restart the FTTC modem,

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.


----
The SNRm doesnt look too bad from that short sample.
Fair bit of errors and bitswap, but I think we really need to see what happens over a longer period.

they corresponded exactly to when I lifted the receiver

It would be interesting to see what happens when the phone actually rings (sometimes it will cause a very sharp spike), and also whilst on a call for a longer period (to see if it continues to decline whilst the line is open).

The fact that something is happening when you take the phone off the hook suggests a possible HR fault, but BT would need to see it dip more than that though :/

[burakkucat]

DSLstats is normally very stable.

Absolutely.

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.

I am currently testing the latest release -- version 3.97 -- and have not noticed anything out of the ordinary.

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.

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 . . .    Sorry Kitz but the Featherless Avian is totally devoted to BGW. 

I must say that plexy's Hlog graph is very impressive . . . I have never seen one as good as that before today! The Eagle will turn decidedly green with envy when he sees it.

[plexy]

thanks both. Ill try the ring test tomorrow when no ones asleep and im sure my wife will use the phone too at some point so hopefully get a longer call.

I updated the SNRm per tone and QLM graph in my previous post. Didn't realize i had them on collapsed view.

Bitloading is attached here too

[burakkucat]

Would you be able to establish a telnet connection to your HG612 and then, from the busybox shell, capture the output returned by the following four commands, please?

Code: [Select]

xdslcmd info --Bits
xdslcmd info --linediag
xdslcmd info --pbParams
xdslcmd info --show

Perhaps invoke script to capture the session's output and then send a copy of the typescript file to me via e-mail . . . as I would very much like to see the 'snapshot' graphs for your line. 

(A PM, containing my e-mail address, is on its way to you.)

[kitz]

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 . . .    Sorry Kitz but the Featherless Avian is totally devoted to BGW. 

Oh..  I do apologise to both the black cat and bald eagle.    I dont know why I thought that (and have done for aaaaaaaages that he ran both)

Plexy, I'll have a look tomorrow at your graphs..  its the SNRm that Im particularly interested in seeing what going on, so if you can leave it running for about a day, and see if we can see any pattern emerging.

Looks like b*cat has also asked for you pbParams  etc, so I shall leave you in his more than capable paws

[plexy]

Thanks both.

I will leave dslstats running and if it goes again then ill try to switch to see if HGstats works under wine.

I have mailed over the commands requested, b*cat - thanks

[Chrysalis]

plexy you have already been given good advice, I just want to say thanks for pasting that info you got from plusnet, as I find it interesting they can see historically you had a 80mbit sync at one point.  Also that they have some kind of crosstalk test which I am curious how they could detect that from their end.  Your bitloading is sort of like mine where the lowest downstream frequencies are very underperforming, in my case a engineer diagnosed a noise/crosstalk fault on the pairs between the voice and fiber cabinet.

[roseway]

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 received your message and replied to it, but at the moment I'm slightly at a loss to explain the problem. Effectively we're using the same OS (I use Debian Testing AMD64 with the latest kernel - 3.10.11-1). I'll investigate further.

[plexy]

Thanks Roseway. I dropped you a mail in reply, I guess maybe its just the unstable branch. Its been running fine since it was last restarted around 1am so unsure of what it was first few times around. If I see it again ill let you know and hopefully the stacktrace provided offers some clue for you in the meantime.

FYI the other helpful people on the thread - the SNRm was sold all night, then this morning at 6:58 the upstream SNRm went to 1.6dB for about 5 minutes. There was no one awake in the house at the time, and the only AC system in the house that has a timer (the hot water) isn't set to come on for another hour after that. *edit: is set to be on 24 hours. Ive also just ran the boiler at full pelt for heating and hot water and the SNRm didn't change.

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?