Print

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

[Weaver]

Referring to the two sets of data I included in my other post [see http://forum.kitz.co.uk/index.php?topic=4024.0] notice that the downstream sync rate went up quite a bit, but the "LOS errors" count remained at zero so presumably no loss-of-sync event occurred.

Why would it change like this, or to put it another possibly better way, what mechanism was invoked or what is this event type correctly called?

(And the router was not rebooted, as I was right there monitoring it at the time the state changed.)

Note that there's a big drop in upstream rate from 608->448 in the state change, despite the downstream rate actually going up. It seems to me at least possible that it's to do with the fact that the initial upstream rate of 608 not being quite sustainable at ~6dB SNR margin into the late afternoon with the sun getting low.  (The service is the BT Wholesale IPStream Max Premium service with its higher upstream limit.)

[roseway]

This is presumably ADSL24+ (?) in which case the connection speed can change without dropping the connection using Seamless Rate Adaption (SRA).

[HPsauce]

SRA isn't necessarily relevant.
I'm on an ADSL2+ service which definitely doesn't support SRA.
If I request a router resync it doesn't show as LOS or LOF in the stats even thouigh the rate changes. (DG834GT)

[kitz]

"LOS errors"

Contrary to some belief LoS stands for loss of signal rather than loss of sync. 
LoS are one of the most serious types of errors, but it is possible to have LoS without loosing sync to the exchange - see http://www.kitz.co.uk/adsl/linestats_errors.htm

Whilst several close LoS will likely cause a resync.. Errors can be taken as an early warning system that all is not well and the line is is starting to struggle.
Full resync will occur when there is insufficient SNR across the subchannels for bitswapping process to maintain sufficient bits in the Bit Allocation Table.
http://www.kitz.co.uk/adsl/adsl_technology.htm

[HPsauce]

An intriguing point I've noticed is that if I have a "forced" resync the router stats almost always show LOF*9 and LOS*1 - maybe this is some sort of trigger threshold in my ISP's equipment? (Be)

[kitz]

lol I admit that sometimes I dont understand error reporting on some routers.

For eg when on adsl1 I noticed that my router without fail would always record 4 CRC errors during the sync up process...  and then it would stay like that for weeks/months without any more CRC errors. 
I'm only assuming here - but because during the sync up process certain stages occur, then at some point before full sync is achieved then these errors are recorded as part of the testing phase whilst it finds its sync/level.  Really dont know - sorry.

[Weaver]

> Contrary to some belief LoS stands for loss of signal rather than loss of sync. 

Aha. Cleared up some misunderstanding there on my part.

> Errors can be taken as an early warning system that all is not well and the line is is starting to struggle.

> Full resync will occur when there is insufficient SNR across the subchannels for bitswapping process to maintain sufficient bits in the Bit Allocation Table.

Indeed.

It's weird that the downstream rate actually goes up, so in a sense if its an error then its a lucky error. And if it's a serious error event the router should have logged something (you'd thing), but didn't.

Someone asked earlier about ADSL2+ - this is just ordinary BT Wholesale IPStream Max Premium, LLU not being available anywhere around here.

[kitz]

Someone asked earlier about ADSL2+ - this is just ordinary BT Wholesale IPStream Max Premium, LLU not being available anywhere around here.

IP Stream Max Premium is ADSL1
ADSL 2+ is whats used by most of the LLU providers (although not all of them enable it).  BTw's answer to adsl2+ is 21CN.

[Weaver]

I realised that what I wrote was possibly rather confusing. Blame my bad hands after a quarter century of keyboard abuse. :-)

I wrote
> Someone asked earlier about ADSL2+ - this is just ordinary BT Wholesale IPStream Max Premium, LLU not being available anywhere around here.[/quote]

I just read that back and it's very ambiguous, poor English. I meant by "this", that "_my service_ is just ordinary BT Wholesale IPStream Max Premium" and therefore afaik not more than ADSL1.

So when Kitz wrote,

>IP Stream Max Premium is ADSL1
>ADSL 2+ is whats used by most of the LLU providers (although not all of them enable it).  BTw's answer to adsl2+ is 21CN.

That was my understanding of it too. I also wondered though if any DSLAM chipsets are out there that now implement any odd features from a 'higher' standard above their baseline feature set. (Which happens with other software developments where developers sometimes go for "low hanging fruit" but can't managed to get an entire higher standard feature set implemented fully.)

[HPsauce]

I also wondered though if any DSLAM chipsets are out there that now implement any odd features from a 'higher' standard

The Be DSLAM's implement and use an extension to INP with setting INP=2 (whatever that means exactly).
Generally routers with Broadcom chipsets support this, other routers need a DSLAM setting change to get their best performance and even so do not usually achieve the same connection speed.

[waltergmw]

Hi HP,

Impulse Noise Protection is mentioned in a Draytec document dated July 2007, so it might be out of date:-

http://www.draytek.co.uk/support/kb_vigor_inp.html

>>>> If you are using any ADSL2+ compliant modem or modem-router which does not support the Broadcom-type extension and hence does not report a connection speed above 7.5Mb/s with INP settings of 2 or higher, your ISP can change the INP settings to be lower than 2. You are unlikely to notice any difference in performance (although latency may reduce slightly, which is a good thing!). An INP setting of 1 should be adequate, but you can request a setting of 0.5 or 1 if you have a good line and want the lowest possible latency (transmission delays). Connection speed does also depend on your line quality, so in some scenarios, your limited line speed may be due to physical limitations. <<<<

They also say that Be clients can request changes.

Kind regards,
Walter

[Weaver]

Update :

A day or two after the original sync rate change discussed originally, it happened again exactly as before. [Original stats in my other post, see http://forum.kitz.co.uk/index.php?topic=4024.0 ]

This morning I rebooted the router and just as originally, it decided to initially pick a "high" upstream sync rate of 608kbps, and then a couple of hours later was found to have mysteriously adjusted just as before,

* the US rate adjusted down from 608kbps, this time to 416, at a US SNR margin of 6dB, and as before,

* the DS sync rate went up a notch even further to a new high of 1920 with DS SNR margin initially around 11dB (+/-1dB occasionally).

I captured stats before and after, but yet again kicked myself for not capturing the bits-per-bin allocations in the first (608k) state although I did do so after the state change. Third time lucky, I'll try to remember to record everything. The second lot of data I is again pretty long and I can post it if needed. I will try and capture a third case though and do things properly.

[Weaver]

And since it looks now we're heading for a third example case today, I'll post the full results up as this time I finally did capture everything in the US=608 case for comparison.

It looks to be the case that after booting and the usual initiation and negotiation sequences that the router picks a set of US bits-per-bin that are all around 1 bit too high to arrive at US=608k with a reported initial SNR margin in "6dB" and will then go over to a new plan with US= ~400k with roughly the same _shape_ to the low bin allocations but with most of the values being 1 bit lower. So not as if there's some single frequency noise source appearing or as if there are a lot of high-noise frequencies that shift up and down, but it suggests that bitswap can't deal with it and it's noteworthy that the US SNR margin does not show a higher figure in the first state than after the change (although this router doesn't report fractions of 1dB).

I realise that I need to look this up. I'm assuming that bitswap doesn't permit the US-DS partition to move? In any case, it's true that in the previous cases the US goes down by 200k and the DS sync rate has gone up by 32k or 64k or so. It would be hoped that the router would display the appropriate number of US bins to show where the partition really is, and reflect the fact that that particular line is on the IPStream Max Premium service with its advertised higher cap on the max US sync of 832k compared to the more usual US cap of 448k for the home/home-office service.

I wonder if I’m seeing the effects of for having had this line too long through too much history, for having had it in operation since 2004 first in the days of pre-Max fixed 500k service, then getting a free upgrade to SOHO IPStream Max, then choosing oi move it over to the IPStream Max Premium service, and am wondering if I needed to ensure that it got pushed back into the 10 day training period so that the changed US-DS partition’s effects can be retested fully.