Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 ... 16 17 [18] 19 20

Author Topic: G.INP enabled Stats Comparison  (Read 99627 times)

boost

  • Reg Member
  • ***
  • Posts: 768
Re: G.INP enabled Stats Comparison
« Reply #255 on: April 04, 2015, 09:39:43 PM »

Pretty sure boost is using the latest firmware on his HG after demoting the BH5a to auth n wireless only.

Good luck convincing gamers that interleaved is better than  fastpath :P

It could be argued that gaming packets are so small the connection has be to almost ruined before it's noticeable in game.

Meanwhile, though, your TCP connections might be rewindowing all shapes and YouTube drops to minimal quality.

We don't care. Ping is king!
Logged

loonylion

  • Reg Member
  • ***
  • Posts: 723
Re: G.INP enabled Stats Comparison
« Reply #256 on: April 04, 2015, 09:47:00 PM »

It also depends on what games you're playing. MMORPGs are more tolerant of latency than shooters.
Logged

boost

  • Reg Member
  • ***
  • Posts: 768
Re: G.INP enabled Stats Comparison
« Reply #257 on: April 04, 2015, 10:05:19 PM »

Quite!
It's mostly the FPS crew that whinge about ping :)
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: G.INP enabled Stats Comparison
« Reply #258 on: April 04, 2015, 10:26:46 PM »

Pretty sure boost is using the latest firmware on his HG after demoting the BH5a to auth n wireless only.

Good luck convincing gamers that interleaved is better than  fastpath :P

Boost we are not trying to convince you that G.INP makes the game experience better or worse all I am saying is that it makes your line more stable as errored seconds are lower and the amount of people that complain i've been moved off fastpath and am now interleaved was due to end-users going above their daily errored second quota.

If you are using DSLstats to upload your data to MDWS you can use the stats tab to show your modem/firmware: version.
Logged

boost

  • Reg Member
  • ***
  • Posts: 768
Re: G.INP enabled Stats Comparison
« Reply #259 on: April 04, 2015, 11:07:53 PM »

I'm not against g.inp :D

Is it starting to get a little silly here, though? It seems like no one can get away with posting their valid concerns about latency ramp without someone chiming in about how 10ms~ doesn't really matter or how wonderful error correction is :)

When longstanding members adopt a dismissive attitude on certain topics there is a risk that valid technical issues get lost in the mire of p00 we already have to put up with from BT, lol.

When someone asks for help we should probably try and provide real help instead of convincing everyone there isn't really a problem :P

Hopefully, I'm not too guilty of this myself but please pick me up on it if I'm being silly :)
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: G.INP enabled Stats Comparison
« Reply #260 on: April 04, 2015, 11:14:10 PM »

When someone asks for help we should probably try and provide real help instead of convincing everyone there isn't really a problem :P

I am up for that  :)
Logged

lockeh

  • Member
  • **
  • Posts: 21
Re: G.INP enabled Stats Comparison
« Reply #261 on: April 05, 2015, 09:56:25 AM »

Quote
moved off fastpath and am now interleaved was due to end-users going above their daily errored second quota.

Wrong. I have had a perfect 3 year service on fasthpath, my line has NEVER dropped and got 0% pl and the only thing that has ruined my line IS G.INP

My error seconds was 0 before and 0 after..
« Last Edit: April 05, 2015, 05:38:49 PM by lockeh »
Logged

BritBrat

  • Kitizen
  • ****
  • Posts: 1359
Re: G.INP enabled Stats Comparison
« Reply #262 on: April 05, 2015, 10:22:02 AM »

I have been getting help to monitor my connection again from roseway, thanks.

Now having flashed the HG612 to latest firmware I now seem to be  able to monitor the stats again so below is my stats:

