Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: NewtronStar on March 18, 2016, 08:49:46 PM
-
[Admin Note - Split from topic originally started in the G.INP on ECI topic (http://forum.kitz.co.uk/index.php/topic,17195.0.html)]
Huawie Cab & HG612
Sync rate @ 35580 Kbps
IP profile 32.7
Now I have seen how to get the ratio but what ever happens when using the PC calculator it go's belly up so could one of use kind members do the maths for me :)
-
Sync rate @ 35580 Kbps
IP profile 32.7
Hmm . . . Odd. :hmm:
(32700 / 35580) x 100 = 91.91%
???
-
Sync rate @ 35580 Kbps
IP profile 32.7
Hmm . . . Odd. :hmm:
(32700 / 35580) x 100 = 91.91%
???
Indeed BC something is not quite right with my line and noticed this a few years ago the sync rate and IP profile don't match.
-
Indeed BC something is not quite right with my line and noticed this a few years ago the sync rate and IP profile don't match.
At first I thought hmmm strange. Have you ever had one that matched up.
Then considering what I just typed above re the 60 seconds, I wonder if there is a possibility that RAP hasn't detected a retrain and change of sync speed... therefore it's possibly calculating on an old sync speed.
____
That delay is definitely there. I've seen cases on my own line where BRAS hasn't recorded quick resyncs in respect of info recorded for bRAS control. BRAS control is also how openreach engineers see on their system for loss of sync.
iirc AndyH also quoted a BT doc where it mentioned 40/60 seconds of downtime to ensure RAMBO detected the retrain properly. The only problem is that RAMBO consists of RAP and DLM and he was using the 40/60 secs as proof that DLM needs 1 min to detect a retrain.... when in actual fact it relates to the BRAS functions.
-
the formula doesnt work.
I think it does work with the TD-W9980, but only since TP-LINK changed the firmware to make it fully support g.inp.
No it does not even work for me using a HG612 and a Huawei cabinet so that formula should be put in the bin ;)
-
No it does not even work for me using a HG612 and a Huawei cabinet so that formula should be put in the bin ;)
The weird thing is that yours didnt even work with the 96.79% figure. The 96.79% should work for everyone on NGA (except those who are g.inped).
Did you try a resync leaving it disconnected for at least a min so that the bRAS RAP porfiler has chance to pick up your new sync speed. I mentioned in this post (http://forum.kitz.co.uk/index.php/topic,17195.msg316620.html#msg316620) that Openreach recommends a min of 40-60 seconds to ensure the RAP function notices the change in sync. RAP is separate from the DLM. DLM info is monitored by the DSLAM. RAP has to go over to the RAS and it doesn't always pick up quick resyncs.
-
Was wonder about my IP profile Vs Sync rate which is 35580 Kbps and the IP is 32700 which gives me 91.90% this seems abnormal from what I am seeing on this thread.
If the forum moderators want to move my post that is fine just want to get to the bottom of how or why this has happened.
-
Hi NS. Ive split this off because it needs looking into further as yours is the first line that Ive seen that doesnt obey the 96.79 / 96.69 rule.*
It does indeed work out at 91.9 % which is quite a deviation from 96%
The way it is supposed to work is sync speed minus an allowance for overheads. Even the adsl2+ lines use a fixed 88.2% method which is more widely documented.
iirc it was BaldEagle that first noted the difference for g.inp lines so he gets credit for the 96.79 / 96.69 observation.
I cant help but notice that yours is about half way between the 2.
Im trying to think of reasons why this could possibly be. The obvious would either be something to do with your framing overheads...
OR is your line banded (which I know it isnt) , has it ever been banded?
Can you remember is your IPprofile always 32.7 regardless of your sync speed?
-----------
Working backwards with some figures so I know what Im dealing with
A sync of 35580 should give you an IPprofile of:-
34.4
An IPprofile of 32.7 should give you a sync of:-
33784 (non g.inp)
33819 (g.inp)
Actually I just looked back on MDWS and I can see you arent banded... but Oct 8th you had a sync that would fit your existing profile, alternatively around May time last year.
---
*barring the odd 0.01 due to rounding of framing parameters.
-
There is one other peculiarity about N*Star's circuit that is noticeable when looking on MDWS. There never seems to be a continuous 24 hours period of data uploading to the MDWS server . . . I do not recall ever seeing the percentage higher than 98%
???
-
Can you remember is your IPprofile always 32.7 regardless of your sync speed?
-----------
Working backwards with some figures so I know what Im dealing with
A sync of 35580 should give you an IPprofile of:-
34.4
An IPprofile of 32.7 should give you a sync of:-
33784 (non g.inp)
33819 (g.inp)
Actually I just looked back on MDWS and I can see you arent banded... but Oct 8th you had a sync that would fit your existing profile, alternatively around May time last year.
---
*barring the odd 0.01 due to rounding of framing parameters.
Yes the IPprofile does change it will lower when say I do a re-sync and the sync rate is 34000 kbps to 32000 Kbps or so depending on time of day when I do modem re-sync
Well on May the 13th 2015 was when I changed ISP provider BT to EE, I do remember some years ago on the these forums BaldEagle was helping work out the IPprofile percentages and did show up as 96.79 well before the G.INP days.
There is one other peculiarity about N*Star's circuit that is noticeable when looking on MDWS. There never seems to be a continuous 24 hours period of data uploading to the MDWS server . . . I do not recall ever seeing the percentage higher than 98%
???
I don't know why this is happening it only started 3 weeks done most things reset router and rebuilt the RPi changed ethernet cables and so on but no luck.
-
@ns
Can you post a full set of the "--stats" output?
After discovering what more of the framing parameters are, I'm wondering if anything will stand out to me.
-
Thanks WWWombat I would appreciate any help you can give me.
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 6255 Kbps, Downstream rate = 34092 Kbps
Bearer: 0, Upstream rate = 6296 Kbps, Downstream rate = 35580 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 5.6 5.9
Attn(dB): 24.6 0.0
Pwr(dBm): 11.2 0.1
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 227 191
M: 1 1
T: 0 40
R: 10 12
S: 0.2038 0.9680
L: 9342 1686
D: 4 1
I: 238 102
N: 238 204
Q: 4 0
V: 0 0
RxQueue: 84 0
TxQueue: 21 0
G.INP Framing: 18 0
G.INP lookback: 21 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 694442
OHFErr: 97 408
RS: 2661593688 327729
RSCorr: 4286622 513
RSUnCorr: 0 0
Bearer 1
OHF: 49508544 0
OHFErr: 3 0
RS: 297050895 0
RSCorr: 5934 0
RSUnCorr: 3 0
Retransmit Counters
rtx_tx: 54818236 0
rtx_c: 135603 0
rtx_uc: 221 0
G.INP Counters
LEFTRS: 70 0
minEFTR: 35574 0
errFreeBits: 431040383 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2870615739 0
Data Cells: 130152516 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 69 335
SES: 0 0
UAS: 18 18
AS: 795252
Bearer 0
INP: 50.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 9.71
OR: 0.01 26.34
AgR: 35658.62 6322.59
Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01
Bitswap: 538079/538219 2604/2607
Total time = 1 days 4 hours 54 min 30 sec
FEC: 4286622 513
CRC: 97 408
ES: 69 335
SES: 0 0
UAS: 18 18
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 9 min 30 sec
FEC: 12450 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 2989 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 4 hours 54 min 30 sec
FEC: 45116 32
CRC: 1 19
ES: 1 16
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 528306 48
CRC: 10 53
ES: 5 40
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 9 days 4 hours 54 min 11 sec
FEC: 4286622 513
CRC: 97 408
ES: 69 335
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 6188 Kbps, Downstream rate = 33860 Kbps
Bearer: 0, Upstream rate = 6296 Kbps, Downstream rate = 35580 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205)
DS: (33,859) (1216,1961)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 6188 kbps 33860 kbps
Actual Aggregate Tx Power: 0.1 dBm 11.2 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 7.8 42.6 N/A N/A N/A 19.4 52.3 80.4
Signal Attenuation(dB): 7.8 42.0 N/A N/A N/A 21.7 51.9 N/A
SNR Margin(dB): 5.8 5.8 N/A N/A N/A 5.4 5.6 N/A
TX Power(dBm): -11.1 -0.2 N/A N/A N/A 8.6 7.8 N/A
#
[Moderator edited in an attempt to fix a mishap with the [code][/code] tags.]
-
I did a modem re-sync as the DS SNRm was at it's lowest point the sync rate is showing 34015 Kbps and the IP profile shows as 31.23
31230/34014 * 100 = 91.81% it seems stuck at 91% :shrug2:
-
It was something I had to do and that was to remove the HG612 and use the BrightBox2 as modem and router the sync rate is now 37599 Kbps and the IP profile shows as 34.6 which = 92%
As you can see with the BB2 line stats it's hard to know if G.INP is enabled or not :(
-
Hi NS
I had a look at your stats, theres a couple of things I note - your R/N figure is 4.2% so you are carrying a slightly higher FEC overhead, but nothing of much concern.
The other thing I note is this figure for Bearer 1
D: 1 0
Most of the other lines Ive seen have interleaved depth of say 3 for the downstream DTU. The modems which report 'no interleave' on the DTU are the the ECI modems, for which the usual calculation also doesnt apply.
I therefore suspect its something in your overhead framing which upsets the usual rules. wombat knows far more than me when it comes to trying to find a relationship between those figures, both of us are interested in finding out what that relationship is, but so far havent been able to. :(
As you can see with the BB2 line stats it's hard to know if G.INP is enabled or not
The BB2 is g.inp compatible, so you should assume it is on.
-
Thanks I appreciate your reply was starting to wonder if this line was just a one off but there must be others seeing the same IP results as I do.
The BB2 is giving me a sync rate of 38000 kbps with a higher SNRm over 24 hours than the HG612 ever did the IP profile is now at 34.9. but then it uses the BCM63168 chipset and my Unlocked HG612 is using the BCM6368 chipset that must be like 4 years old now.
-
My god I am getting a sync rate of 39.6Mbps with this BCM63168 and the DS SNRM is at 6.5dB
-
My god I am getting a sync rate of 39.6Mbps with this BCM63168 and the DS SNRM is at 6.5dB
I get quite a lot more (~3Mbps pre g.inp) with my Zyxel VMG8324 which also uses a BCM63168.
Since g.inp my max attainable has increased by another ~1.5 Mbps but I havent done a direct g.inp comparison between the 2.
-
I get quite a lot more (~3Mbps pre g.inp) with my Zyxel VMG8324 which also uses a BCM63168.
Just never thought the BCM63168 would make so much of a difference on a long line but after 2 days it's very impressive all i need now is to see the stats on DSLstats ::)
-
all i need now is to see the stats on DSLstats
iirc it doesnt have telnet access. Without being able to telnet into the router, then things like DSLstats/HG612 modemstats aren't able to get any info.
-
DS sync rate to-day 39625 Kbps SNRm 7.2dB but will drop to 6.0dB in the evening the IP Profile is 36.5 = 92.1%.
Can I be the only person in the UK who's IP profile is capped at 92% instead of the normal 96%
would like to see other members ratio's for comparison the more the better
IPprofile / current DS sync rate * 100 for example 36500/39625 X 100 = 92.11
Cheers
-
IP Profile is a BT thing
-
IP Profile is a BT thing
True but every VDSL2 circuit is part of the Openreach product sold to the CP/ISP.
And Openreach is definitely a BT thing! ;)
-
Mine is 49570/51272 * 100 = 96.68044
-
IP Profile is a BT thing
True but every VDSL2 circuit is part of the Openreach product sold to the CP/ISP.
And Openreach is definitely a BT thing! ;)
A Sky connection doesn't have an IP Profile as it's a BT thing not an Openreach thing.
-
A Sky connection doesn't have an IP Profile as it's a BT thing not an Openreach thing.
Are you saying Sky & Talktalk don't follow the same IP Profile rule of 96% as BTWholesale
-
Yes. I thought everyone knew that.
-
Yes. I thought everyone knew that.
I never knew that Dray :no:
So when your DS sync rate is showing 60000 kbps your throughput is also showing as 60000 kbps
-
That would be they day. I'm sure there's some overheads but possibly different to 96% - like yourself. Perhaps you're on the old Orange network?
-
That would be they day. I'm sure there's some overheads but possibly different to 96% - like yourself. Perhaps you're on the old Orange network?
It's not an extract science but if you could post your current DS sync rate and then do a few speedtests and then get and average we could work out your IP Profile for SKY
-
Sky doesn't have an IP Profile though
It uses MER not PPPOE so I think the framing parameters etc. will be different.
-
Sky doesn't have an IP Profile though
It uses MER not PPPOE so I think the framing parameters etc. will be different.
Don't worry just post your sync rate and throughput results ! it's like getting blood out of a stone :D
-
Sync 60.00
T/P 57.71
-
Cheers Dray I used your 57.71 X 1.033 = 59614 so 57710/59613 X 100 = 96.80%
see that was not so bad and thanks
-
Cheers Dray I used your 57.71 X 1.033 = 59614 so 57710/59613 X 100 = 96.80%
see that was not so bad and thanks
What does 1.033 represent?
Because 1/1.033 X 100 = 96.80% ::)
-
1.033 is the reciprocal of 0.968054211 ;)
I can see what N*Star is doing but I'm not sure why! :D
-
Nor me
-
Cheers Dray I used your 57.71 X 1.033 = 59614 so 57710/59613 X 100 = 96.80%
see that was not so bad and thanks
What does 1.033 represent?
It it a computation to calculate the IP profile and then convert this to the actual sync rate - you would need to ask BaldEagle1 what 1.033 stands for but as you can see it works
http://forum.kitz.co.uk/index.php/topic,13114.msg247507.html#msg247507 (http://forum.kitz.co.uk/index.php/topic,13114.msg247507.html#msg247507)
-
All you've shown is that 1/1.033 x 100=96.8%
-
All you've shown is that 1/1.033 x 100=96.8%
You seem to have an IP profile of 96%
I am still waiting on others to respond with there ratio's if you could hang back from posting until I get some more IP ratio's we shall discuss this in a later time.
-
No I don't. The number 59614 is meaningless.
-
No I don't. The number 59614 is meaningless.
Dray even if I take your throughput of 57.71 as the IP Profile and your sync rate is 60000
57710/60000 x 100 = 96.18% the number 59614 is something the calculator came up with.
-
Lets assume I said my thruput was 99
99 X 1.033 = 102.267 so 99/102.267 x 100 = 96.80%
It works with any number.
-
Lets assume I said my thruput was 99
99 X 1.033 = 102.267 so 99/102.267 x 100 = 96.80%
It works with any number.
Forget the IP profile X 1.033 stuff this was a way to covert a known IP profile into it's sync rate, hope your not being pedantic on me ;)
-
A Sky connection doesn't have an IP Profile as it's a BT thing not an Openreach thing.
Are you saying Sky & Talktalk don't follow the same IP Profile rule of 96% as BTWholesale
they also have less overhaeads for not using pppoe
-
I'm back, and have proper access to stats, so will take a look at @NS's stats with a bit more rigour later. This thread has moved on somewhat, so there's a lot to catch up on.
In the meantime, can I just point out that:
a) "IP profile" is a term used by BT wholesale that is used to distinguish between the raw throughput of a line, from the encapsulated "IP date" rate carried in amongst the framing overhead.
b) Framing overhead represents the overhead bytes that surround the IP packets when sent across VDSL2; Some are visible and subtracted from the sync speed (such as the PPPoE framing bytes), while some are less visible, and subtracted before the sync speed is calculated (such as the FEC overhead); My work before the holiday was to figure where the framing overheads for the G.INP DPUs fell within this.
All ISP's (including BT Wholesale) encounter some form of framing overhead, of both types, across the Openreach FTTC product - it is inescapable. Dray's number show that an overhead exists for Sky as much as anyone else.
However, it remains only BT Wholesale that give this overhead a name - IP profile - and then sets rules about what the ISP must do with that information.
Perhaps both Sky and TT have a name, and rules, but they aren't publicised.
-
I see in SIN 498 a singular reference to VDSL2 net data rate and I wonder if this is what BT refers to as the IP Profile?
Note: Where the modem is an integrated device with PPP and/or DHCP functionality, it is recommended that change in state of the VDSL2 physical layer also triggers change of state of PPP/DHCP state. For example, on transition to “showtime” this should re-initialise the PPP session and/or force DHCP to renew. This will ensure the BRAS is informed of the new VDSL2 net data rate via the Intermediate Agent
-
Net Data Rate, or Actual Net Data Rate (for clarity alongside Attainable Net Data Rate) is the more technical term for what is commonly called "sync speed". It's "net" in the sense that the FEC overheads aren't included in the figure.
-
That's interesting. So the BRAS is told the sync speed. I wonder where and how is the IP Profile is calculated?
-
I'm back, and have proper access to stats, so will take a look at @NS's stats with a bit more rigour later. This thread has moved on somewhat, so there's a lot to catch up on.
In the meantime, can I just point out that:
a) "IP profile" is a term used by BT wholesale that is used to distinguish between the raw throughput of a line, from the encapsulated "IP date" rate carried in amongst the framing overhead.
b) Framing overhead represents the overhead bytes that surround the IP packets when sent across VDSL2; Some are visible and subtracted from the sync speed (such as the PPPoE framing bytes), while some are less visible, and subtracted before the sync speed is calculated (such as the FEC overhead); My work before the holiday was to figure where the framing overheads for the G.INP DPUs fell within this.
All ISP's (including BT Wholesale) encounter some form of framing overhead, of both types, across the Openreach FTTC product - it is inescapable. Dray's number show that an overhead exists for Sky as much as anyone else.
However, it remains only BT Wholesale that give this overhead a name - IP profile - and then sets rules about what the ISP must do with that information.
Perhaps both Sky and TT have a name, and rules, but they aren't publicised.
There is overhead's, but the protocol sky use has smaller overheads, is nothing to dispute really just plain fact.
The IP profile is something artificially implemented by BT wholesale to rate limit traffic to each line as it is something BT have long believed necessary on their services. It is separate to the natural overhead of the connection protocol which is PPPoE for BTw based FTTC services.
-
Chry could you do a speedtest/throughput test and use the formula to calculate your ratio
IP profile/throughput / sync rate X 100 =
Please
-
using which speedtester?
I have no ip profile as I am not on the BTw network.
But I will do your request if I understand it properly.
--edit--
Ok newt i assumed you meant the BTw tester, I was surprised I am able to run it, however it seems to be broken as it reports what I am attaching.
Sync speed is 72089
-
I recommend downloading a large enough file so that the download takes a few minutes, while making sure that the download is running at maximum speed. Then with the file size, time taken, and your MTU, we could factor in the overheads for the TCP and IP layers to get a value comparable to the BTw IP profile.
-
Ok newt i assumed you meant the BTw tester, I was surprised I am able to run it, however it seems to be broken as it reports what I am attaching.
Sync speed is 72089
>:D Nope just do a speedtest no need to go to the BTw tester web site there are plenty of them to get your throughput speed, if your your not sure how to do this I will guide your hand :P
-
A speedtest isnt going to give a 100% accurate throughput information, tho there will be variables but regardless here it is. Note i have downstream and upstream QoS active on my router which I am not prepared to disable right now.
So no idea what you doing :) but will provide the data you want.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F5227474242.png&hash=3d7d2f3f334e96eee2daf6a42799a53692cc4594) (http://www.speedtest.net/my-result/5227474242)
sync speed is still same as before.
Ok so this is just an experiment to try and compare overheads?
-
ok here you go, I effectively disabled downstream policing by raising its limits to very high levels, but upload was still under QoS.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F5227488703.png&hash=ee0503f6426de5d47c1a47df177acea0c32a2d04) (http://www.speedtest.net/my-result/5227488703)
du meter hit 8.4 (at max 79999 sync on BTw it used to hit 9.3).
-
ok here you go, I effectively disabled downstream policing by raising its limits to very high levels, but upload was still under QoS.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F5227488703.png&hash=ee0503f6426de5d47c1a47df177acea0c32a2d04) (http://www.speedtest.net/my-result/5227488703)
du meter hit 8.4 (at max 79999 sync on BTw it used to hit 9.3).
Thanks I'll take the higher throughput reading of 67920 Kbps
67920 / 72089 X 100 = 94.21% a we bit shy of 96% by 2%
And thanks again for doing this :)
-
tests indicate overall overheads are very very close, actually maybe slightly favouring BTw.
My comment regarding overheads earlier was PPPoE vs MER.
The issue I have with this is that speedtesting is only a guideline not a accurate science and I didnt do the same test on a BTw isp, so we dont have the same hardware in the tests. (This is why I mentioned du meter as that is software I had installed in both cases).
-
My feeling those ratio's will start to drop off once the Exchange has reached it's limit with broadband users the next stage is to reduce the throughput slightly for each user a way to alleviate congestion at the exchange.
It may even come under the contention ratio rule but this time it's not the ISP it's the Exchange which may need upgrading because of over demand.
This is all hypothetical of course
-
I'm back, and have proper access to stats, so will take a look at @NS's stats with a bit more rigour later. This thread has moved on somewhat, so there's a lot to catch up on.
Ho him. @ns switched to a different modem, so no longer appears in the drop down list of users - I can't see any graphs at all.
No matter ... I work best from the raw stats. I just need @ns to post exemplars from different periods, alongside the IP profiles that applied at the time. Sorry for the hassle :-[
-
The IP profile is something artificially implemented by BT wholesale to rate limit traffic to each line as it is something BT have long believed necessary on their services. It is separate to the natural overhead of the connection protocol which is PPPoE for BTw based FTTC services.
That was true in the days of ADSLmax, with the stepped nature of the IP profile, exacerbated by the slow restoration time - both aspects were indeed artificial. And delays incurred within Plusnet will have further exacerbated problems.
But the artificialness went away with the immediate updates in both 21CN and FTTC, with the values reflecting real overheads.
Unfortunately, delays still occur within Plusnet, making issues appear there still. Added to the fact that they (appear to) leave room for their QoS prioritisation work.
But, overall, the modern IP Profile is no longer the artificial tool it once was.
After all, your line can indeed only cope with a certain rate. If more data has to be sent, it can only ever be handled in one of two ways - queued (causing bufferbloat and jitter) or dropped (the right answer, for TCP).
-
Thanks I'll take the higher throughput reading of 67920 Kbps
67920 / 72089 X 100 = 94.21% a we bit shy of 96% by 2%
This is why I thought about factoring in the TCP and IP layer overheads, to get a value comparable to the IP Profile. I wouldn't expect a speedtest result to be exactly on the IP Profile value. Assuming a MTU of 1492 and the usual 20 byte TCP and 20 byte IP header:
67920/72089 × 1492/1452 × 100 = 96.81%
-
My feeling those ratio's will start to drop off once the Exchange has reached it's limit with broadband users the next stage is to reduce the throughput slightly for each user a way to alleviate congestion at the exchange.
It may even come under the contention ratio rule but this time it's not the ISP it's the Exchange which may need upgrading because of over demand.
This is all hypothetical of course
Were you thinking of the IP Profile being deliberately reduced if the exchange is congested? I don't think that's likely to happen. SIN 498 does mention downstream prioritisation rates, of 30 and 15 Mb, for the up to 80 and 40 Mb products respectively, or your line speed if it's lower than the downstream prioritisation rate. I thought all ISPs and the broadband infrastructure in general tends to rely on not everyone using their full line speed at the same time. However, I do think that as people's line speeds get faster, it'll become more likely that people won't always get the full e.g. 330 Mbps at all times, and it won't be considered a fault so long as it's above some other, lower speed.
-
For G.Fast at 330mbps, didn't they say for every line there will be 80mbps of back haul?
-
I don't know about the back haul (to where?). BT STIN 518 does mention 80 Mbps as this "downstream prioritisation rate". Reading a little further into that STIN, the downstream prioritisation rate sounds like it works by allocating everyone 80Mb each that's prioritised above every line's next 250Mb, but I don't think it implies a dedicated 80Mb for each line.
-
Thanks ejs tbh I am grasping at straws here my line used to show the 96.8% ratio that was three years ago and have not bothered to check it until a few weeks ago and it's now either 91.1% - 92.6% depending on the sync rate 33000 - 39000 Kbps.
I am not to bothered with the loss of throughput 2-4Mbps just trying to find out the reason why this could have happened as most users on FTTC it's 96.8%
-
That's interesting. So the BRAS is told the sync speed. I wonder where and how is the IP Profile is calculated?
Hmm . . . I think you will find some relevant information on a page of the main site --
- http://www.kitz.co.uk/adsl/IPprofile.htm#RAP
- http://www.kitz.co.uk/adsl/IPprofile.htm#IP_profile_calculated
Granted that was written in the era of 20CN technology but I am fairly certain that the overall concept is still correct.
-
Do you think I have a stuck bRAS ?
If you suspect a stuck bRAS on your line then you will have to contact your ISP asking them to get BTw to clear a stuck bRAS profile fault.
-
Ho him. @ns switched to a different modem, so no longer appears in the drop down list of users - I can't see any graphs at all. :-[
Use the Range option, that lists all users who have uploaded in the past three months rather than in past 48 hours.
-
Sorry I have been moving between modems to see if the ratio would go back to 96.8% but no luck
I am fairly certain this happened two years ago when looking at speedstest results it was always way lower than expected from the current sync rate.
Just thought this was normal for my line.
-
There seems to be a suggestion that MTU is involved in the calculation somehow
-
There seems to be a suggestion that MTU is involved in the calculation somehow
It would be nice if someone could explain the MTU in words we can understand and do that in layman's terms unless it's all cut & paste stuff and they don't even understand without having to use google ;)
-
Ho him. @ns switched to a different modem, so no longer appears in the drop down list of users - I can't see any graphs at all. :-[
Use the Range option, that lists all users who have uploaded in the past three months rather than in past 48 hours.
I'll go check that shortly, ta.
-
Hi
I'm not sure if this explains easily to layman terms but
MTU. Is maximum transmission unit
Now to try to explain it in layman terms, look at it like currency conversion for monies for holiday
You have 100 pound sterling and need euro for holiday, a bank converting the money would not give you the 100% value, so you might only get 96% of value, which this analogy translate to your MTU, and the overhead of connections (ppp etc...) say your MTU IS 1492, but including overhead is 1500, then it reduces your 1492 accordingly
I hope that makes sense as I'm tired but could be wrong or give bad analogy
Many thanks
John
-
That's interesting. So the BRAS is told the sync speed. I wonder where and how is the IP Profile is calculated?
Hmm . . . I think you will find some relevant information on a page of the main site --
- http://www.kitz.co.uk/adsl/IPprofile.htm#RAP
- http://www.kitz.co.uk/adsl/IPprofile.htm#IP_profile_calculated
Granted that was written in the era of 20CN technology but I am fairly certain that the overall concept is still correct.
Can you humour me briefly, and confirm exactly how the FTTC IP profile calculation is formulated? What is it that makes 96.8% an appropriate adjustment?
The recent mentions of MTU is making me think...
-
Can you humour me briefly, and confirm exactly how the FTTC IP profile calculation is formulated? What is it that makes 96.8% an appropriate adjustment?
I can only say that it is based entirely upon empirical observations made by one with a very sharp beak (http://forum.kitz.co.uk/index.php?topic=10514.0).
The recent mentions of MTU is making me think...
If you could help to expand the collective knowledge by means of erudite thought experiments and observations, it would be greatly appreciated.
-
Can you humour me briefly, and confirm exactly how the FTTC IP profile calculation is formulated? What is it that makes 96.8% an appropriate adjustment?
I can only say that it is based entirely upon empirical observations made by one with a very sharp beak (http://forum.kitz.co.uk/index.php?topic=10514.0).
I was hoping someone had worked backwards from the observations to the cause...
I assume the 3.2% comes from around 48 bytes out of around 1500 bytes. Something related to the MTU, or biggest MTU anyway...
The recent mentions of MTU is making me think...
If you could help to expand the collective knowledge by means of erudite thought experiments and observations, it would be greatly appreciated.
The line of thinking hasn't coalesced into full theory, but it goes like this...
- IP profile ratio used to be static. Same percentage for all. All modems, all cabinets. Unvarying.
- With G.INP activation, the ratio isn't just different, but seems to be variable. Sometimes in extremis.
- Right now we don't understand what variation can happen, but perhaps that isn't the first step to take. Perhaps we should just accept that the system can now vary.
- Perhaps the variation isn't caused by G.INP directly.
- Perhaps the activation of G.INP also activates a new DLM version, in which the IP profile calculation is made dynamic.
- In which case, we can open up consideration of @ns's problem beyond the raw IP profile ratio and framing parameters.
If that is a plausible pathway, then perhaps the old IP profile calculation was based on static considerations: worst MTU, and worst overheads. But the new dynamic calculation can happen from actual MTU discovery, and actual overheads.
Then my next question to @ns would be: What's your MTU?
That's the thought experiment. Observations next...
-
I don't think MTU has anything to do with the IP profile. The only reason I asked for the MTU was to factor in the TCP and IP layer overheads for going from a speedtest result to a number comparable to the IP profile figure.
I don't even think that the framing parameters should affect the IP profile percentage. The framing parameters are already taken into account when the modem calculates the net data rate (the "sync speed"). G.INP maybe has something to do with whether the modem reports the sum total speed of bearer 0 plus bearer 1, or only bearer 0.
-
Then my next question to @ns would be: What's your MTU?
That's the thought experiment. Observations next...
The MTU is set at 1492 on the modem and 1492 on the pc.
Was thinking about my variable attainable sync rate as you can see on MDWS it climbs and then dips every 24 hours all year round, could the lowest point on the attainable sync be used as the minimal sync rate.
-
@ejs
As I said, it is a thought experiment that hasn't reached a conclusion yet. But I can't find an answer within the expected boundaries, so I'm widening my thinking beyond what I expect to happen. Just to see if it provides any other insights... I understand why you asked about the MTU, but the mere act of you asking is what triggered this train of thought.
I experimented with changing my MTU in the router, and it didn't change the IP Profile reported by the BTW speedtester. Strike 1, but I'll try again later when the line isn't being used for work. DLM fears make experimentation slow here (take note, Mr Grimsley!)
However, this morning I was reading SIN 498, which had this to say (amongst lots of other stuff):
As a result of these overheads, the actual achievable throughput in bits per second is
dependent on the reported VDSL2 rate and frame size of the data being transmitted.
with an example:
For example, if the reported downstream VDSL2 data rate is 40,000 kbit/s and the IP
packet size is 1500 bytes (i.e. Ethernet frame size at End User LAN is 1514 bytes) the
maximum throughput achievable is actually 39,178 kbit/s (when measured at the EU
LAN i.e. no VLAN header, but including Ethernet header). Alternatively, if the IP
packet size is 64 bytes the maximum throughput achievable is further reduced to 35,721
kbit/s. This overhead is particularly important to consider in respect to the downstream
shaper setting on the CP’s BRAS.
What they call "IP Packet Size" sounds awfully similar to the MTU to me.
There's a lot in there for me to read related to tagging, which may affect throughput rates too - and they draw a reference to the framing used for PTM mode, which I haven't yet found a good reference for.
Then I was looking in the BTW FTTC Handbook (issue 12 is the most recent I've got; I'd love a newer one), which broke down throughput vs frame size even further, and has given me some ideas for further MTU experiments. I've attached a snip of the table.
Even those throughput figures aren't the final "IP-level" ones we need, as they probably include the encapsulation headers for PPP and PPPoE, at the very least. The text alludes to some form of traffic management - which might be as simple as some tags being added for QoS - but I need to figure that out too.
I think I need to read more of the two documents ... and not skip so much of the bits I don't understand :-[
Right now, I think that the packet size is important. You used MTU to figure out the TCP and IP overhead that applies above the application 'goodput', but I think it works in the other direction with some of the tagging being added by Openreach/BTW/ISP too.
-
Then I was looking in the BTW FTTC Handbook (issue 12 is the most recent I've got; I'd love a newer one), . . .
Issue 12, dated 16 September 2014, is also the most recent version that I possess.
-
The other thing I note is this figure for Bearer 1
D: 1 0
Most of the other lines Ive seen have interleaved depth of say 3 for the downstream DTU.
Had a look around and find that users on a 80/20 service with a sync of 70 Mbps will see a depth of 3 for the downstream DTU.
Those on the 40/10 service with a sync of 25-38 Mbps has a depth of 1 for the DTU.
you can also see the same on tbailey2 Bearer 1.
-
Those on the 40/10 service with a sync of 25-38 Mbps has a depth of 1 for the DTU.
you can also see the same on tbailey2 Bearer 1.
I'm on 80/20.... started life at 56/15, now 38.5/4.6
-
I'm on 80/20.... started life at 56/15, now 38.5/4.6
Crikey you would have thought your line was on the 40/10 profile not 80/20 with those stats.
Anyway back to the Bearer 1 DS depth just by looking through some xdslcmd info --stats I can see depth 1 for 40 Mbps and 3 for 80 Mbps users.
-
to show how variable speedtesters are, with flash vs html5, buffer sizes etc. I can report my tbb html5 tester result is 68.91mbit/sec. Same sync speed.
-
I used speed of me test it shows max download of 32Mbps and my sync is 33400 something I am not used to this speedtester could someone give me advice.
http://speedof.me/show.php?img=160423165936-8875.png (http://speedof.me/show.php?img=160423165936-8875.png)