Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[les-70]

  mdslwebsats is a mix of ISP's but more or less consistent with 1440 i.e. 60/hour average as a probable limit and probably need for a sustained less than 6/hour average to recover.    Until we can be really sure I think 1440 is much safer guide figure.

  On mydslstats there are about 7 non-interleaved in the range 20-40 ES/hours where the ES/hours, as noted above, are have to precisely estimate.  No one is above  ~40/hour, I guess if they were then an odd bad day or two would lead to DLM action.

   I guess the 6 to recover is so low as interleaving markedly reduces errors and without a low limit, for good, things would just switch on and off.

 !0 disconnects is still more than the 5 or so some have observed but it is easy to forget what messing around may have occurred the day before and still be in a 24/hour time span. 

[kitz]

Im afraid I really dont have time atm to look at the figures.  I possibly buggered totals up a bit too because I swapped out routers a couple of time to make sure it wasnt hardware at my end.  I also left the router without sync for a few hours -it was Sat not Friday that I swapped routers, but iirc Id also done a full system boot on the Friday just also to ensure it wasnt the Zyxel that had got itself in a tizz after the outage (Several routers do this after electrical outages - but it wasnt that either)

To find out exactly how many errsecs there are, then it would need something like DSLstats or HG612 to automatically count the totals at midnight which is when the DLM averages out the days totals.

Ive had a quick look and according to that on the first day (17th) I had 2453 Err Secs. 
The next morning the DLM applied interleaving depth 357 & INP 3

On the 18th I had 2839 ErrSecs but apprx three 3hrs without sync whilst I swapped routers out.
For that the DLM changes Interleaving depth to 325 & rate limited the line to 17Mb


Im afraid you'll have to wait until I get chance to look and break down the other days.

One thing I did notice which I dont know if is co-incidence or not with the rate limiting, is that on each of the profiles my SNRm seemed to be damn near to either 6dB, 9dB or 12dB.  Again something I will have to check when I get chance.

[kitz]

!0 disconnects is still more than the 5 or so some have observed but it is easy to forget what messing around may have occurred the day before and still be in a 24/hour time span

Thats why it was handy to see adslmax's RADIUS log, and whilst chrys said that PN cant see the loss of sync as such.  If everything is working correctly then loss of sync should also cause loss of PPP session.  It was also pretty easy to spot as you could see he'd left the router off approx each time he swapped over routers, thinking 10-15 mins would be long enough to avoid DLM action.

My RADIUS log has picked up all my loss of syncs over last week.

[Chrysalis]

I guess this depends on the router, on my asus if I lose sync only momentarily the ppp will survive 90% of the time.  It usually needs an actual sync outage to drop the ppp.  My PPP seems to drop at least 2-3 times a month completely of its own accord, whether that's plusnet rebalancing, BTw maintenance or something else I dont know.

I guess one of us should query again on the plusnet forum which profile they using but I think they wont be too open about it.  Someone higher up may have decided its easier on their tech support department to deal with moaners about interleaving instead of having more unstable lines.

[Ixel]

Bear in mind that interleaving depth isn't an accurate metric of what DLM's doing to your connection, as the sync rate adjusts that value. The speed band (if any), INP and delay are generally the values I'd suggest observing.

[Bald_Eagle1]

Thats why it was handy to see adslmax's RADIUS log, and whilst chrys said that PN cant see the loss of sync as such.  If everything is working correctly then loss of sync should also cause loss of PPP session.  It was also pretty easy to spot as you could see he'd left the router off approx each time he swapped over routers, thinking 10-15 mins would be long enough to avoid DLM action.

The trouble is that not everything works correctly.

When I first wrote the connection logging scripts due to my very unstable connection at that time, I could see numerous connection resyncs at differing speeds.
However, PlusNet could only see an occasional PPP disconnect/reconnect in their Radius logs.
They obviously initially argued that my connection was in fact stable & didn't warrant further investigation.

EVENTUALLY, they came round to accepting that the HG612 modem would often resync quicker than their PPP session timeout settings & thus their Radius logs were not a reliable tool for measuring the actual number of resyncs.

I think we are all now aware that this potential issue is mentioned in BT's SIN498 documentation.

My RADIUS log has picked up all my loss of syncs over last week.

Was that when using the combined ZyXel modem/router?
If so, I would imagine that a resync would also disconnect/reconnect the PPP session as per a typical ADSL combined modem/router.


Still using a HG612 modem with my original Netgear WNR 1000v3 router, my connection doesn't resync very often these days & when it does, the PPP session is still often retained (confirmed by the dynamically allocated IP address & BT's IP profile remaining unchanged).
i.e. I still have to sometimes manually force a new PPP session via my Netgear router in order to initiate a new PPP session so that BT will send a delta report for PlusNet to adjust their own profile.

[Chrysalis]

Also there could have been a period on adslmax's line where he had several resync in one short period that plusnet just seen as one PPP outage because the uptime was never long enough to establish a new ppp session.

[tbailey2]

To find out exactly how many errsecs there are, then it would need something like DSLstats or HG612 to automatically count the totals at midnight which is when the DLM averages out the days totals.

That was fairly easy to do in MDWS as the needed data is there just before it's plotted.... As an experiment only I've changed the standard ES graph to show both Total and Average figures for Downstream only ES along with the usual hourly totals. The average data and totalling starts at 01:00 with the 00:00-01:00 hour's total and is plotted each hour until reset after the 23:00-00:00 totals are shown.