Code: [Select]

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 8169 Kbps, Downstream rate = 52832 Kbps
Bearer: 0, Upstream rate = 9997 Kbps, Downstream rate = 53998 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.9 4.1
Attn(dB): 22.3 0.0
Pwr(dBm): 12.2 5.9
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 243 227
M: 1 1
T: 0 0
R: 10 16
S: 0.1439 0.7254
L: 14122 2691
D: 8 4
I: 254 244
N: 254 244
Q: 8 4
V: 0 0
RxQueue: 42 16
TxQueue: 14 8
G.INP Framing: 18 18
G.INP lookback: 14 8
RRC bits: 24 24
Bearer 1
MSGc: 122 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 8.0000 16.0000
L: 32 16
D: 1 1
I: 32 32
N: 32 32
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 0
OHFErr: 2 0
RS: 375653472 2361207
RSCorr: 4275944 9905
RSUnCorr: 0 0
Bearer 1
OHF: 10500855 56429
OHFErr: 0 0
RS: 84006350 3514053
RSCorr: 85 25
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 40636 36
rtx_c: 4375 321
rtx_uc: 3 0

G.INP Counters
LEFTRS: 78 23
minEFTR: 53987 9994
errFreeBits: 138878331 106508342

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 334868363 0
Data Cells: 463237793 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: 2 0
SES: 0 0
UAS: 44 44
AS: 168676

Bearer 0
INP: 47.00 43.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 54052.91 10019.02

Bearer 1
INP: 2.00 4.00
INPRein: 2.00 4.00
delay: 0 0
PER: 16.06 16.06
OR: 63.75 31.87
AgR: 63.75 31.87

Bitswap: 126122/126122 626/627

Total time = 1 days 22 hours 52 min 0 sec
FEC: 4275944 9905
CRC: 2 0
ES: 2 0
SES: 0 0
UAS: 44 44
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 7 min 0 sec
FEC: 148 9521
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: 224 3
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 = 22 hours 52 min 0 sec
FEC: 3724437 9642
CRC: 2 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 551507 263
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 44 44
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 days 22 hours 51 min 15 sec
FEC: 4275944 9905
CRC: 2 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#



Code: [Select]

Stats recorded 05 Apr 2015 10:21:42

DSLAM/MSAN type:        BDCM:0xa44f / v0xa44f
Modem/router firmware:  AnnexA version - A2pv6C038m.d24j
DSL mode:                VDSL2 Profile 17a
Status:                  Showtime
Uptime:                  1 day 22 hours 52 min 15 sec
Resyncs:                0 (since 05 Apr 2015 09:06:35)

Downstream Upstream
Line attenuation (dB):  22.3 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 53998 9997
SNR margin (dB):        5.9 4.8
Power (dBm):            12.2 5.9
Interleave depth:        8 4
INP:                    47.00 43.00
G.INP:                  Enabled

RSCorr/RS (%):          1.1333 0.4708
RSUnCorr/RS (%):        0.0000 0.0000
ES/hour: 
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7415
  • VM Gig1 - AAISP CF
Re: G.INP enabled Stats Comparison
« Reply #263 on: April 05, 2015, 11:23:40 AM »

I'm not against g.inp :D

Is it starting to get a little silly here, though? It seems like no one can get away with posting their valid concerns about latency ramp without someone chiming in about how 10ms~ doesn't really matter or how wonderful error correction is :)

When longstanding members adopt a dismissive attitude on certain topics there is a risk that valid technical issues get lost in the mire of p00 we already have to put up with from BT, lol.

When someone asks for help we should probably try and provide real help instead of convincing everyone there isn't really a problem :P

Hopefully, I'm not too guilty of this myself but please pick me up on it if I'm being silly :)

if people are seeing a sudden jump of latency whilst the modem has NOT resynced, after been put on g.inp my input is its a bug in the implementation.

g.inp is supposed to have dynamic latency but not in this way, my guess is the bump of latency occurs when it first has to increase by such amount and then for whatever reason doesnt decrease again when it is supposed to.

SRA had similar bugs on some devices where by it would adjust the SNR and then the SNR would become "stuck" at which point until a new resync was done it would act like SRA was off.

I suspect this is a bug basically.

rizla's input here might be useful as he seems to know a lot about sky's g.inp implementation, so it be useful to know if sky LLU users have the same issues (I think they dont).

