Print

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

[ejs]

I guess it's banded. The FTTC DLM seems to apply banding fairly commonly, unlike the ADSL DLM which adjusted the target SNRM first, and only uses banding in the worst cases.

Interleaving+FEC can result in the max attainable rate being moderately higher than the actual rate, but it wouldn't cause the increased SNRM. In a similar way as increasing the target SNRM results in a lower rate, limiting the rate results in a higher SNRM.

The DLM may eventually relax or remove the banding, how long it takes, no-one really knows. But whatever caused the banding in the first place generally needs to no longer be present.

[NewtronStar]

Going from ADSL to VDSL2 the internal wiring needs to be almost perfect on longer lines and same for the master socket with a new NTE5 & SSFP MK3 installed it's a pity you never had Openreach to do the FTTC install.

As this is a new FTTC line I would wait a few more days but if your are not happy after that you can call your ISP and ask them to send an OR engineer out it should be free

[dfects]

You know, I think I might of missed something. I installed an extra 12v 120mm pc fan in my cabinet that houses that hub and the other electronics I mentioned on Sunday night. I didn't notice until just, but the next time it synced on Monday morning the hub dropped from 40.48mb to exactly 40.00mb. This could possibly be a band? The plusnet doc says so. The next 2 nights it dropped to 35.00mb, then 32.40mb both of which are bands according to that doc too.

The fan was only about 10-15cm from the hub, and maybe 30cm from the faceplate Could this of been the cause of all the interference? Its all been removed now, so the only thing close to the hub and faceplate are my asus router and the hub itself.

[j0hn]

ask your ISP to run a GEA line test. this will show if your line is banded or not.

[sevenlayermuddle]

Regarding the gradual decline since getting the service, is there any possibility you were one of the first to be connected after the cabinet went live?

If so then as neighbouring lines get connected up so crosstalk will increase and your speeds will drop.   I was pretty much first in my village to get FTTC and initially saw around 50Mbps.  Over the next few months as the word spread, and the rest of the village switched over, I progressively lost almost half of that, getting about 30Mbps last time I looked.

[dfects]

We probably were the first on there. I knew the cab had been fitted as I drive past it every day so I was checking daily until it became available, so I signed up straight away and took the first slot I could  Glad to be free of 6mb adsl.

It was only activated on the 14th of Sept, 10 days ago today. Maybe it is cross talk as I did tell my neighbours as I saw them, at least the ones who mentioned how frustrated they are with the slow net we had.

I know our cab serves our 27 houses, a small industrial estate of maybe 10 units and a couple of older houses. Most the rest in our area are on another cab from my checks. Our adsl cab is a very small rusty old cab a new shiney double cab, and the fibre one fitted is smaller than most in the area too.

I managed to test my corded phone on my nans bt connection today, but her line has constant clicking and hissing so it wasn't much help (luckily shes 85 and can barely hear so she doesn't care). I tried it in my parents virgin phone line by lifting the receiver and pressing one number so it was quiet and it sounded almost identical to on our bt line on the quiet line test... that is a very faint hiss. There may be a tiny bit more of a buzz on our bt line, but its hard to tell as it was tested several hours apart. Either way, its not really told me if its the cheapo phone or the line thats making the noise

Our hub had two TR69 (ACS?) connections this morning, one that set the downstream noise margin from 8.8 to 8.6 at 8.28am then one that set it back to 8.8 at the same 8.54am fixed time!? Not sure if that tells me anything at all

[Weaver]

A cheapo old-fashioned wired POTS telephone should be fine for testing, surely. If you can hear hiss, then that’s presumably not good (?)

[dfects]

I'm using this http://www.argos.co.uk/static/Product/partNumber/3924358.htm and I have to admit, I'm trying it through the adsl filter as I don't want to disconnect the hub at the moment which i know is less than ideal.

Its hard to describe the noise, its constant, monotone and quiet... as in if there is any noise at all while listening you won't hear it. If its silent, and you concentrate its there. My parents virgin line was pretty much the same with this handset, so not sure if its the low quality speaker or maybe both are crap lines. Are your guys lines honestly dead silent? so you can't hear a difference between the test, and the line being dc'ed as in the receiver was down?

[ejs]

@sevenlayermuddle
It seems unlikely to be crosstalk, because crosstalk is basically noise, so if it were crosstalk, the speed would be decreasing while the SNRM stays the same, or the crosstalk would be seen by a drop in the SNRM if the crosstalk appeared and you remained connected. But here we've got decreasing speeds, and a raised (from the usual default of 6 dB) SNRM.

Our hub had two TR69 (ACS?) connections this morning, one that set the downstream noise margin from 8.8 to 8.6 at 8.28am then one that set it back to 8.8 at the same 8.54am fixed time!? Not sure if that tells me anything at all

The TR69 remote management won't be setting the SNRM, but it might cause the Hub to reboot or reconnect. The current SNRM will vary slightly over time, this is normal.

[dfects]