To be accurate it needs a complete 24 hours worth of data with no downtime on the graph. Otherwise the results are not accurate as it just uses the data that's there. Showing several days at a time is possibly the best way.

So there are four plots which may need a bit of close eyeball work for low values but I believe the idea here is to see higher values when it is much easier to decipher. Dragging a small area horizontally will zoom it if needed.

If it's of any use or preferred I can split it out into two new sets of graphs so you'll have ES (Normal), ES DS AVg+Totals and ES US AVg+Totals.

Attached is a composite plot for 3 days for BE1....

[les-70]

  That looks really good for the always on users.  It is quite likely that I have missed one but, over the last 10 days the biggest fast path 24 hours I can find are about 900ES/day on just odd days and very few are above 800ES/day.

  If you look at my 10 day plot you will see what is probably the inevitable consequence of intermittent logging, maybe it can be improved a bit but the needed info to be complete just not available to you.  I think it may be time to invest in  a Rb Pi.

[Chrysalis]

To find out exactly how many errsecs there are, then it would need something like DSLstats or HG612 to automatically count the totals at midnight which is when the DLM averages out the days totals.

That was fairly easy to do in MDWS as the needed data is there just before it's plotted.... As an experiment only I've changed the standard ES graph to show both Total and Average figures for Downstream only ES along with the usual hourly totals. The average data and totalling starts at 01:00 with the 00:00-01:00 hour's total and is plotted each hour until reset after the 23:00-00:00 totals are shown.

To be accurate it needs a complete 24 hours worth of data with no downtime on the graph. Otherwise the results are not accurate as it just uses the data that's there. Showing several days at a time is possibly the best way.

So there are four plots which may need a bit of close eyeball work for low values but I believe the idea here is to see higher values when it is much easier to decipher. Dragging a small area horizontally will zoom it if needed.

If it's of any use or preferred I can split it out into two new sets of graphs so you'll have ES (Normal), ES DS AVg+Totals and ES US AVg+Totals.

Attached is a composite plot for 3 days for BE1....

nice job, can you add a column to display the hardware used (when known), I would guess its possible to get of ronski's app as I have to select which modem I am using so its stored in the config.

[tbailey2]

Nice job, can you add a column to display the hardware used (when known), I would guess its possible to get of ronski's app as I have to select which modem I am using so its stored in the config.

Sorry, nope, don't know it as it's not available in any of the uploaded data.....

[tbailey2]

  If you look at my 10 day plot you will see what is probably the inevitable consequence of intermittent logging, maybe it can be improved a bit but the needed info to be complete just not available to you.  I think it may be time to invest in  a Rb Pi.

See if it's any better now..... It can still go wrong but looks more like it should    I've set it to reset if the hours value is less than the last plot's hours and not 0.

[les-70]

  Thanks, as you say that is much better.       I don't know exactly what is uploaded or whether you base stats just on errors within 1 minute, but if  ES since link is uploaded, tracking the change in that total ES might give a better ES/hour with intermittent uploads.

 (I am doing some HG635 testing at the moment and consequently not uploading.)

[kitz]

To find out exactly how many errsecs there are, then it would need something like DSLstats or HG612 to automatically count the totals at midnight which is when the DLM averages out the days totals.

That was fairly easy to do in MDWS as the needed data is there just before it's plotted.... As an experiment only I've changed the standard ES graph to show both Total and Average figures for Downstream only ES along with the usual hourly totals.

That is brilliant.. because it fits nicely with something else I had in minde  :clap2: 

Once you have some figures to play with..  this may be of use :-

http://www.kitz.co.uk/adsl/DLM_calculator.php

The average data and totalling starts at 01:00 with the 00:00-01:00 hour's total and is plotted each hour until reset after the 23:00-00:00 totals are shown.

Information seems to suggest that the DLM starts at midnight, so should work well.  Over the past week Ive been trying to dig out anything and everything I can about the DLM, theres also some contradictions on some of the info I have found, but I guess we just have to do what we can with what we can.. and guess at the rest

To be accurate it needs a complete 24 hours worth of data with no downtime on the graph. Otherwise the results are not accurate as it just uses the data that's there. Showing several days at a time is possibly the best way.

Indeed, but genuine downtime can and will be adjusted accordingly by the DLM.  The calculator should also for 15 min bins same as the DLM. I need to revisit rounding, so for the time being Ive left it with simple rounding to 2 decimal points.    I can only stress its beta atm, and something Ive put together tonight after I got home.
 
I wont have chance to do anything more on it now for several days... but theres a few things I want to try and contact a couple of people about to clarify with, but that will have to wait as my dad is very ill    Ziggs is also poorly and dunno whats happening atm. I have him home tonight, but hes got to go back at 8:30 tomorrow. Ive also just got results back for my annual checkup and it looks like I'll also be back in hospital sometime soon.    

[kitz]

This is a real quicky which chrys may be interested in.   Dont have time to put all info..   but you know that 5,10,20 figure for resyncs that gets quoted..  well in one of the docs Ive read there was something about 'grey' ie its a fast track down the DLM scale for really troublesome lines. 

When I coded the DLM calculater I noticed that for the MTBR it seems to suggest 10 resyncs is about all you can get away with.
I checked and double checked and it appears to be calculating correctly.   Ive done a search to find out if there is any more sets of MTBR figures then I noticed this on the Plusnet site linky



Zoom in and see what it says for ILQ Scarlet.

Im going to attempt to contact a couple of people but as mentioned previously, I wont have chance now until when Im not sure ... at least until after the weekend :/