IF I am right then in theory if someone initiates a new resync then latency should recover.
« Last Edit: April 05, 2015, 11:26:52 AM by Chrysalis »
Logged

boost

  • Reg Member
  • ***
  • Posts: 768
Re: G.INP enabled Stats Comparison
« Reply #264 on: April 05, 2015, 12:29:37 PM »

Both bug and bodge make a lot of sense, especially if the wonderful DLM is parsing error stats in a particular way.
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: G.INP enabled Stats Comparison
« Reply #265 on: April 05, 2015, 12:54:14 PM »

It varied, when I first had G.inp enabled it increased by 3ms then it increase by about 12ms and reduced sync with ECI modem, I installed the HG612 and in deceased slightly. Had a BT engineer out had the port reset abut wouldn't stick and interleave wouldn't budge and needed someone at BT OR HQ to fix the interleave on up and down. I had 9ms ping to BBC again for a few days and then G.INP reapplied with and same again.

Which of these figures are measured? Preferably by something running all the time, such as a TBB BQM or f8lure?

I'm concerned about whether you have taken latency figures from modem stats, rather than from observed behaviour. For example, in one previous post, you interpret a setting of "INP=4, delay=3" as having actually put 3ms delay on the line. Unfortunately, those stats were for bearer 1 - which isn't the main data channel. Bearer 0, which *is* the main data channel, had "INP=0, delay=0" - so no added latency for the vast majority of your data.

Quote
I wonder if having ECI connected when G.INP got applied caused a higher state of interleave?

Have you read any of the other posts around here? It looks like there is a BIG problem with ECI modems and G.INP right now, and there are a lot of mixed opinions swirling around forums.

Here are my opinions ...

It looks like some (at least) ECI modems have failed to upgrade to G.INP-compatible firmware; when G.INP attempts to go active, the result is indeed slower speeds and higher latency. A DLM reset fails to fix this. No surprise really, as the DLM reset was only meant as a temporary way to regain sync, to give breathing space to allow the firmware upgrade to happen.

