Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: Sptz on August 15, 2019, 04:15:07 PM
-
Hi all,
I've once used this setup for EE yeeeeeears ago and it worked great. I since got rid of the HG612 and due to Virgin's price hike decided to cancel the contract and go with Vodafone.
Has anyone successfuly used this setup with Vodafone? Do they provide the PPPOE username/pass by default or does it need to be requested? (Is there also some sort of tutorial anywhere?)
Thank you!!
-
Hi
I use the same modem with Vodafone.
You need to request your login details from them.
I used the live chat
-
I've got it working.
Disabled QoS, left all at default (IP_Bridged etc) and even though I should be getting 70Mbps and a minimum of 55Mbps I'm getting 43 tops. Doesn't go over that. Any ideas? Or is this just Vodafone being absolute crap? (this is all tested on ethernet)
-
Can you post some stats from the HG612 so we can see what the line is doing please?
-
Stats recorded 29 Sep 2019 09:34:47
DSLAM type / SW version: BDCM:0xa4a1 (164.161) / v0xa4a1
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 1 day 6 hours 43 min 49 sec
Resyncs: 0 (since 29 Sep 2019 08:55:45)
Downstream Upstream
Line attenuation (dB): 15.9 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 55399 20000
SNR margin (dB): 6.0 6.3
Power (dBm): 13.0 6.9
Interleave depth: 8 8
INP: 47.00 47.00
G.INP: Enabled Enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): 0.0001 22.4825
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
Downstream Upstream
General
rtx_tx 752 1447
rtx_c 642 1327
rtx_uc 33594 0
LEFTRS 23 13
minEFTR 55414 20003
errFreeBits 230808029 33757950
Bearer 0
RxQueue 45 39
TxQueue 15 13
G.INP Framing 18 18
G.INP Lookback 15 13
RRC Bits 24 24
Interleave depth 8 8
INP 47.00 47.00
INPRein 0.00 0.00
Delay 0 0
Bearer 1
Interleave depth 1 1
INP 2.00 4.00
INPRein 2.00 4.00
Delay 0 0
-
The DLM has capped your line at 55.4Mb.
It caps because of multiple resyncs, often during setting up modems and repeated power cuts.
Nothing to do with Vodafone.
-
The DLM has capped your line at 55.4Mb.
It caps because of multiple resyncs, often during setting up modems and repeated power cuts.
Nothing to do with Vodafone.
Hmm.. This has been locked to 55Mb since it was first plugged in, even with just the vodafone's own router/modem... Is there anything that can be done?
-
Do Vodafone have a 55/10 product which has wrongly been applied to your line?
-
Do Vodafone have a 55/10 product which has wrongly been applied to your line?
No, I have the 63Mbps, the other one is 35Mbps. BUT, as you can see in the screenshot I've attached here, the minimum guarantee for my package (the highest one) is 55Mbps which is why I think it looks really coincidental when since day one it seems to have locked to their MINIMUM guarantee... I don't know seems really fishy... Even though the estimation for my location is 66 minimum.
-
Do you need to wait for DLM to start lowering the target dB to get the expected speeds?
-
No, I have the 63Mbps, the other one is 35Mbps. BUT, as you can see in the screenshot I've attached here, the minimum guarantee for my package (the highest one) is 55Mbps which is why I think it looks really coincidental when since day one it seems to have locked to their MINIMUM guarantee... I don't know seems really fishy... Even though the estimation for my location is 66 minimum.
I think you are confusing what they are guaranteeing with how their products are set up. When FTTC was first being advertised, the packages were sold as typically 40/10 and 80/20 even though the actual speeds obtained were in most cases rather less than the headline figures. OfCOM decided that this was sharp practice and the sellers now have to advertise the sort of speeds that users may expect. However, in the background the packages would still be the 40/10 and 80/20 packages as far as the seller is concerned. That means that someone with a line capable of more than 40Mbps download who opts for the cheaper 40/10 package (however it is now advertised) would find their line capped at 39999kbps download. A lot of sellers have recently been stepping up their packages and their base package is now quite often 55/10 rather than 40/10. That means that someone with a line which will support more than 55Mbps download who signed up for the basic FTTC package would find their download speeds capped at 55Mbps.
I don't know what parameters Vodafone uses for their packages but if their cheaper package is based on 55/10, it may be that the system has incorrectly capped your line at 55Mbps.
From your stats, the upload looks to be capped at 20000kbps so at least that half of the package isn't compromised!
-
55399 is above what a line capped at 55MB would be showing
-
No, I have the 63Mbps, the other one is 35Mbps. BUT, as you can see in the screenshot I've attached here, the minimum guarantee for my package (the highest one) is 55Mbps which is why I think it looks really coincidental when since day one it seems to have locked to their MINIMUM guarantee... I don't know seems really fishy... Even though the estimation for my location is 66 minimum.
Nope.
A 55Mb product cap would be 54,999.
Your 55,399 sync is a 55.4Mb cap/banding applied by the OpenReach DLM and has nothing to do with the ISP.
That is unless it's the ISP's supplied hardware that has been resyncing over and over.
Even multiple resyncs during the setup process of your ISP supplied hub/modem can leave a line banded before a byte is downloaded.
It wasn't banded when activated though.
-
downstream is 6db SNRM, the sync speed could just be a coincidence.
Sometimes sync speeds do fall on banding boundaries.
-
The DS is currently 55.4 with interleaving and SNRM of 6.
If the interleaving comes off you will be up to 62 ish.
If the SMRM then goes to 3 then you'll be over 70 again.
-
The DS is currently 55.4 with interleaving and SNRM of 6.
If the interleaving comes off you will be up to 62 ish.
If the SMRM then goes to 3 then you'll be over 70 again.
The line isn't Interleaved it has G.INP on both upstream/downstream.
3dB would take it to 65-66Mb at best.
-
downstream is 6db SNRM, the sync speed could just be a coincidence.
Sometimes sync speeds do fall on banding boundaries.
https://forum.kitz.co.uk/index.php/topic,16850.msg310430.html#msg310430
Yesterday, though, I started getting intermittent Internet connection issues and noticed something was up with the dsl connection as it was reconnecting a lot of times,
https://forum.kitz.co.uk/index.php/topic,23740.msg402695.html#msg402695
Hmm.. This has been locked to 55Mb since it was first plugged in, even with just the vodafone's own router/modem... Is there anything that can be done?
I'm confident the line is banded and with a resync would be 55,399 or less.
xdslcmd info --stats with attainable included would have been nicer
-
Oh I see, I saw a number other than '1' in the interleaving on the O.P. so assumed it was interleaved.
Might I ask why the SNRM is 6 if the line's been banded at 55.4? Wouldn't that be higher since 55.4 is easier to achieve than the claimed attainable of 70 ?
-
The SNRM shown isn't the target SNRM but it's the current SNRM.
Current SNRM changes frequently and may have dropped after syncing.
The line is also a Huawei cabinet and it could technically be on a 5dB SNRM target.
I can't work that out without seeing the --stats command with attainable figures.
edit: claimed attainable of 70 is based on line with previous ISP.
Line might not be capable of that now due to crosstalk or DLM not giving 3dB
-
It's now changed as can be seen in the attachment. Speeds still don't sustain over 50Mb.
-
Could you post the output of xdslcmd info --stats (The Connection Stats tab on DslStats)
The figures in the HG612 webui are mainly incorrect.
-
The sync rates are about the only ones that are actually correct.
-
Kitz has mentioned this I’m sure, but I forget; why do some people say that sync speed increases if there is no interleave?
-
because FEC also gets turned off and FEC uses part of the sync speed for error correction.
-
Kitz has mentioned this I’m sure, but I forget; why do some people say that sync speed increases if there is no interleave?
Very different to ADSL.
Interleaving on FTTC takes roughly 10% off the sync compared to fastpath.
-
Weaver my current stats on the new default interleaving.
Max: Upstream rate = 26704 Kbps, Downstream rate = 82193 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 68689 Kbps
note the large gap between max and bearer on downstream rate.
Coding gain does mask some of it tho, the actual sync speed will be below 80 on fast path but still higher than 68.
-
Please forgive my total ignorance - Why is is there this co-occurrence then? Straight interleaving has no overhead, by definition, just a time delay. So there must be a side order of something else that comes along when someone selects ‘interleave’ in this particular case then.
Basically I know nothing about FTTC and its quirks.
Or is there something in the g.993.2 spec itself that I should be looking at ? Not having read it properly.
@chrys About the max and bearer lines - my VMG 1312-B10A shows utter bonkersness in the max values - I can’t make any sense of it. For me it doesn’t seem to correspond to any x I can think of in “the max of x” as far as I can see
@j0hn - wait, I’m suddenly realising that I might not be reading this as intended - maybe. Are we saying that the value of the quoted sync rate drops by 10% if someone chooses interleave or that one has to take the sync rate and multiply it by 0.9 to get the effective throughput ? I just am being more than a bit slow here
-
Interleaving comes with FEC overheads.
N - N Value (NFEC)
RS codeword size. Reports the actual number of Reed-Solomon redundancy per codeword used in the latency path. Used with the R value to express the rate of FEC applied.
R Value - RS check Bytes (RFEC)
Number of (redundant/parity) bytes occupied by the Error Correction process (overhead).
Often used to describe the level of error correction and can range from 0 to 20. The more check bytes that are used then the more errors can be corrected. The value 0 indicates no Reed Solomon coding. Use this value with N to express the rate of FEC applied as a percentage. eg R/N
If Chryralis posts his full stats you can see how much overhead is used by FEC on his line with Interleaving is enabled.
Post your own --stats and compare.
A line on FTTC that is fastpath or has G.INP will sync at the full rate and show a similar attainable.
Something like
sync: 41,111
attainable: 41,216
when interleaving is enabled there's an effect on both sync and attainable.
overheads reduce sync.
attainable is inaccurate * more info below.
for the same line interleaving would do something similar to
sync: 36,132
attainable: 43,324
sync reduced, attainable increased.
*
an older inaccurate "basic" method of working out the attainable used by most modems (and Broadcom chipsets) exaggerates the attainable with INP/Interleaving. newer Lantiq chipsets/firmware use a newer "improved" method of calculating the attainable and don't do this.
There's an example on the forum of a user with a Lantiq chipset who's interleaved posting their stats before and after a firmware upgrade.
Post 1 shows an Attainable way above sync and post 2 showed an accurate attainable.
1st time I've seen an accurate attainable with interleaving which ejs suggests shows Lantiq using a better method of calculating attainable on newer firmware which makes sense.
Can't find the post.
WWWombat detailed the different ways modems can calculate the attainable in this post (https://forums.thinkbroadband.com/fibre/t/4528909-openreach-to-rollout-3db-target-snrm-for-fttc-next-year.html)
-
Please forgive my total ignorance - Why is is there this co-occurrence then? Straight interleaving has no overhead, by definition, just a time delay. So there must be a side order of something else that comes along when someone selects ‘interleave’ in this particular case then.
Basically I know nothing about FTTC and its quirks.
Or is there something in the g.993.2 spec itself that I should be looking at ? Not having read it properly.
@chrys About the max and bearer lines - my VMG 1312-B10A shows utter bonkersness in the max values - I can’t make any sense of it. For me it doesn’t seem to correspond to any x I can think of in “the max of x” as far as I can see
@j0hn - wait, I’m suddenly realising that I might not be reading this as intended - maybe. Are we saying that the value of the quoted sync rate drops by 10% if someone chooses interleave or that one has to take the sync rate and multiply it by 0.9 to get the effective throughput ? I just am being more than a bit slow here
the max prediction is quite possibly not accurate when interleaving is applied, there is coding gain which will push it up tho. The sync speed reduction comes from FEC which is enabled alongside interleaving. kitz mentions it here https://kitz.co.uk/adsl/error_correction.htm
John here is my (interleaved) stats from the midnight yesterday, you can fetch historical stats from link in my sig if you want also.
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 26774 Kbps, Downstream rate = 82359 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 68689 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): 6.1 9.4
Attn(dB): 15.2 0.0
Pwr(dBm): 4.5 4.6
VDSL2 framing
Bearer 0
MSGc: 18 150
B: 51 236
M: 1 1
T: 64 5
R: 12 16
S: 0.0241 0.3771
L: 21256 5410
D: 1345 1
I: 64 255
N: 64 255
Counters
Bearer 0
OHF: 74052238 18714292
OHFErr: 9 39
RS: 1777339917 1215827841
RSCorr: 104456 307
RSUnCorr: 13 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2253654117 0
Data Cells: 215409838 0
Drop Cells: 0
Bit Errors: 0 0
ES: 62346 7301
SES: 70 1
UAS: 145 114
AS: 114626
Bearer 0
INP: 3.00 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 1.54 6.15
OR: 124.06 202.87
AgR: 68813.19 20203.27
Bitswap: 41496/41497 9/9