Broadband Related > FTTC and FTTP Issues

Big drop in upload speed

(1/3) > >>

tomtom:
Hi, there has been a big drop in my upload speed which appears to have happened when g.inp was enabled?

US0 attenuation has increased form 7.5 to 13.1db. The download attenuation has not changed its 26.6db for DS1 and speed increased from 23mb to 25mb.

However upload has dropped from 0.6 to 0.16mb!

What kind of fault would cause this as I though the highest frequencies are effected the most when the line degrades?

Could this be a firmware upgrade on the dslam that has altered transit power? The dslam was on 0x86 firmware before.
I will try and get some line stats tomorrow.

tomtom:
Here is modem stats

tiffy:
Just to give an idea what can effect VDSL-2 synch/data speeds, in particular US only, I had a similar issue in 2020, early days of the first Covid lock down, saga is here:
https://forum.kitz.co.uk/index.php/topic,24606.msg413899.html#msg413899
Not saying this will be directly relevant to your situation but may be food for thought.

As you likely know, at 26.6db attenuation you have a long copper run to the DSLAM, fibre cabinet hence the overall poor line synch speeds.
Note that you are using a ZyXEL VMG8924-B10A modem/router, a very well respected VDSL device, uses Broadcom chipset and as such supports the excellent DSLStats utility program, I would advise that you should get this running if at all possible on a Raspberry Pi or PC which will make monitoring and diagnosis much easier.
Software is free and will run on a RPi Zero-W or any RPi of a greater spec. so doesn't have to cost a fortune.
Lots of directions to get DSLStats up and running on various devices available on this forum.

Edit: Typo correction

parkdale:
Hi tomtom, i'm have the same problem... since G.IMP has been enabled my upload speed has dropped from 8Mb to 3.2Mb. Historically my line use to support 16Mb! but over the years has been clipped :(
I see from my error counter things are going to get worse.
Attached before and after..

kitz:
Openreach use Dynamic Spectrum Management (DSM), which is linked to DLM in that it comes under the control of the RAP side of RAMBo.  See DLM Management Device (RAMBo).
To try and cut a longer story short, there are various profile masks that affect which tones load and at what power. The idea of these masks is to help protect against x-talk.  Lines that are nearer the cab have a more restrictive power mask than longer lines.  There's many different masks that can be applied and "your mask" is analysed and applied during the sync process depending upon factors such as your line length, how close the cab is to the exchange, amount of INP.

When looking at a lines bit loading graph, you can usually see effects of the PSD mask best in the U1 band.

>> as I though the highest frequencies are effected the most when the line degrades? <<

If your line is reasonably long, then it is quite possible that U1 is the highest frequency or that not many bits are loading in the U1 channel.   You need to check the Band Plan in pbParams and your bit loading.  If you use DSLstats, this nicely maps the info for a visual representation.

For example mine is shown below, my PSD mask (Power cut back) for U1 is quite harsh compared to the surrounding downstream.  I'm on a fairly short line so it doesn't really affect my overall max upstream sync as I'm able to get most of my upstream bandwidth in the U2 band.
But if your line is fairly long and cant makes use of the upstream U2 band (tones 1984,2770), you are relying mostly on the tones in U0 and U1, then the amount of bit load is restricted.

Although there isn't anything in black and white, but from observed behaviour it would appear that when g.inp is enabled,  the DLM upstream INP is increased.  This together with the upstream masking & PCB can result in less bit load in U1  in turn reducing power > increase attenuation > reduced upstream max sync.

Sorry this doesn't help 'fix' what has happened to you, just giving an explanation likely why you've ended up with less upstream.  Your line isn't the first Ive seen where the PCB causes restricted upstream sync and wont be the last.  The lines I've seen it most reported on are those where the cab is some distance to the exchange.  Although cab to exchange makes no difference for the fttc lines, its the neighbouring ADSL lines that could be drowned out without the use of PCB on the FTTC connections.

I hate to sound negative, but if it it the switch to g.inp and Openreach using higher INP on the upstream, then there is little you can do. However, it is worthwhile fighting it if you can with your ISP, there may be a spare pair thats cleaner and can give you a better sync   There most likely wont be, but until you register the speed reduction you wont know... so its worth a shot to at least see if there is anything OR can do to eke out as much possible upstream sync.  Good luck.

Navigation

[0] Message Index

[#] Next page