Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: tiffy on June 17, 2017, 11:19:58 AM
-
Having diligently read through the excellent kitz guide to the BT DLM system (many times) I am still confused regarding the concept of "error sec's. per day" with respect to inputing data to the the line quality calculator in order to establish ILQ (Indicative Line Quality)
Kitz DLM guide states that only ES's & SES's are taken into account so that simplifies things considerably.
I'am on the Plusnet vDSL2 40/2 package, only recently migrated from ADSL2+ with Plusnet.
I am using DSLStats V.5.9.5 (pre-release) on an unlocked Huawei HG612 modem to monitor line stat's., get a constantly updating figure of ES/hr. and the historic hourly graph.
From the "Average Error Rates by Day" page I can see the live ES/hr. figure and also see historic, previous day's figures, in my case I have never had any SES's recorded to date so don't have to worry about that.
So, am I correct in assuming I should take a historic ES/hr. figure X24 (assuming there have not been any re-synch's in that period) as the "total day ES" figure for application to the ILQ calculator ?
I have only been on FTTC for 10 days, the first few days was on the PN Hub One (same as BT HH5a) very limited stat's. available via the dedicated RouterStats utility then changing to an unlocked HG612 modem with my existing Netgear DGND3700v2 modem in order to run DSLStats with much more comprehensive monitoring capabilities.
I initially connected fast path then DS interleaving was applied after a few days, correctly I would say from line error records via DSLStats.
After 4 days of DS interleaving, DLM appeared to act and reverted to fast path, again totally predictable from the DSLStats error records.
I have a relatively good line and synch. at the top end of my IP profile, I would just like to be able to predict the ILQ state of my line and perhaps predict if DLM is likely to re-apply DS interleaving in the near future.
I have monitored this excellent site for many years, fantastic reference source, only just joined up, first post.
-
Sign-up to MDWS > https://www.mydslwebstats.co.uk/mdws-rg.php
Have DslStats upload your data to MDWS
MDWS simplifies ES rates to per day/last 24 hour figures
Red traffic light = DLM will take action
ECI cabinet I assume? Interleaving shouldn't be a problem on Huawei cabinets.
-
j0hn,
Many thanks for the very quick response, much appreciated.
Yes, I an on an Huawei FTTC cabinet, one of the reasons I quickly scrapped the PN Hub One router in favour of the unlocked Huawei HG612 modem, I did get an improvement in DS synch. speed immediatly on changing and of course much better stat's. availability also.
I did notice references to MDWS but never really investigated or appreciated it's capabilities, that's certainly my next project, looks like it does all calculations associated ILQ monitoring and produces direct indications.
Is MDWS run as a complimentary addition to DSLStats or a separate program ?
-
MDWS is a separate system managed by Tony Bailey. DSLstats is simply one of the two monitoring programs which can upload data to the MDWS site, the other being HG612_Modem_Stats.
-
Thanks again to both.
MDWS registered, dues paid, DSLStats activated and data flowing, looks good, hours of fun anticipated !
The only slight reservation I have is the requirement to keep by desktop PC running with DSLStats active in order to provide the constant data uploads for most meaningful results.
Would still like to know what ES/day figure to use for a manual calculation of ILQ status ?
-
MDWS registered, dues paid, DSLStats activated and data flowing, looks good, hours of fun anticipated !
The only slight reservation I have is the requirement to keep by desktop PC running with DSLStats active in order to provide the constant data uploads for most meaningful results.
Some members use a Raspberry-Pi for continuous data collection, by DSLstats, and the uploading of the harvested data to MDWS. Such a system has very low energy consumption and would be quite unobtrusive.
-
Yes, I was aware that there has been a version of the program for Raspberry-Pi for quite a while, I did buy the older "B" model a few years ago to play around with but to be honest just never got the time, I think that has sufficient resources to run the application in question ?
I take it that the Raspberry-Pi would just look after the stat's. data transfer to MDWS with minimal display capabilities and DSLStats would still be used with Windows in my case for more detailed monitoring ?
Either way, sound like a good project for winter when it comes around again, many thanks for the information.
-
I use a pi3. Works a treat. The lan port connects to my modem for stats and the wifi connects to the router. I did edit the network file to use static ips on both connections..
-
. . . I did buy the older "B" model a few years ago to play around with but to be honest just never got the time, I think that has sufficient resources to run the application in question ?
Yes. I own one of the original Type B R-Pi and it certainly has sufficient resources to run DSLstats & upload the data to MDWS.
-
I'm using the older RPi B+ and it runs DSLstats which uploads to MDWS and can either look at MDWS on MS Windows or look at the stats coming from the RPI GUI via DSLstats from a different monitor it has it's own wifi keyboard & mouse and one Lan patch cable from RPI to the Modem/router.
When your in MDWS there is Traffic light status bar here is were check your ILQ status you just click on it of course having a full 24 Hours worth of stats is needed to get the big picture 24/7 is the way to go.
-
When your in MDWS there is Traffic light status bar here is were check your ILQ status you just click on it of course having a full 24 Hours worth of stats is needed to get the big picture 24/7 is the way to go.
It's not the ILQ status as it says if you read the notes. This is just for the basic DLM status, ILQ I think has seven states rather than three. This also displays a rolling 24 hours for a better overview wheres the popup can be set to the current day that DLM uses and also historic views.
-
Yes it does but we only consider GREEN AMBER and RED on MDWS
-
Yes it does but we only consider GREEN AMBER and RED on MDWS
:'( Isn't that what I just said??
-
:'( Isn't that what I just said??
Don't worry about tbailey2 he come across as a grumpy old sod but he has a heart of gold :)
-
I assume that you agree then.
-
I assume that you agree then.
Yes I do
-
I'm glad that's settled . . . :hug:
-
Just a further update from my original post and further to suggestions from various members:
I now have my old Mk.1 "B" RPi running merrily on DSLStats harvesting HG612 stat's. to MDWS, RPi on latest Raspbian Jessie, running headless with TightVNC / VNC Server from my Windows 8.1 desktop PC..
Had issues with getting TightVNC running after a re-boot of the RPi, eventually sorted by inserting the re-start command in /home/pi/.config/lxsessions/LXDE-pi existing autostart file, would not work for me in the /home/pi/.config folder within a new file as suggested by most web sites.
My old RPi struggled a bit at times with CPU usage, peaks just after data sampling, I have optimised the memory split to 128Mb. for GPU (default is 64Mb.) found this quite strange, would have thought that decreasing GPU allocation would have helped the CPU to recover, however, having tried step changes in both directions from the default 64Mb. can state that 128Mb. GPU allocation appears to be the best compromise.
I had purchased a RPi 3 for DSLStats/MDWS service, this obviously runs the set up with less trouble, however, as the old RPi seems to be doing the business I am currently keeping the RPi 3 in reserve for future projects, the old RPi is not really fit for present day, more demanding applications anyway, good to be able to finally but the old Pi into service.
I note there have been a lot of issues reported regarding getting DSLStats to auto-start on boot up, especially when running headless via VNC connection, this does not really bother me, I am quite content to manually start DSLStats and accept that the monitor won't run after a power outage unless re-started manually.
I find the MDWS on line facility fantastic, congratulations to the creator/custodian for the facility, and indeed to the creator/custodian of DSLStats for the provision of this excellent monitor.
Many thanks to all who offered suggestions and help, much appreciated.
-
Just had a wee peek at your downstream ES rate for 7 days it's staying in the amber zone and only reaching 481 ES in 24 hours yesterday on fastpath your well away from getting near the red zone of 2880 ES on the DLM Speed profile.
You also appear to be on a Huawei FTTC cabinet without G.INP this part can take upto 2 months if it's needed.
-
Hi, Many thanks for the response and interest.
I have been messing about over the last few days with the monitor, jumping backwards and forwards between the old and new RPi's giving gaps in the data uploads, should be stable now and the stat's. should be more meaningful without any data upload gaps.
Yes, I am definately on a Huawei FTTC cabinet, I was wondering about G.INP, I am situated in Northern Ireland, perhaps BT are a bit behind over here with G.INP roll out even on Huawei cabinets ?
I am a very recent convert to fibre, on ADSL2+ I always considered my line to be very good and noise free, however, by comparison to most of the other MDWS users stat's. my DS, ES's / day do seem higher than most but still well clear of the "red" zone as you say.
I did connect initially on fast path at the ADSL/VDSL conversion date then went to DS interleaving as few days later.
After approx. 4 days, DLM re-synch'ed and put DS back to fast path where it's been ever since.
I 'am not totally clear as to the criteria for application of G.INP, if it is active on my cabinet should it now be applied to my line under it's current circumstances ?
I was inclined to believe (likely in ignorance) that G.INP, when available, was only applied if required ?
Isn't MDWS fantastic, in combination with DSLStats an absolute font of information.
-
G.INP will be active on your FTTC cabinet and it's available here in Northern Ireland I can vouch for that as my line really needs it, from what I can see new FTTC installs like yours can take 7-8 weeks for G.INP to be applied to your circuit/line
looking at MDWS all or most users using this Huawei FTTC cabinet have G.INP enabled so I am still in the believe it will use it even if not required.
-
Well NS you have been proved correct, I had a DLM re-synch @ 06:15 this morning and G.Inp has finally been applied to my line, you did predict up to 8 weeks on a new installation, yesterday was 7 weeks since ADSL to VDSL converson day.
For the record, my line was not struggling prior to the DLM re-synch this morning, I was running just at the bottom range of ILQ amber yesterday and at the top of ILQ green for quite a few days previous with respect to DS ES rate it looks like the DLM re-synch was instigated for the express purpose of G.Inp application.
The before & after stat's can be observed on MDWS, ID tiffy.
Over the few weeks I have been on fibre and posted questions relating to G.Inp application criteria I have observed that there are a lot of very well informed members of this forum, PN and TBB forums that are of the opinion that G.Inp is only applied to a line when/if deemed necessary by DLM, my experience and indeed the kitz Q&A tutorial with BT, http://www.kitz.co.uk/adsl/ginp-retransmission.htm would seem to contradict this belief.
-
Did you notice the sudden drop of Errored Seconds being plotted in MDWS that still amazes me and you got a increase of sync you should see the DLM status indicator Downstream turn all green tomorrow.
Why new FTTC installs take this long to apply G.INP onto a line I've no idea 7-8 weeks is quite a long time ah well someone must have decided this is the best way :-\
-
strange why it was so long - one of our family members had brand new line and FTTC service. G.INP was enabled 10 days after the new service went live. I monitored it from activation on day 1.
-
There seems to be no set time for G.Inp to be applied, on my line on two occasions it has been activated after about 2 days, firstly after starting my FTTC service and again 2 days after having a DLM reset which removed it.
-
Do you have the exact date that your line went live?
-
Do you have the exact date that your line went live?
ADSL2+ to VDSL2 conversion took place on Wed. 7th. June @ approx. 09:15 hrs., previous long term ADSL line with PN, still with PN, VDSL had been available for a long time in my area but did not have the requirement for fibre speeds.
-
Did you notice the sudden drop of Errored Seconds being plotted in MDWS that still amazes me and you got a increase of sync you should see the DLM status indicator Downstream turn all green tomorrow.
Why new FTTC installs take this long to apply G.INP onto a line I've no idea 7-8 weeks is quite a long time ah well someone must have decided this is the best way :-\
Yes, the difference is quite dramatic already as I had expected having observed other MDWS users stat's with G.Inp applied to their lines.
I did have quite a substantial increase in my DS synch speed as well, that's a bonus.
With the RPi 24 hour monitoring now in place and by virtue of the excellent MDWS facility the before & after G.Inp changes should be visable to all interested parties.
-
Hopefully I have G.INP applied on or around August 1st then.
My line has been live since Feb 3rd, but DLM only started monitoring the line on June 12th (my order was not completed by OpenReach till then).
-
My line went live on the 29th June so hopefully I should have G.INP around the 17th August then! :)
-
Yes, I will keep my fingers crossed for both of you.
I would not count on the 7 to 8 week delay for G.Inp application being set in stone but it certainly was the most accurate prediction for me, made by NewtronStar quite a few weeks ago when I first started posting on the issue.
I found that there are quite a number of members on this forum, Plusnet members forum and TBB forum who are still of the opinion that G.Inp will only be applied to a line when deemed necessary by DLM, ie. a line not performing well and struggling with errors, the experience with my line would certainly appear to discount this belief.
I have had some communication with Chris Pettitt today via PN members forum, he is Plusnet Build & Release Engineer and has produced some very good fibre fault & tutorial guides for the forum, he has agreed that guidance on G.Inp is definately required and has agreed to look into producing a tutorial / fault guide to compliment the existing topics.
-
Well nothing with your line triggered a DLM resync, nothing changed that meant G.INP was suddenly needed.
The only thing I have ever seen on the subject, officially, is that it's applied to all lines by default. That makes perfect sense to me. There's not a single line that wouldn't benefit from it.
-
Now a week on DS G.Inp and DS ES rate is flat lining apart from a 3 sec/day record on the day after application.
My US error rate was always virtually zero (contract capped at 2 mbps) so no G.Inp requirement.
Without antagonising the ECI cabinet users or the Huawei cabinet users who are still awaiting G.Inp application/re-application, G.Inp certainly makes a difference as can be readily observed on MDWS.
Not complaining but just an observation, my line DS synch. increased from 35,995 to 38,290 kbps. on the G.Inp application, DLM re-synch, however, have noted that BT WH performance test and the TBB speed tests have consistantly produced lower data speed figures since G.Inp application (was DS fast path before G.Inp) is this a product of the associated DS I/L (8 in my case) and/or INP application (47.00 in my case) and to be expected ?
Before anyone else comments, yes, some people are never happy !!
-
Nice. Sadly those of us on eci still await the eci g.inp elusive return.... :wall: now well over 12 months since we had a taste..
-
There's not a single line that wouldn't benefit from it.
Not everyone agrees with this, e.g. ASSIA:
For a line experiencing very frequent and very brief
noise bursts, the best protection is achieved by
using FEC and interleaving
-
have noted that BT WH performance test and the TBB speed tests have consistantly produced lower data speed figures since G.Inp application (was DS fast path before G.Inp) is this a product of the associated DS I/L (8 in my case) and/or INP application (47.00 in my case) and to be expected ?
No, no and no.
Even if you were on a Retransmission High profile with an accompanying lower percentage for the IP profile, 96.7% of 35,995 and 91% of 38,290 work out as about the same value (34.8 Mb).
-
I appreciate that there are different views regarding G.Inp amongst this and other forums members, I personally was very keen to to have it applied even though my line probably did not need it, was running DS fast path with ES daily rate consistantly at the top end of ILQ green or the very bottom end of ILQ amber, very rarely had any US ES's recorded.
Had a very occasional "bad noise" day but these were very rare.
I certainly still prefer to have G.Inp applied as it has eliminated my recorded DS ES's completely and keeps me firmly in ILQ green state, hopefully any future impact due to "bad noise" days will also be reduced/eliminated.
Thanks for the information regarding IP profile calculation from DS synch speed, I have seen these figures before but certainly had forgotten their relevance in this context, makes sense now, initially seeing the increase in DS synch speed post G.Inp I expected to see a corresponding data throughput speed increase.
-
G.INP still not enabled for me. Looks like the time period is going to be very accurate...
-
Sorry to hear that but certainly not surprised, everything about G.Inp application appears to be shrouded in mystery, a very grey area !
-
Got G.INP enabled this morning :)
So that is 5 weeks and 6 days for me to have it enabled.
-
Excellent news, DLM may be slow but it appears to eventually get there.
You actually beat my experience, 7 weeks & 1 day from VDSL C/O. to G.Inp application.
Was there any perceived trigger such as line instability prior to G.Inp application or did DLM just finally decide to apply as per my experience on 28/07/17, I have not looked at your MDWS trends,they should certainly tell a story ?
Only problem now, MDWS becomes boring to watch with the DS ES's gone and permanant green's on the ILW indicator's.
Only joking, honestly !!
-
Just had a look at your MDWS, from my limited experience I can't see any reason for DLM intervention other than to apply G.Inp, virtually the circumstances on my line when G.Inp was applied.
I note that your DS interleaving and INP, 8/46 are virtually the same as my line, 8/47 post G.Inp application.
Again as per my experience, you DS synch. rate has increased quite a bit, I expected to see this reflected in my DS data speed, was not the case, some of the more experienced forum members reminded me that the data throughput overheads are greater with G.Inp applied, (96.7 to 91% of DS synch. speed to line IP profile) in my case this gave exactly the same DS data rate (IP profile) before and after G.Inp..
-
I think the approx. 91% IP profile only applies to "Retransmission High" profiles, and presumably you'll at least start on "Retransmission Low".
-
No, no and no.
Even if you were on a Retransmission High profile with an accompanying lower percentage for the IP profile, 96.7% of 35,995 and 91% of 38,290 work out as about the same value (34.8 Mb).
As you informed me earlier in this thread, my before and after G.Inp DS synch speed figures applied to the percentage figures you quoted gives me my current (and pre G.Inp) DS IP profile of 34.8 mbps, I was certainly willing to accept these figures with that explanation.
-
Had another DLM resync today and INP has been increased to 55 on the downstream.
-
Can you tell from Dslstats whether you are on a Retransmission High profile or a Retransmission Low profile?
-
Still no G.INP for me. Though a harsh cap for a couple days on my line just managed to get DLM to return it to fastpath.
-
Can you tell from Dslstats whether you are on a Retransmission High profile or a Retransmission Low profile?
I was on 46 before and now 55 so I'n guessing that's low to high? INP REIN has increased as well.
-
Had another resync and I think I'm now on a 5dB target on the downstream. Sync now maxed out at 54997.
-
Sync now maxed out at 54997.
I presume that you are a consumer of the Openreach 55/10 Mbps? :-\
-
I presume that you are a consumer of the Openreach 55/10 Mbps? :-\
Indeed.
-
Had another DLM intervention today and now have G.INP on the upstream. Did three manual resyncs yesterday which I don't think would have caused it - speed profile is up to 10 per day?
Downstream and upstream are now maxed out, at 54997 and 10000 :)
-
Had another DLM intervention today and now have G.INP on the upstream. Did three manual resyncs yesterday which I don't think would have caused it - speed profile is up to 10 per day?
Downstream and upstream are now maxed out, at 54997 and 10000 :)
I thought speed was supposed to be up to 20 per day? Standard 10, stable 5? Maybe I'm mistaken though.
http://www.kitz.co.uk/adsl/DLM_calculator.php
I assume you didn't exceed the ES+SES threshold on the upstream? Also how close were the three manual resyncs?
-
About 15 minutes apart.
-
Still no G.INP for me. Though a harsh cap for a couple days on my line just managed to get DLM to return it to fastpath.
Any reason for the cap that you know of? Was it just on for a couple of days before it was removed automatically?
-
About 15 minutes apart.
A wild theory, though seems to relate to my experience recently when I was changing some settings on the ASUS too soon in an hour. I re-synced four times in one hour, I didn't exceed any other thresholds, the following day DLM intervened.
My theory is that maybe you re-synced too many times within an hour for FTTC's DLM.
-
A wild theory, though seems to relate to my experience recently when I was changing some settings on the ASUS too soon in an hour. I re-synced four times in one hour, I didn't exceed any other thresholds, the following day DLM intervened.
My theory is that maybe you re-synced too many times within an hour for FTTC's DLM.
You may be quite right. My understanding was that if you leave 30 minutes between resyncs then DLM won't get upset?
-
Any reason for the cap that you know of? Was it just on for a couple of days before it was removed automatically?
I should have been more specific. I set the cap, as despite being ILQ green for nearly 9 weeks my lines been interleaved with no G.INP in sight. Capping my line from 40/8 down to 25/5 looks like it returned it to fastpath.
Though DLM removed interleaving at 2:30pm, right after a power cut affecting the entire county. It threw me as I've never had DLM take action so late, noon probably being the latest before this.
Despite remaining ILQ green, 2 days later interleaving was reapplied. I'd much rather have lower sync/lower latency. Seems DLM is determined to keep my line interleaved though.
I had the same trouble with interleaving not removing when I was connected to the ECI cab. Despite being ILQ green for over 6 months it wouldn't budge. After trying various caps over time I've noticed I need to cap the line low enough to get ES below roughly 20/day.
I've capped the line again and I'm hoping at some point this morning (or maybe early afternoon again) DLM will remove interleaving again.
-
It has been way to long now John for G.INP to become active, nothing has gone right since that move to the Huawei cabinet it does look as if your circuit is ignoring any attempts to move your line onto G.INP re-transmission
Lowering the sync rate will not do much other than getting you back to Fastpath quicker was this not the trick some of us used to get rid of interleaving/banding, if it doesn't not work I can only think of another way and thats a DLM reset/recalc by Openreach.
-
wow he is still waiting?
-
DLM has removed G.INP on the upstream today.
-
wow he is still waiting?
And how long does he have to wait ?
-
I got no idea, you usually predict DLM waiting times quite well.