Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: neil on October 28, 2021, 02:44:30 PM
-
Hello
I don't know what's the issue but every few mins line gets new IP when downloading games.
here is the ping and you can see no ping when it is disconnected. 3 times in 5 mins during download.
and also, dslstats snr downstream and upstream
-
Does the line lose sync or just the PPP session?
-
Does the line lose sync or just the PPP session?
I don't know I think just PPP session because after few seconds it reconnects.
-
Have you tried other large downloads to see if they affect it similarly? (There's some files here (https://www.thinkbroadband.com/download) you could try)
-
Have you tried other large downloads to see if they affect it similarly? (There's some files here (https://www.thinkbroadband.com/download) you could try)
yes, only when there is some download. Today I tested again, no disconnect but errors were high. SNR margin goes down for downlink when there is downloading
upload is fine.
02 Nov 2021
CRC errors per hour: 697 Down, 0 Up
FEC errors per hour: 113194 Down, 0 Up
HEC errors per hour: 42359 Down, 0 Up
ES per hour: 2.68 Down, 0 Up
SES per hour: 1.34 Down, 0 Up
-
stats
Max: Upstream rate = 40587 Kbps, Downstream rate = 86864 Kbps
Bearer: 0, Upstream rate = 20246 Kbps, Downstream rate = 43563 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 17.8 20.6
Attn(dB): 17.8 0.0
Pwr(dBm): 14.4 9.3
VDSL2 framing
Bearer 0
MSGc: 30 20
B: 31 239
M: 1 1
T: 64 64
R: 10 0
S: 0.0233 0.3772
L: 14392 5090
D: 2795 1
I: 42 120
N: 42 240
Counters
Bearer 0
OHF: 44375103 16546906
OHFErr: 1060 58
RS: 4154970097 1058949001
RSCorr: 205989 0
RSUnCorr: 285373 0
Bearer 0
HEC: 63209 0
OCD: 296 0
LCD: 296 0
Total Cells: 4061102611 0
Data Cells: 587520497 0
Drop Cells: 0
Bit Errors: 0 0
ES: 5 8
SES: 2 1
UAS: 34 34
AS: 99864
Bearer 0
INP: 7.50 0.00
INPRein: 0.00 0.00
delay: 16 0
PER: 2.25 6.05
OR: 128.00 34.32
AgR: 43690.66 20280.77
Bitswap: 32976/32976 45/45
Total time = 1 days 3 hours 44 min 58 sec
FEC: 205989 0
CRC: 1060 58
ES: 5 8
SES: 2 1
UAS: 34 34
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
Latest 15 minutes time = 14 min 58 sec
FEC: 419 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
Previous 15 minutes time = 15 min 0 sec
FEC: 21 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
Latest 1 day time = 3 hours 44 min 58 sec
FEC: 7399 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
Previous 1 day time = 24 hours 0 sec
FEC: 198590 0
CRC: 1060 58
ES: 5 8
SES: 2 1
UAS: 34 34
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
Since Link time = 1 days 3 hours 44 min 23 sec
FEC: 205989 0
CRC: 1060 58
ES: 5 8
SES: 2 1
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
-
Looks like its really struggling, you're connected almost half the speed you should be if that's an 80/20 package you're signed up on.
Is there any noise on the phone line?
-
Just a quick reminder that neil is in Pakistan, so he is not using an Openreach product. ;)
-
Looks like its really struggling, you're connected almost half the speed you should be if that's an 80/20 package you're signed up on.
Is there any noise on the phone line?
no speed is according to my package 35down/18up
there is no noise on the phone line
btw upto 50mb speed is allowed here on VDSL
-
Just a quick reminder that neil is in Pakistan, so he is not using an Openreach product. ;)
Yeah that does complicate things as I have no idea how it SHOULD be behaving. I was definitely thrown by it looking so similar to an under-performing 80/20 package.
-
no speed is according to my package 35down/18up
there is no noise on the phone line
btw upto 50mb speed is allowed here on VDSL
Any idea if its supposed to sync at this speed or does it sync as fast as possible and then the ISP just throttle the throughput to what you paid for?
-
Any idea if its supposed to sync at this speed or does it sync as fast as possible and then the ISP just throttle the throughput to what you paid for?
it just syncs at the speed as given in the package
-
it just syncs at the speed as given in the package
But it's syncing at 43/20 on a 35/18 package so that suggests there is some ISP throttling going on?
-
But it's syncing at 43/20 on a 35/18 package so that suggests there is some ISP throttling going on?
I wonder if they are over-provisioning like Cable do over here so that you get real-world throughput matching the package rather than the sync rate matching the package?
Its certainly a curious speed if that is indeed an actual cap on the sync rate. My first thought was that it WASN'T capped and its some instability that has resulting in that speed, but without knowing if that sync rate is normal or not, its impossible to know.
The fact PPP seems to be dropping though is what makes you wonder if there is packet loss. Though its always possible its a faulty router or PSU, as its only happening under load.
-
But it's syncing at 43/20 on a 35/18 package so that suggests there is some ISP throttling going on?
it is sync at that to give real world speed as mentioned by the @alex atkin UK and 2mb extra is for IPTV
and here is speed test
-
I wonder if they are over-provisioning like Cable do over here so that you get real-world throughput matching the package rather than the sync rate matching the package?
Its certainly a curious speed if that is indeed an actual cap on the sync rate. My first thought was that it WASN'T capped and its some instability that has resulting in that speed, but without knowing if that sync rate is normal or not, its impossible to know.
The fact PPP seems to be dropping though is what makes you wonder if there is packet loss. Though its always possible its a faulty router or PSU, as its only happening under load.
yes, over-provisioning to give you real world throughput matching the package.
it is capped at that sync rate by the ISP. Previously I was using 25mb package let me share screenshot of that sync rate.
yes, it is happening underload. If I remember correctly previously, I also replaced the PSU, I was getting disconnects at that time too during underload.
-
Hi neil,
what router are you using?
-
Hi neil,
what router are you using?
modem or router?
modem is hg 150-ub
router is openwrt pi4
-
Looking back at Reply #5 (https://forum.kitz.co.uk/index.php/topic,26446.msg443843.html#msg443843) we can see from the "Max" estimate line --
Max: Upstream rate = 40587 Kbps, Downstream rate = 86864 Kbps
and the then current SNRM excess over 6 dB (here I am assuming the target is set at 6 dB) --
Down Up
SNR (dB): 17.8 20.6
that the service provider must be applying some form of capping. :-\
-
Looking back at Reply #5 (https://forum.kitz.co.uk/index.php/topic,26446.msg443843.html#msg443843) we can see from the "Max" estimate line --
and the then current SNRM excess over 6 dB (here I am assuming the target is set at 6 dB) --
that the service provider must be applying some form of capping. :-\
yes, it is capped I think from ISP side. This is not how it is done in the UK?
-
modem or router?
modem is hg 150-ub
router is openwrt pi4
So is the Pi4 handling PPP? If so you should have the logs to prove if PPP is dropping.
If the logs show PPP has dropped multiple times while the AS value from the modem shows it was in sync, you have your answer of what is happening, just not why.
Also the HG150-UB technically appears to be a router itself, is it being used merely as a modem to split the Internet and IPTV onto their own ports? They key here again is where PPP is being handled as you can rarely get some weird connectivity issues if you are in a double-NAT.
-
So is the Pi4 handling PPP? If so you should have the logs to prove if PPP is dropping.
If the logs show PPP has dropped multiple times while the AS value from the modem shows it was in sync, you have your answer of what is happening, just not why.
OMG thank you so much for saying this. I absolutely missed to look at my pi4. But sadly, I just updated the image on pi4 and it rebooted.
-
So is the Pi4 handling PPP? If so you should have the logs to prove if PPP is dropping.
If the logs show PPP has dropped multiple times while the AS value from the modem shows it was in sync, you have your answer of what is happening, just not why.
Also the HG150-UB technically appears to be a router itself, is it being used merely as a modem to split the Internet and IPTV onto their own ports? They key here again is where PPP is being handled as you can rarely get some weird connectivity issues if you are in a double-NAT.
Yes Pi4 is handling ppp and modem is running in bridge mode.
-
Stats recorded 11 Nov 2021 03:39:36
DSLAM type / SW version: BDCM:0xb124 (177.36) / v0xb124
Modem/router firmware: Not monitored
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 1 day 11 hours 12 min 17 sec
Resyncs: 0 (since 11 Nov 2021 03:39:32)
Downstream Upstream
Line attenuation (dB): 18.4 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 43563 9711
SNR margin (dB): 22.4 9.3
Power (dBm): 14.4 9.4
Interleave depth: 2795 8
INP: 7.50 0
G.INP: Not enabled Not enabled
Vectoring status: Not monitored
RSCorr/RS (%): 0.0819 0.0000
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
yesterday I noticed changes on my line, now upload speed has been reduced and snr are also stable for download. but downside is upload speed is limited to 9.7mb only :'( :'(
-
Looking back at Reply #5 (https://forum.kitz.co.uk/index.php/topic,26446.msg443843.html#msg443843) we can see from the "Max" estimate line --
and the then current SNRM excess over 6 dB (here I am assuming the target is set at 6 dB) --
that the service provider must be applying some form of capping. :-\
Please your comments on my line after new stats
-
Previously (Tue 2nd November) --
Connection speed (kbps): 43563 20246
SNR margin (dB): 20.6 17.8
Now (Wed 10th November) --
Connection speed (kbps): 43563 9711
SNR margin (dB): 22.4 9.3
We can see that there is a reduction in the SNRM for the US band and a marked reduction in the US band synchronisation speed. Whether it is due to a defect in the metallic pathway or intervention by the service provider, I am not sure. This is rather puzzling.
-
Wouldn’t we think that the sync rates would be nice round numbers like xx000 or xx999 or something close to that? The SNRM values are so high suggesting either noise or banding, as has been said, and there’s no G.INP? But no (recent) errors visible - no CRCs or ES at all?
-
So were back to my original confusion over the weird sync rate then? ;)
-
Unless the package has changed I'd be reporting that as a fault as I can't think why the US sync rate would suddenly halve otherwise.
-
Its certainly an interesting new development. Unfortunately sometimes the only way to identify a fault is to hope it gets worse which it appears to have done.
-
thank you for comments.
I don't know what's going on but line is stable for internet
line is up and no resync in last 2 days
and there is no noise on phone line whatsoever
Protocol: PPPoE
Address: ************/32
Gateway: ***********
DNS 1: 8.8.8.8
Connected: 1d 22h 41m 10s
-
If everything is working fine then it might be worth leaving it alone for now. Are you still getting the loss of PPP sync when downloading or has that stopped too?
-
Stats recorded 11 Nov 2021 19:41:04
DSLAM type / SW version: BDCM:0xb124 (177.36) / v0xb124
Modem/router firmware: Not monitored
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 0 hour 41 min 21 sec
Resyncs: 0 (since 11 Nov 2021 19:07:32)
Downstream Upstream
Line attenuation (dB): 17.8 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 43563 20246
SNR margin (dB): 22.4 20.6
Power (dBm): 14.4 9.3
Interleave depth: 2795 1
INP: 7.50 0
G.INP: Not enabled Not enabled
Vectoring status: Not monitored
RSCorr/RS (%): 0.0000 0.0000
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
sync rate back to original after power reset. I will only know about desync when there is some big update for a game. For usual browsing and speed tests it is working fine. I think something is wrong somewhere in joint somewhere as mentioned by burakkucat Whether it is due to a defect in the metallic pathway or intervention by the service provider, I am not sure. This is rather puzzling.
-
here is SNRM graph for last 2 hours
strange anomaly