Silver - Disconnections and slow speed

[#1]

That's a shame there's nothing there Silver. If I knew how to Telnet on a MAC then you could look further back in the log entries and we might have found something.
Right guys, please remember not to make things too technical in one go for Silver's benefit. Please excuse us Silver whilst we have a slight technical "debate".
Sorry guys, if you have a Loss of Signal, you have a Loss of Sync, whether it's a Technicolor, a Linksys, a Netgear, a Voyager or anything else. Some texts refer to LOS as "Loss of Sync" (not that it's excusable to do that really). How that shows in the stats will depend on the cause. More on that later.
From a couple of different sources - (note ATU-C is the exchange end, ATU-R is the user end)
lossOfSignal - ATUC failure due to not receiving signal.
Loss of Signal - Error events caused by the absence of any signal for any reason, such as disconnected cable or loss of power.
From RFC-2662 - A Loss of Link condition is declared at the ATU-C if a Loss of Signal is not preceded by a `dying-gasp' message from the ATU-R. Note that Loss of Link is only supported by the ATU-C.
AFAIK Loss of Link is not supported by current 20CN DSLAMs or 21CN MSANs (that's the exchange equipment end of the broadband connection Silver), at least not as a supported error count.

Quote from: ejs

A loss of signal error does not mean that the ADSL dropped and re-connected, so there won't be any xdsl linestate down / xdsl linestate up log entries corresponding to loss of signal errors.

Wrong! The attachments in the first post in this thread are a good example of a case of loss of sync. Note the LOS count and some of the various Log entries - xDSL Line state down. But this is not the only possible scenario - as mentioned in a muddled way by Kevin and also it would seem in ejs' stats now I've had a quick look at them.
ejs,  whilst there is nothing technically wrong with your posted definition of LOS, it was nitpicking to split hairs between resync and retrain especially as in some circumstances this doesn't necessarily happen. I'll try and explain that in a following post.

[#2]

Perhaps a moderator should split off the discussion of what a Loss of Signal error actually is vs. what Anotherone thinks it is despite all evidence to the contrary to a separate thread.
Sorry Anotherone, I assume you are just going to ignore all the stats we post with increasing numbers of LOS errors while the ADSL doesn't drop? And keep telling us we are wrong?
A LOS error is the LOS state for 0.1 seconds.
A LOS failure is 2.5 seconds of continuous LOS state. From the G.997.1 PDF. The LOS failure is not the same as a LOS error.
The attachments in the first post in this thread contain no information whatsoever as to when the LOS errors occurred. There is nothing to support the assertion that the entries in the log correspond to LOS errors. You can get a count of "Number of reset" (retrains) via telnet from "xdsl info expand=enabled".

[#3]

ejs, both are relevant to Silver's line problems. Just because you don't understand what may have gone on here and are too impatient to wait for me to post the explanation about it - I have other things to do besides just reply to this - it doesn't make you right.

[#4]

Neither of your personal attacks directed towards me, which I'm starting to get a bit tired of by the way, are going to change the fact that on this occasion, regarding what a loss of signal error is, me, Townman and Oldjim are in fact correct, and you are wrong. The fact that you've always been mistaken about what a loss of signal error is doesn't make you any less wrong. If you're just going to disregard all evidence that doesn't fit with your misunderstanding, then there's no point continuing the debate.
Perhaps you'd like to clarify that when you say loss of sync, you do indeed mean the ADSL drops, goes back to the initialisation state, and re-establishes the connection, probably at a slightly different speed? Otherwise I expect you'll try to wriggle out of being wrong be re-defining whatever you've said before so that a loss of sync means not receiving a few synchronisation bits within the ADSL signal or something like that.

[#5]

ejs, this is not a personal attack - get off your high horse. If you want to perhaps be a touch pedantic, none of us are wrong.
OK, a quick recap. When Silver first posted here she was suffering lots of connections drops and resyncs/retrains (call it what you will) that had resulted in her connecting at low speeds and the connection being banded. You may also care to note that the LOS count on the posted stats was large.
Before what I explain what I believe is happening here, I'll comment on a couple of points first.
ejs,
first, you seem to be saying that the LOS count doesn't change when there is loss of sync, if so you are wrong. I've sat in front of my own stats and watched it increment when there has been loss of sync, never mind many of the other documented stats on these boards.
Second, your quote in post #98 is largely irrelevant (and therefore overcomplicated as I've already remarked - that is inconsiderate to Silver) as there is no change in power state L0/L2 here.
Third, reply #106 - do you know which LOS event the 582n actually reports? If not, going into that detail only confuses the picture further when you can't explain what is actually going on.
4th, do you know how to Telnet on a MAC? If not, quoting xdsl commands is irrelevant to Silver (but Kevin may wish to note that one - Routerstats also uses it).
5th, you choose to ignore all the information the poster had given in the example I happened to quote. Whilst I accept there is no precise indication of when those LOS events occurred, in the time frame the poster described, it's pretty obvious when they happened.
Finally, look at the test data in reply #80 and my reply #81. There were "retrains" even though the sync speed was unchanged.
Now, I will admit I did look at all that rather quickly and didn't give it more in depth thought at the time, nor when making my comment about when the last LOS event was, as quoted by Kevin in reply #97. However Kevin, reference to kitz (reply #94) and inventing terminology that doesn't exist/or is mentioned in the quote doesn't help. There's no such thing as a 'micro' loss of sync.
OK  to the crux of the matter. The LOS count can increase without there being any change in downstream sync speed as well as instances with the loss of downstream sync. This is due to a loss of upstream sync. When this occurs, provided that it is not sustained for long enough then there is no loss of PPP session, nor change of IP address as alluded to by Kevin in reply #97.
Plenty have seen the effect of a loss of sync with no loss of PPP but there are very few of us on here have actually watched it happen whilst monitoring it (at least that have communicated this information) and in such instances the reported Line count/Line reset count doesn't change.
I can go into some more depth, but don't have time right now, and as remarked earlier I didn't give it enough thought that this may be occurring on Silver's line because of the previous events

[#6]

Quote from: Anotherone

ejs, this is not a personal attack - get off your high horse.

Was that really necessary?  Presumably you'll be arguing about how black is white next.
No, I was not saying that the LOS count doesn't change when there is a re-train. I don't know what gave you that idea. I'm saying the LOS count can change without a re-train. Which you have eventually accepted, after reminding me how controversial and inconsiderate and impatient (for not staying up until midnight) I apparently am.
Of course there could be plenty of reasons for the line to re-train besides a loss of signal.
The test data in post #80 just gives the number of retrains and the sync speed at the moment that data was collected. It doesn't prove there were re-trains without the sync speed changing, although there were very likely to be re-trains without the sync speed changing while the line was banded.
Oh, presumably you're talking about the 6 retrains after the 0 retrains. Presumably those stats must be collected daily or when the sync speed changes, so that the delta sync "timestamp" isn't necessarily when the stats were collected.
In reply to post #81, mean time between errors being high is of course a good thing, the higher the better. But we know what you meant to say.
I don't see how the definition of loss of signal is irrelevant. The bit about L0/L2 is in brackets, the fact that there's no power management happening doesn't mean the whole definition is irrelevant. The overcomplicated definition means that the loss of signal is when the power level of the received adsl signal is 6db or more lower than what is usually is.
Do you know which LOS event the 582n reports? The web interface just calls it Loss of Signal, although the telnet stats list something under G.997.1 Statistics, Line failures, Loss of signal.
How to telnet on Windows/Linux/Mac - open a terminal / command prompt and enter exactly the same command - "telnet 192.168.1.254" (or appropriate IP address) (without the ").
Edit 2: One more point - the Loss of Signal figures are reported as local in the web interface, and as near end in telnet. Saying they must be due to loss of upstream sync doesn't really tally with the loss of signal being about power level of the received signal. Surely if the upstream signal was lost, only the remote / far end would be able to detect the signal was weak / lost.

[#7]

Gentlemen please!,
This is interesting, but the argument is not helping Silver, which is what we are all really trying to do.

Quote

Now, I will admit I did look at all that rather quickly and didn't give it more in depth thought at the time, nor when making my comment about when the last LOS event was, as quoted by Kevin in reply #97. However Kevin, reference to kitz (reply #94) and inventing terminology that doesn't exist/or is mentioned in the quote doesn't help. There's no such thing as a 'micro' loss of sync.

Forgive my imprecise paraphrasing but from the technical description of a LOS event or error this acceptedly wooly phrase does seem to describe the event well, in that a single LOS event does not lead to a xdsl state down and a full resynch.  Whereas a LOS failure (repeated or continuous events lasting 2.5 seconds if I understand the foregone discussions correctly) does lead to xdsl state down, a full resynch (possibly at the same speed) and a reset of the DSL connected timer.
Back to the matter in hand, how does the discussion about the correct understanding of LOS errors help us progress Silver's issue please?
Cheers,
Kevin

[#8]

Quote from: Townman

Back to the matter in hand, how does the discussion about the correct understanding of LOS errors help us progress Silver's issue please?[/url]

Well I was waiting for the LOS expert to come and tell us, as I'm apparently wrong in all I say. (The comic was funny btw.) and don't know what a terminal window is or what data I can get from an xdsl info command
I've usually tried to explain things in fairly plain english with out getting bogged down in unnecessary technical detail when it has little bearing on the practical issue - a message I've clearly failed to get across. At the end of the day, a non-technical person with a problem just wants to know how to fix it in as simple a way as possible.
There's a lot in those previous posts that needs addressing, but I'm not going to respond to them all right now.

Quote from: Townman

.......a single LOS event does not lead to a xdsl state down and a full resynch

Yes it CAN. I have deliberately used the word "event" so as NOT to equate it directly to either an "error" or "failure" in a similar way to the use in the quote from kitz I gave in reply #95. That's because one can not always be certain in every case that what you think any modem/router is reporting is what it appears to be reporting. There's plenty of examples round these boards - eg. downstream reported as upstream etc.
In this case, it appears that the 582n is reporting LOS failures. (see ejs response in reply #110 to my previous question)

Quote from: ejs

Do you know which LOS event the 582n reports? The web interface just calls it Loss of Signal, although the telnet stats list something under G.997.1 Statistics, Line failures, Loss of signal.

As I've stated in previous posts, the reported LOS seems to increment with a loss of downstream sync and also with a loss of upstream sync.
Part of the debate/argument here has stemmed from the interpretation/significance of  "loss of sync".  I think to be precise, a lot of the time we talk about resyncs, we actually mean retrains. And in the context here, although the LOS is a loss of sync it doesn't always result in a full retrain (as we understand it). Although I am at a loss (as was Chris) to explain those 6 listed retrains at the top of the stats in reply #80 with no change in sync speed, unless of course 16256 is some new capped speed no-one knows about
It's amazing what can turn up with a quick bit of googling - here's a good example of LOS associated with obvious upstream issues 
In the context of edit:2 by ejs in reply #110, how the modem/router knows it was an upstream issue - you need to remember that'll generally be because the DSLAM/MSAN didn't send an acknowledgement (ACK) for what the modem sent.
How does this help Silver? Well to get back to some plain english, there's still an issue - possibly with the line, it certainly seems like a problem with the upstream which may be down to interference, maybe the line or perhaps the filter. Is it persisting, can it be lived with if it's not disrupting internet usage? Silver may be able to answer that, but whether the line is performing outside acceptable limits will depend on the current DLM data.

[#9]

So we need another update from Silver please and CRT to revisit the line stats and the engineering notes from the part-repair BTOR visit.  Silver might need another BTOR visit to finish the fix.

[#10]

Hi
Latest stats below. No more loss of signal or disconnections, so -  assuming the huge number of errors of various types are just the router with nothing better to do  - then it seems to be holding steady.
Do not laugh but is it possible that the increases in loss of signal last week were to do with the lightning we had every day until Saturday? Was rather hoping it would thunder again today so I could put that discreetly to the test!
I will not pretend to have followed all your discussion but I hope you have reached a consensus now -  and are friends 
Thanks again

Silv.


DSL Connection
Uptime: 7 days, 16:37:48
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 1,124 / 15,355
Data Transferred (Sent/Received) [MB/GB]: 596.02 / 2.80
Output Power (Up/Down) [dBm]: 12.6 / 0.0
Line Attenuation (Up/Down) [dB]: 19.2 / 32.0
SN Margin (Up/Down) [dB]: 6.7 / 6.2
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / IFTN
Loss of Framing (Local/Remote): 61 / 0
Loss of Signal (Local/Remote): 9 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 5,470 / 4
FEC Errors (Up/Down): 54,628 / 3,407,237
CRC Errors (Up/Down): 505 / 17,291
HEC Errors (Up/Down): 1,114 / 747,528
P

[#11]

Quote from: Anotherone

ejs,  whilst there is nothing technically wrong with your posted definition of LOS, it was nitpicking to split hairs between resync and retrain especially as in some circumstances this doesn't necessarily happen. I'll try and explain that in a following post.

Quote from: ejs

Perhaps you'd like to clarify that when you say loss of sync, you do indeed mean the ADSL drops, goes back to the initialisation state, and re-establishes the connection, probably at a slightly different speed? Otherwise I expect you'll try to wriggle out of being wrong be re-defining whatever you've said before so that a loss of sync means not receiving a few synchronisation bits within the ADSL signal or something like that.

Quote from: Anotherone

As I've stated in previous posts, the reported LOS seems to increment with a loss of downstream sync and also with a loss of upstream sync. Part of the debate/argument here has stemmed from the interpretation/significance of  "loss of sync".  I think to be precise, a lot of the time we talk about resyncs, we actually mean retrains. And in the context here, although the LOS is a loss of sync it doesn't always result in a full retrain (as we understand it). Although I am at a loss (as was Chris) to explain those 6 listed retrains at the top of the stats in reply #80 with no change in sync speed, unless of course 16256 is some new capped speed no-one knows about

[#12]

Quote from: silver

Do not laugh but is it possible that the increases in loss of signal last week were to do with the lightning we had every day until Saturday? Was rather hoping it would thunder again today so I could put that discreetly to the test!

Hi Silver,
Why would anyone (especially gentlemen such as ourselves    ::)) laugh at anything so sensible.  I'd guess that the lightening had EVERYTHING to do with the LOS events.
Given that you've had a stable connection for over 7 days, there not going to be too much in the way of useful information out of the stats, beyond looking for increasing LOS counts and marked variation in SNRM.  The synch rate as I said before is good for the line's attenuation figure/
It is now a matter of keeping a watchful eye.  I think you still have 3 or so days left in your training period (since the engineer left).  It will be interesting to see how long the link stays up before you get another resynch at a different speed.
Just keep an eye on things, enjoy the better speed and stability.  You've done well in helping yourself.
Cheers,
Kkevin

[#13]

Hi Silver,

Quote from: silver

......Was rather hoping it would thunder again today so I could put that discreetly to the test!

You may get that chance sometime at the weekend 
Before you made your last post I was going to say that the CRC/HEC/ES errors were still a bit higher than one would like to see, but mine have suffered as much with the lightning. After the weekend when the weather has settled down again, it might be worth doing the disconnect/power down method in daytime when the SN Margin Down is around the 6dB or just below, to reset everything and see how it goes after that. As Kevin has mentioned, just keep an eye on things.

[#14]

Tested today .. 1 x thunderstorm = 1 x loss of signal (with no disconnection) 

[#15]

To be clear, do you mean there was no change in the Downstream or Upstream sync speeds at all?
Posting the stats might be handy in any event