Hmm it seems strange, as I say the TR69 connections seem to come in at 8.54ish every day, so I've had chance to check before and after it definitely seems to be when the noise margin alters on the hub but I haven't had any resyncs or reboots for just over 3 days now. Maybe its just a coincidence. Today it changed twice, once at 8:27 and then again at 8:54, both times it changed as I was keeping an eye on it before I went out. I think the 8:27 one coincides with when I did a fault check on bt's site oddly.

Code: [Select]

08:54:31, 24 Sep.
TR69 connectivity to (pbthdm.bt.mo) has been closed
08:54:31, 24 Sep.
TR69 sending GetParameterValuesResponse message
08:54:31, 24 Sep.
TR69 receiving GetParameterValues message
08:54:31, 24 Sep.
TR69 connectivity to (pbthdm.bt.mo) has been initiated
08:54:31, 24 Sep.
TR69 receiving InformResponse message
08:54:30, 24 Sep.
TR69 event found : 6 CONNECTION REQUEST
08:54:30, 24 Sep.
TR69 event found : 4 VALUE CHANGE
08:54:30, 24 Sep.
TR69 sending Inform message
08:54:29, 24 Sep.
TR69 event found : 6 CONNECTION REQUEST
08:54:29, 24 Sep.
TR69 event found : 4 VALUE CHANGE
08:54:28, 24 Sep.
TR69 sending Inform message
08:54:27, 24 Sep.
TR69 creating new session with ACS
08:54:25, 24 Sep.
TR69 ConnectionRequest: processing request from ACS
08:54:25, 24 Sep.
TR69 ConnectionRequest Failed
08:54:25, 24 Sep.
TR69 ConnectionRequest: processing request from ACS
08:54:23, 24 Sep.
TR69 connectivity to (pbthdm.bt.mo) has been closed
08:54:22, 24 Sep.
TR69 connectivity to (pbthdm.bt.mo) has been initiated
08:54:22, 24 Sep.
TR69 receiving InformResponse message
08:54:22, 24 Sep.
TR69 event found : 4 VALUE CHANGE
08:54:22, 24 Sep.
TR69 event found : 2 PERIODIC
08:54:21, 24 Sep.
TR69 sending Inform message
08:54:20, 24 Sep.
TR69 event found : 4 VALUE CHANGE
08:54:20, 24 Sep.
TR69 event found : 2 PERIODIC
08:54:19, 24 Sep.
TR69 sending Inform message
08:54:19, 24 Sep.
TR69 creating new session with ACS
08:51:37, 24 Sep.
TR69 ConnectionRequest Failed
08:51:37, 24 Sep.
TR69 ConnectionRequest: processing request from ACS
08:46:02, 24 Sep.
HTTP UserAdmin timeout from 192.168.1.7
08:34:16, 24 Sep.
HTTP UserAdmin login from 192.168.1.7 successfully
08:34:09, 24 Sep.
HTTP UserBasic login from 192.168.1.7 successfully
08:28:37, 24 Sep.
TR69 connectivity to (pbthdm.bt.mo) has been closed
08:28:36, 24 Sep.
TR69 connectivity to (pbthdm.bt.mo) has been initiated
08:28:36, 24 Sep.
TR69 receiving InformResponse message
08:28:36, 24 Sep.
TR69 event found : 4 VALUE CHANGE
08:28:35, 24 Sep.
TR69 sending Inform message
08:28:34, 24 Sep.
TR69 event found : 4 VALUE CHANGE
08:28:33, 24 Sep.
TR69 sending Inform message
08:28:33, 24 Sep.
TR69 creating new session with ACS
08:27:40, 24 Sep.
TR69 connectivity to (pbthdm.bt.mo) has been closed
08:27:39, 24 Sep.
TR69 sending SetParameterValuesResponse message
08:27:39, 24 Sep.
TR69 receiving SetParameterValues message
08:27:39, 24 Sep.
TR69 connectivity to (pbthdm.bt.mo) has been initiated
08:27:39, 24 Sep.
TR69 receiving InformResponse message
08:27:39, 24 Sep.
TR69 event found : 6 CONNECTION REQUEST
08:27:39, 24 Sep.
TR69 event found : 4 VALUE CHANGE
08:27:38, 24 Sep.
TR69 sending Inform message
08:27:37, 24 Sep.
TR69 event found : 6 CONNECTION REQUEST
08:27:37, 24 Sep.
TR69 event found : 4 VALUE CHANGE
08:27:36, 24 Sep.
TR69 sending Inform message
08:27:36, 24 Sep.
TR69 creating new session with ACS
08:27:34, 24 Sep.
TR69 ConnectionRequest: processing request from ACS
08:27:34, 24 Sep.
TR69 ConnectionRequest Failed
08:27:33, 24 Sep.
TR69 ConnectionRequest: processing request from ACS
08:27:31, 24 Sep.
TR69 connectivity to (pbthdm.bt.mo) has been closed
08:27:30, 24 Sep.
TR69 sending SetParameterValuesResponse message
08:27:30, 24 Sep.
TR69 receiving SetParameterValues message
08:27:30, 24 Sep.
TR69 connectivity to (pbthdm.bt.mo) has been initiated
08:27:30, 24 Sep.
TR69 receiving InformResponse message
08:27:30, 24 Sep.
TR69 event found : 6 CONNECTION REQUEST
08:27:30, 24 Sep.
TR69 event found : 4 VALUE CHANGE
08:27:29, 24 Sep.
TR69 sending Inform message
08:27:28, 24 Sep.
TR69 event found : 6 CONNECTION REQUEST
08:27:28, 24 Sep.
TR69 event found : 4 VALUE CHANGE
08:27:27, 24 Sep.
TR69 sending Inform message
08:27:27, 24 Sep.
TR69 creating new session with ACS
08:27:25, 24 Sep.
TR69 ConnectionRequest: processing request from ACS
08:27:25, 24 Sep.
TR69 ConnectionRequest Failed
08:27:24, 24 Sep.
TR69 ConnectionRequest: processing request from ACS
08:27:12, 24 Sep.
TR69 connectivity to (pbthdm.bt.mo) has been closed
08:27:11, 24 Sep.
TR69 sending GetParameterValuesResponse message
08:27:11, 24 Sep.
TR69 receiving GetParameterValues message
08:27:11, 24 Sep.
TR69 connectivity to (pbthdm.bt.mo) has been initiated
08:27:11, 24 Sep.
TR69 receiving InformResponse message
08:27:10, 24 Sep.
TR69 event found : 6 CONNECTION REQUEST
08:27:10, 24 Sep.
TR69 event found : 4 VALUE CHANGE
08:27:10, 24 Sep.
TR69 sending Inform message
08:27:09, 24 Sep.
TR69 event found : 6 CONNECTION REQUEST
08:27:09, 24 Sep.
TR69 event found : 4 VALUE CHANGE
08:27:08, 24 Sep.
TR69 sending Inform message
08:27:07, 24 Sep.
TR69 creating new session with ACS
08:27:05, 24 Sep.
TR69 ConnectionRequest: processing request from ACS
08:27:05, 24 Sep.
TR69 ConnectionRequest Failed
08:27:05, 24 Sep.
TR69 ConnectionRequest: processing request from ACS
08:26:23, 24 Sep.
TR69 ConnectionRequest Failed
08:26:23, 24 Sep.
TR69 ConnectionRequest: processing request from ACS