(NB: Openreach expected ECI modems with incompatible firmware to *look* like they had synced, but to have actually failed to sync. It doesn't look like it has turned out this way)

Unfortunately, ECI modems are locked, so no-one can confirm this is what has happened. This adds to the general confusion.

People with unlocked Huawei modems, but left on incompatible firmware, report the same behaviour. When they upgrade themselves to compatible firmware, speeds and latency return to normal (with G.INP active).

I suspect, therefore, that your ECI modem is one of those suffering such a problem.

The obvious next question is - how many of your observed changes to latency can be explained by a duff ECI modem? And how many can't be explained this way?
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: G.INP enabled Stats Comparison
« Reply #266 on: April 05, 2015, 01:00:54 PM »

Is it starting to get a little silly here, though? It seems like no one can get away with posting their valid concerns about latency ramp without someone chiming in about how 10ms~ doesn't really matter or how wonderful error correction is :)

I agree, it is hard to remain objective on this issue.

However, we are currently undergoing a sea change in the way in which error-mitigation works on our DSL lines, and it isn't always clear that other people understand that. A visceral hatred of interleaving can come from how interleaving behaved in the past, without understanding how it will work in the future.

None of which is helped by having modem failures, like we seem to be seeing.

Quote
When someone asks for help we should probably try and provide real help instead of convincing everyone there isn't really a problem :P

I find my first step tends to be to make sure someone understands that what they are complaining about has changed utterly. I think it is important to make sure they are not just complaining about a label.

It probably comes over like I'm trying to convince them there isn't a problem, I agree.
Logged

lockeh

  • Member
  • **
  • Posts: 21
Re: G.INP enabled Stats Comparison
« Reply #267 on: April 05, 2015, 05:44:30 PM »

Bearer 1 does have a say in latency

         Bearer 1
INP:      4.00      4.00
INPRein:   4.00      4.00
delay:      3      0
PER:      16.06      16.06
OR:      95.62      31.87
AgR:      95.62   31.87


The delay setting 3 does add 3ms.

Read adslmax post as he had delay set to 3 and it was removed for some reason and is now set at 0 and his ping did drop by 3ms backed up by thinkBB graph. 
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: G.INP enabled Stats Comparison
« Reply #268 on: April 06, 2015, 11:22:52 AM »

Again, I point you back to understanding what bearer 0 and bearer 1 are for.

Bearer 1 does have a say in latency

         Bearer 1
INP:      4.00      4.00
INPRein:   4.00      4.00
delay:      3      0
PER:      16.06      16.06
OR:      95.62      31.87
AgR:      95.62   31.87

Look at the bottom line of this: The "AgR" line - or aggregate rate.

Bearer 1 carries 95Kbps. Compare that to bearer 0, which carries 80,614Kbps (at least it does on my 80/20 line).
  • Quote
                            Bearer 0
    INP:            46.00           47.00
    INPRein:        0.00            0.00
    delay:          0               0
    PER:            0.00            0.00
    OR:             0.01            0.01
    AgR:            80614.82        20102.08

Which do you think is carrying the main stream of data?

Another clue comes from the OR data (Overhead Rate). It seems that bearer 0 has almost no overhead, but bearer 1 is entirely overhead.

The final giveaway comes from reading G.998.4 - the G.INP specification - section 9, combined with the annex that applies to VDSL2. The spec uses different numbering, but it puts the user data into bearer 0, protected by retransmission. And it puts the "overhead channel" (which sends management data back and forth) into bearer 1, protected by FEC and interleaving.

Result: 0ms delay to user data. 3ms to the overhead channel, sending management data back and forth between the modems.

Quote
Read adslmax post as he had delay set to 3 and it was removed for some reason and is now set at 0 and his ping did drop by 3ms backed up by thinkBB graph. 

With the best will in the world, I wouldn't put Max down as the most stringent observer of experimental behaviour.

Max and I have one thing in common... we both use Plusnet. It is observed behaviour for Plusnet connections to change gateway at each resync. It is also observed behaviour for latency to alter within 1-2ms on different gateways, and I suspect that one gateway is even worse.

With a natural tendency to not want to switch too often, it makes it hard to confirm whether small latency changes come from landing on a slower/faster gateway, or from a change in modem settings. Distinguishing one from the other takes time, and careful observation. No jumping to conclusions.

So lets swap to an experimental investigator I trust a little more. One who makes more careful observations, and is less prone to rush to judgement...

So far, I have seen a max of 1ms of variation in my end-end ping times since G.INP activation, having swapped through 3 different gateways. Attached is my BQM of the day G.INP activated (snipped, to fit to the Kitz size requirement); you see a tiny increase when G.INP activates at 06:30; a slight decrease after a resync at 19:15; a slight increase at 22:15. All 3 resyncs resulted in the same configuration of both bearer 0 and bearer 1 as I mention earlier.

Yet I had the same exact configuration - 3ms "delay" in bearer 1, only downstream, alongside INP of 4 and INPrein of 4 in both directions - introduced at 06:30, and left in place at each of the other resyncs.

So what scale are those changes? Zoomed in, I can see that 20ms on the scale is represented by 28 pixels - so a pixel is approximately 0.7ms. The visible changes in the graph happen at the scale of 1 pixel, less than 1ms.

You certainly don't see 3ms extra latency switch into effect in any of my test results - either this BQM, or the previous graphs. What you see are the kind of changes I'd expect by swapping gateways at Plusnet.
Logged

jelv

  • Helpful
  • Kitizen
  • *
  • Posts: 2054
Re: G.INP enabled Stats Comparison
« Reply #269 on: April 06, 2015, 12:06:20 PM »

Does anyone know if new cabinets are being installed with G.INP enabled? My installation is due on 14th (I ordered on the first day it was accepting orders). The cabinet looks like a Huawei 288.
Logged
Broadband and Line rental: Zen Unlimited Fibre 2, Mobile: Vodaphone
Router: Fritz!Box 7530
Pages: 1 ... 16 17 [18] 19 20