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 [2] 3 4 ... 6

Author Topic: Stats  (Read 5385 times)

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 5515
Re: Stats
« Reply #15 on: April 20, 2018, 12:50:24 AM »

I got the fast path status from this line

D 1 1
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab - LINE STATISTICS CLICK HERE

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 24615
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Stats
« Reply #16 on: April 20, 2018, 01:13:25 AM »

I should go on to say that there's a chance restarting a modem may not be treated the same as a link drop because of something to do with a "dying gasp" ... perhaps b*cat or some other experienced person could confirm.

The "dying gasp" concept is a quite simple process. It is not an absolute requirement but almost all modem manufacturers do follow the recommendation. When the processor senses that its power has been lost (and is essentially operating off the energy stored in the smoothing capacitors of the power supply circuitry) it stops all normal activity and sends a loss-of-power message to its upstream peer (at the highest, emergency, priority). Upstream, the DSLAM or MSAN will note the loss-of-power message and will then not increment its error counters.

The important rule is to remember to power off the modem before disconnecting the xDSL patch lead. It is worthwhile following that rule, regardless of the type of service being received.

However with the current FTTC service, making use of a G.993.2 link over a metallic pathway, the DLM process does not consider the DSLAM's non-incrementing error counters when deciding whether to intervene and what action to take!  :doh:
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

re0

  • Reg Member
  • ***
  • Posts: 401
Re: Stats
« Reply #17 on: April 20, 2018, 09:42:38 AM »

I got the fast path status from this line

D 1 1

D'oh. :doh: I blame the alcohol content for missing that. :drunk: :P Back to the apple juice this morning, so accuracy and quality posting should ensue.

However with the current FTTC service, making use of a G.993.2 link over a metallic pathway, the DLM process does not consider the DSLAM's non-incrementing error counters when deciding whether to intervene and what action to take!  :doh:

Just so I understand, rather than it being a stupid question with a blatant answer, does the DLM essentially discard the "non-incrementing" error counters?
Logged

sotonsam

  • Reg Member
  • ***
  • Posts: 101
Re: Stats
« Reply #18 on: April 20, 2018, 10:56:30 AM »

Thanks for everyones input on this, I've learnt a lot!

I'll see how things pan out over the coming months in terms of G.Fast, as I said if the increase is likley to be minimal (or non-existant on upstream) then it certainly won't be worth paying the extra $$ it will cost.

If only I could wake up one day to see them building a new cab just over the road from me...(which would still probably take a tour of southampton before landing at my house!)
Logged
AAISP FTTC 80/20. BT Infinity FTTC 80/20. ECI Cab.

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 24615
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Stats
« Reply #19 on: April 20, 2018, 06:35:40 PM »

Just so I understand, rather than it being a stupid question with a blatant answer, does the DLM essentially discard the "non-incrementing" error counters?

My understanding, based on Kitz' analysis of the DLM mode of action, is that it (the DLM process) only takes notice of a small subset of the parameters which a DSLAM/MSAN will collect for each (end-user) circuit.

The actual mode of operation of the DLM process (for GEA G.993.2 based services) has not been publicly disclosed.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

re0

  • Reg Member
  • ***
  • Posts: 401
Re: Stats
« Reply #20 on: April 20, 2018, 09:42:23 PM »

I'll see how things pan out over the coming months in terms of G.Fast, as I said if the increase is likley to be minimal (or non-existant on upstream) then it certainly won't be worth paying the extra $$ it will cost.
BT, for example, offers a lower tier 152 Mbps package with a 100 Mbps download speed guarantee. I am not aware of the complete terms surrounding this and sadly I am not aware of any gaurantee on the upstream. But perhaps it is worth a punt when it becomes available and if it does reveal any inadequacies with your line then perhaps they will "fix" it.

If only I could wake up one day to see them building a new cab just over the road from me...(which would still probably take a tour of southampton before landing at my house!)
Why wish for a new cabinet over the road when you could wish for FTTP? ;)

My understanding, based on Kitz' analysis of the DLM mode of action, is that it (the DLM process) only takes notice of a small subset of the parameters which a DSLAM/MSAN will collect for each (end-user) circuit.

The actual mode of operation of the DLM process (for GEA G.993.2 based services) has not been publicly disclosed.
Well, I was always under the impression that a lot of information on the web in relation to the DLM was based on the little documentation and "experimenting" done by "hobbyists". As per usual, information floating on the web is simply either just guidelines based on what we know (which could be outdated since revisions to underlying systems could have been made without publicly available documentation) or assumptions.
Logged

Browni

  • Reg Member
  • ***
  • Posts: 125
Re: Stats
« Reply #21 on: April 20, 2018, 10:34:43 PM »

Both Ultrafast packages are available to me therefore I can see the small print!

Quote
Ultrafast is the only UK broadband with a 100Mb speed guarantee
Our speed guarantee is our promise that you’ll always get the download speeds you pay for – even at peak times. Ultrafast is also the only UK broadband to give you an upload speed guarantee of 10Mb.

Claim £20 if your broadband’s less than Ultrafast
We want you to feel confident Ultrafast won’t let you down, so we’ll put our money where our mouth is. You can test the speed to your hub in My BT. And claim £20 if it’s slower than it should be (you can make a claim up to four times a year).
Logged

sotonsam

  • Reg Member
  • ***
  • Posts: 101
Re: Stats
« Reply #22 on: April 21, 2018, 10:03:56 AM »

