Print

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

[les-70]

SES seem to be something that the DLM does, and perhaps will in the furure of any new DLM, notice.   I wondered if it might be possible add SES to the CRC plots.  I wondered about with the ES but the aim is see better the times when they occur hence with CRC.

[roseway]

Yes, that's a good point. DSLstats really should report SES in some usable manner. I'll put it on the list.

[roseway]

Update: I've added a graph of SES in the same style as the CRC graph. I decided that it was tidier to make it a separate graph rather than add it to the CRC graph (even though for most users it will probably be blank most of the time).

[les-70]

   I look forwards to using it. Your probably correct re zeros's for most people. On my noisy line I get a few a day if I cap my speed but about 10-20 if I run uncapped. 

[broadstairs]

Eric I noticed this morning that I had been put on interleaved but DSLStats had not recorded a re-sync, however MDWS had detected the re-sync and sent me an email. I am puzzled as to how MDWS detected it but DSLStats did not.

I guess this is because the re-sync happened and completed within the minute that DSLStats was waiting between samples. Surely this should be detectable by DSLStats, perhaps by checking the DSL uptime has now fallen from its previous value. This would allow DSLStats to both record it and activate any commands which may have been setup to run on a re-sync.

Stuart

[roseway]

Yes Stuart, you're probably right. DSLstats detects a resync by first detecting a connection drop, then detecting a good connection afterwards. So if it all happens within one sample period the resync won't be detected. For the next release I'll add a separate check.

[broadstairs]

Thanks Eric, I think that will help a lot when that sort of thing happens, DSLStats is my first point of call to check the connection..

Stuart

[burakkucat]

Eric I noticed this morning that I had been put on interleaved but DSLStats had not recorded a re-sync, however MDWS had detected the re-sync and sent me an email. I am puzzled as to how MDWS detected it but DSLStats did not.

Just a quick request for clarification, please.

MDWS will only display the data that it has been sent. As far as I am aware it is only Eric's DSLStats and Bald Eagle1's HG612_stats utilities that currently upload data to MDWS. My conclusion, therefore, is that you have both utilities (DSLStats and HG612_stats) executing and uploading data to MDWS. Is that correct? 

[broadstairs]

Eric I noticed this morning that I had been put on interleaved but DSLStats had not recorded a re-sync, however MDWS had detected the re-sync and sent me an email. I am puzzled as to how MDWS detected it but DSLStats did not.

Just a quick request for clarification, please.

MDWS will only display the data that it has been sent. As far as I am aware it is only Eric's DSLStats and Bald Eagle1's HG612_stats utilities that currently upload data to MDWS. My conclusion, therefore, is that you have both utilities (DSLStats and HG612_stats) executing and uploading data to MDWS. Is that correct? 

Sorrry no only DSLStats, I'm guessing the MDWS senses a reconnect if DSL uptime goes to a lower value than the last data showed. I expected to see an entry in the Event log on a re-sync if DSLStats noticed one and there was nothing.

Stuart

[burakkucat]

That is very puzzling (to me).    I understood that Tony's MDWS only displays data that it has been sent.  Hmm . . . So it appears that MDWS also makes decisions based upon the data uploaded to it.

[broadstairs]

This is what I got from MDWS

This is to let you know that a resync/restart occurred on your line on 30-11-2014 05:09 (+/- 1 minute).

Reason: 1 Remote Defect Indicator

Current Downstream Sync Rate is now 54998kbps
Current Upstream Sync Rate is now 19993kbps

There was nothing in the DSLStats Event log for that time. The two relevant entries are

30 Nov 2014 04:52:44   Auto snapshots taken
30 Nov 2014 05:42:42   Alert: Downstream FEC/min rose to 105.00

Stuart

[tbailey2]

That is very puzzling (to me).    I understood that Tony's MDWS only displays data that it has been sent.  Hmm . . . So it appears that MDWS also makes decisions based upon the data uploaded to it.

Corrrect since there is no data uploaded that on its own says exactly when a resync occured, it's not a distinct recordable value as such. You (i.e. the code) have to look at the data and then decide. BE1 and myself also do it different ways, not sure about Eric

[roseway]

I mentioned earlier how I currently do it, but as Stuart has pointed out, it can fail if the entire sync drop-resync cycle is completed within one sampling period. So I'll be improving it in the next release, probably by detecting a sudden fall in the AS (available seconds) value.

[broadstairs]

I used to have a 15-20 second sample interval prior to MDWS but now of course it is set to 1 minute. With 3 or 4 samples a minute it is very unlikely DSLStats would miss a re-sync but at one minute or so it is much more likely.

Stuart

[NewtronStar]

Thats must be some fast modem/routers people are using if it takes under 1 second for the line to drop and resync it takes my HH3 about 3 minutes from a cold boot