If the DLM has set some form of offset for the noise margin, is it likely to see variations around that still? Not sure if it going from 8.6 back to 8.8 is an indication its definitely seeing noise on my line still or if its something still in place by DLM from previous errors/dc's.

[ejs]

The TR69 messages will be coincidental with any changes in the current SNRM. If you keep watching the current SNRM, you're bound to see it go up or down slightly, because the noise level will change, from all sorts of electrical equipment, environmental conditions, crosstalk from other lines maybe even ADSL ones.

[dfects]

Thanks for your help. So would you say the noise margin currently set at 8.8db being higher than 6db being an indication there is a noise problem currently? Or could it be a precaution from DLM that might drop over time due to previous errors/noise.

Sorry for all the questions.

[ejs]

I think the elevated SNRM is a result of the DLM capping (banding) the speed. It could be due to the previous noise from all those electronics near the modem that you've removed, or it could be due to something else, some issue with the line. It's difficult to tell without more detailed stats.

I suppose you could re-instate all the electronics near the modem, check the SNRM before switching them on, then switch them on, and re-check the SNRM. If you see the the SNRM has decreased after switching all that kit on, then it would indicate that they are indeed a source of noise affecting your VDSL2 connection. However, some sources of noise may affect the error counts, which you can't see, more than they affect the SNRM, which you can see.

It could all actually be simply the DLM finding a stable setting for your line, in which case the DLM won't increase the speed unless the line is improved somehow.

[dfects]

Thanks for the response. I'm hoping its a sign that the line originally started at 36mb, then slowly increased over 5 days to 40.48mb before diving to 32.4mb where it is now that it can actually be stable at higher speeds, even if not at 40+mb. Unless for some reason it tests higher speeds even if the error count is high on lower speeds. Only thing that really changed was me installing that extra fan, checking temps with an infrared thermometer and seating the adsl cable fully. Other than that it can only be an external fault that developed recently or interference from a neighbours new line if it increases only when stable.

Is it normal to see the upstream noise margin remain around 6 even when the downstream increases? I'd of thought both would be affected. Its still punching above its max sync estimate of 7.7mb with 9.68mb atm.

[ejs]

No, I don't think so, I don't think there's anything to suggest a fault developed recently.

You start off on some default settings, and it takes a few days for the systems to detect that your modem supports G.INP, and then it enables G.INP, perhaps resulting in a slight increase in speeds, compared to interleaving+FEC. But it may never have been stable at the initial 36Mb or the subsequent 40Mb, and so the DLM made further changes.

If it had been operating for a few weeks at one speed, then the speed decreased, it might be different. But for only a few days, right at the start of the service being activated, I don't think there's much significance to it. Sure, if your speeds keeps getting slower and slower and slower, you would be able to report a fault, but if it's still operating within estimates, getting six engineers out to try and find a couple of extra Mb might not really be called for.

The FTTC DLM adjusts the downstream and upstream independently.