BT, for example, offers a lower tier 152 Mbps package with a 100 Mbps download speed guarantee. I am not aware of the complete terms surrounding this and sadly I am not aware of any gaurantee on the upstream. But perhaps it is worth a punt when it becomes available and if it does reveal any inadequacies with your line then perhaps they will "fix" it.
Why wish for a new cabinet over the road when you could wish for FTTP? ;)
Well, I was always under the impression that a lot of information on the web in relation to the DLM was based on the little documentation and "experimenting" done by "hobbyists". As per usual, information floating on the web is simply either just guidelines based on what we know (which could be outdated since revisions to underlying systems could have been made without publicly available documentation) or assumptions.

I could wish for FTTP....but I can't imagine there's any chance of that here - well not within the next 5/6 years anyway. I was watching a Video the other day, a bloke was getting quite irate at how 'cheap' it could be for BTO to string fibre cables along the same route as your phone line (over the poles etc) rather than messing around with G.fast. Not sure BT would agree with that, but apparently lots of other European companies deploy FTTP in that way.
Logged
AAISP FTTC 80/20. BT Infinity FTTC 80/20. ECI Cab.

sotonsam

  • Reg Member
  • ***
  • Posts: 101
Re: Stats
« Reply #23 on: April 23, 2018, 08:23:00 PM »

My FTTC resynced in the middle of the night last night, and I'm guessing I'm now being impact by DLM for some reason as my latency has shot up by 15ms. I must be honest, this is the highest latency I've ever had on FTTC - it's +20ms now, which is pretty naff for certain things I do.

I note from an above comment that D 1 1 demonstrated that I was on fast path. The new stats now show

D 1165 1 - what does that mean??


Logged
AAISP FTTC 80/20. BT Infinity FTTC 80/20. ECI Cab.

re0

  • Reg Member
  • ***
  • Posts: 401
Re: Stats
« Reply #24 on: April 23, 2018, 08:42:05 PM »

It looks like it has applied interleaving with a depth of 1165 on the downstream. Though, upstream is still fastpath. The increase in latency would be caused by the increase in the delay on the line. But it looks like your downstream has decreased a bit with the increase in interleaving depth.

Perhaps if you have PuTTY or telnet installed on your OS, you could login into the router and then do (without the speech marks):

"sh" (to get into the shell mode)
"adsl info --stats" (to retrieve all stats)

And then, below Bitswap statistics, you should see the error counters total time, latest 15 minutes, etc. Maybe you could copy and paste that here? Furthermore, could you also copy the information for "Bearer 0" which should be just above the Bitswap as this will show delay parameters.

With the error counters, we should be able to hopefully see what the DLM (roughly) classifies your line as (information can be found out regarding the DLM at http://www.kitz.co.uk/adsl/DLM.htm). This should give some insight to why the DLM has actioned changes.

Alternatively, if you do not want to login to the router and go through the steps, as you have HG612_Modem_Stats you could run the HG612_current_stats.exe and get the counters from a little bit down from the top of the Plink_*.log file under the Current_Stats_(date and time) folder.
Logged

sotonsam

  • Reg Member
  • ***
  • Posts: 101
Re: Stats
« Reply #25 on: April 23, 2018, 08:56:47 PM »

Cheers re0 - attached is that said file.

Rather foolishly I did another reboot of the HG612 and it's degraded even further - now on an IP Profile of 57.
Logged
AAISP FTTC 80/20. BT Infinity FTTC 80/20. ECI Cab.

re0

  • Reg Member
  • ***
  • Posts: 401
Re: Stats
« Reply #26 on: April 23, 2018, 09:09:26 PM »

Cheers re0 - attached is that said file.
I only needed the following stats copied from the file:

Code: [Select]
Bearer 0
INP: 3.00 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 1.80 6.15
OR: 106.55 202.87
AgR: 59101.13 20203.27

and

Code: [Select]
Total time = 2 min 41 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 2 min 41 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 0 sec
FEC: 0 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 = 2 min 41 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 2 min 15 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

Though, no biggy that you've included the whole log.

Rather foolishly I did another reboot of the HG612 and it's degraded even further - now on an IP Profile of 57.
That would explain why the counters only go back just under 3 minutes. ::) I can't make much of it until we have more information over the space of a few days to a week at least. :( I would recommend logging your line statistics over the next few days using HG612 Modem Stats (or DSLstats, if you would prefer... both are just as good as each other). Though, the downside is that you would need a machine connected and switched on without powersaving for the duration.

I can confirm that the delay has gone up by only 8 ms at link level from the cabinet; to the cabinet is still fastpath as mentioned (so no delay). If you have had an increase of 15+ ms, then some of it may be contributed by using different servers for testing latency and/or when you established PPP session (after you resynched) your ISP may have routed you differently.
Logged

sotonsam

  • Reg Member
  • ***
  • Posts: 101
Re: Stats
« Reply #27 on: April 23, 2018, 09:12:24 PM »

Sorry about that!

I'll hook a laptop up by the socket and leave it running - would 72 hrs be enough to work from?
Logged
AAISP FTTC 80/20. BT Infinity FTTC 80/20. ECI Cab.

re0

  • Reg Member
  • ***
  • Posts: 401
Re: Stats
« Reply #28 on: April 23, 2018, 09:23:59 PM »

I should note that using HG612 Modem Stats in this occasion is not strictly necessary as we could use the stats logged on the modem. Though, it may serve us better to log using the program in case the modem is powered off (as stats on the modem are not retained after that). Plus, it is probably easier to overlook the stats in this program.

I'll hook a laptop up by the socket and leave it running - would 72 hrs be enough to work from?
It should be enough as we are not necessarily looking for a fault or inconsistency here, but rather just the general error counters in an attempt to classify the line based on the information available. Perhaps you could update the topic here after a day with the counters up until that point?
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 24615
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Stats
« Reply #29 on: April 23, 2018, 09:27:27 PM »

Attached are the four "snapshot" plots, created from that dataset (dated 2018.04.23 20:41:26).
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.
Pages: 1 [2] 3 4 ... 6
 

anything