Technical question on bit swapping

[#1]

Yesterday evening my connection went bad with very high error rates for about 2 hours.
It then settled down but at about 1:00am the error rate went so high it lost sync and the rate dropped from 4256 to 3776 kbps.
The odd point was that while this was happening there was no downstream bit swapping at all taking place.
I rebooted the router this afternoon (4384kbps) and then initiated a resync in the early evening to get a sync speed of 4096kbps which should give me an IP profile of 3,500kbps eventually.
Since then there has been significant bit swapping and the line has been stable.
My question is whether the lack of bit swapping (which almost certainly caused the high error rates) was likely to be due to an exchange problem or the router.

[#2]

Oldjim,
Bearing in mind I've just given myself a 'crash course' in bit swapping, are you able to get hold of any logs from your router from before 1.00AM just to see what the SNR was like at that time?

[#3]

Well you did ask

Sat	18	Sep	2010	17:50:42	Rx-Noise=6.7	Rx-Sync=4256
Sat	18	Sep	2010	18:00:42	Rx-Noise=6.6	Rx-Sync=4256
Sat	18	Sep	2010	18:10:42	Rx-Noise=6.6	Rx-Sync=4256
Sat	18	Sep	2010	18:20:42	Rx-Noise=6.6	Rx-Sync=4256
Sat	18	Sep	2010	18:30:42	Rx-Noise=6.5	Rx-Sync=4256
Sat	18	Sep	2010	18:40:42	Rx-Noise=6.4	Rx-Sync=4256
Sat	18	Sep	2010	18:50:43	Rx-Noise=6.0	Rx-Sync=4256
Sat	18	Sep	2010	19:00:43	Rx-Noise=5.9	Rx-Sync=4256
Sat	18	Sep	2010	19:10:43	Rx-Noise=5.4	Rx-Sync=4256
Sat	18	Sep	2010	19:20:43	Rx-Noise=4.9	Rx-Sync=4256
Sat	18	Sep	2010	19:30:43	Rx-Noise=4.7	Rx-Sync=4256
Sat	18	Sep	2010	19:40:43	Rx-Noise=4.3	Rx-Sync=4256
Sat	18	Sep	2010	19:50:43	Rx-Noise=3.5	Rx-Sync=4256
Sat	18	Sep	2010	20:00:44	Rx-Noise=3.4	Rx-Sync=4256
Sat	18	Sep	2010	20:10:44	Rx-Noise=3.4	Rx-Sync=4256
Sat	18	Sep	2010	20:20:44	Rx-Noise=3.4	Rx-Sync=4256
Sat	18	Sep	2010	20:30:44	Rx-Noise=3.3	Rx-Sync=4256
Sat	18	Sep	2010	20:40:44	Rx-Noise=3.1	Rx-Sync=4256
Sat	18	Sep	2010	20:50:44	Rx-Noise=3.3	Rx-Sync=4256
Sat	18	Sep	2010	21:00:44	Rx-Noise=3.3	Rx-Sync=4256
Sat	18	Sep	2010	21:10:44	Rx-Noise=3.6	Rx-Sync=4256
Sat	18	Sep	2010	21:20:45	Rx-Noise=3.6	Rx-Sync=4256
Sat	18	Sep	2010	21:30:45	Rx-Noise=3.6	Rx-Sync=4256
Sat	18	Sep	2010	21:40:45	Rx-Noise=3.9	Rx-Sync=4256
Sat	18	Sep	2010	21:50:45	Rx-Noise=3.5	Rx-Sync=4256
Sat	18	Sep	2010	22:00:45	Rx-Noise=4.1	Rx-Sync=4256
Sat	18	Sep	2010	22:10:45	Rx-Noise=3.8	Rx-Sync=4256
Sat	18	Sep	2010	22:20:48	Rx-Noise=3.9	Rx-Sync=4256
Sat	18	Sep	2010	22:30:49	Rx-Noise=4.3	Rx-Sync=4256
Sat	18	Sep	2010	22:40:49	Rx-Noise=4.1	Rx-Sync=4256
Sat	18	Sep	2010	22:50:54	Rx-Noise=4.1	Rx-Sync=4256
Sat	18	Sep	2010	23:00:43	Rx-Noise=4.2	Rx-Sync=4256
Sat	18	Sep	2010	23:10:43	Rx-Noise=4.6	Rx-Sync=4256
Sat	18	Sep	2010	23:20:43	Rx-Noise=4.3	Rx-Sync=4256
Sat	18	Sep	2010	23:30:43	Rx-Noise=4.4	Rx-Sync=4256
Sat	18	Sep	2010	23:40:44	Rx-Noise=4.1	Rx-Sync=4256
Sat	18	Sep	2010	23:50:44	Rx-Noise=4.0	Rx-Sync=4256
Sun	19	Sep	2010	00:00:44	Rx-Noise=4.3	Rx-Sync=4256
Sun	19	Sep	2010	00:10:44	Rx-Noise=4.4	Rx-Sync=4256
Sun	19	Sep	2010	00:20:44	Rx-Noise=3.4	Rx-Sync=4256
Sun	19	Sep	2010	00:30:44	Rx-Noise=3.2	Rx-Sync=4256
Sun	19	Sep	2010	00:40:44	Rx-Noise=3.6	Rx-Sync=4256
Sun	19	Sep	2010	00:50:45	Rx-Noise=3.4	Rx-Sync=4256
Sun	19	Sep	2010	01:00:54	Rx-Noise=3.3	Rx-Sync=4256
Sun	19	Sep	2010	01:10:54	Rx-Noise=3.0	Rx-Sync=4256
Sun	19	Sep	2010	01:20:54	Rx-Noise=6.8	Rx-Sync=3776
Sun	19	Sep	2010	01:30:55	Rx-Noise=6.6	Rx-Sync=3776
Sun	19	Sep	2010	01:40:55	Rx-Noise=6.5	Rx-Sync=3776

[#4]

Hi Jim,
If I understand this correctly it seems that when your line resynched at 1.00AM it was at a lower sync rate due to increased noise on the line.
The general opinion here is that the issue could have been caused by anything that could create a general increase in  noise across all frequencies carried on the line, hence leaving no other frequencies available for bit swapping to take effect.
Personally I wouldn't be too perturbed by this but if it becomes a regular issue some diagnostics would be a good idea.

[#5]

Adam.
I know about that but it wasn't the question I was asking

Quote

My question is whether the lack of bit swapping (which almost certainly caused the high error rates) was likely to be due to an exchange problem or the router.

[#6]

Quote

The general opinion here is that the issue could have been caused by anything that could create a general increase in  noise across all frequencies

Sorry if I wasn't being clear, the above comment is my answer to that. A more straight-forward answer would be the exchange, the router or anything in between that could cause a general increase in noise.

[#7]

So the fact that there was absolutely no bit swapping recorded during that period (after an exchange initiated resync - at about 10:10 on the 18th) until I rebooted the router was due to a general increase in noise.
I am sorry I don't buy that
This picture is what I normally see as the system moves the bit loading about.

[#8]

REMOVE EDIT, AS ONLY TANGENTIAL TO MAIN DISCUSSION
Perhaps we need a new topic on NOISE: useful synoptic term for management, perhaps, but pretty well useless as a diagnostic tool?

[#9]

@Oldjim
A burst in noise probably wiped out too many tones for bit swapping to be able to cope, shown by the big loss in sync. In this situation the router may just resync all tones instead of attempting bit swapping. Alternatively, the noise may have increased across all tones and so no tones had sufficient SNR margin to take on extra bandwidth. I'd postulate the former was more likely. We'd only know for sure if we saw bits-per-tone loading graphs pre- and post- sync event.

[#10]

Ben
It wasn't the burst of noise it was the fact that there was no downstream bit swapping taking place when it usually does as the noise margin drops below 6dB. in the early evening.
I raised it on another forum and another poster advised that they had the same problem with a Netgear and he suspected that for some reason the router decided to stop bit swapping - you can do this manually with a telnet command.
However this morning my router suddenly lost sync twice in about 5 minutes for no apparent reason

Quote

Wed, 2010-09-22 11:31:31 - LCP down. Wed, 2010-09-22 11:31:38 - Initialize LCP. Wed, 2010-09-22 11:31:38 - LCP is allowed to come up. Wed, 2010-09-22 11:31:39 - CHAP authentication success Wed, 2010-09-22 11:34:19 - LCP down. Wed, 2010-09-22 11:34:26 - Initialize LCP. Wed, 2010-09-22 11:34:26 - LCP is allowed to come up. Wed, 2010-09-22 11:34:27 - CHAP authentication success

So I have bit the bullet and ordered another Netgear DG834G from Amazon (they had the best price with free delivery) and I will see what happens.
Also it will be interesting to see the effect of switching from a Broadcom chipset.
edit - just to save you asking the question - no I don't want a Thompson 

[#11]

I have recently used both dg834gv3 and dg834gt routers.
On my connection the v3's snr margin was up and down like a puppy on a lead,whilst the gt was constant and smooth as could be.
The 2 were chalk and cheese.
After several weeks i noticed the gt slowly reducing in noise margin,but never loosing sync.
So i investigated and looked at the router,one of the electrolytic caps had bulged,so i replaced the 3 main caps and all is well again,this is a well known issue.These caps smooth out the internal switch mode regulators.
The gt stays between 5.5-7db snr margin day or night week by week,i have resisted in using the snr tweek as it could be counter productive.
Now i have just replaced this fo a 2700hgv hub,with a few interesting differences.
The snr is not as stable,varies between 5-7db but sync's at 2496kb compared with the gt at 2432kb.
Also the gt had a ping test of 100ms approx and showed a download interleave depth at 16,never changed.
The 2700hgv initially showed pings of 47ms but increased to  120ms,but has now settled down to 56ms.
While the 2700hgv does not show interleave depth,i would guess this router accesses and adjusts interleave depth better than the gt router.
As i am on a long line with 62.5db attenuation i thought i would try out the 2700hgv as it has a good reputation for long line use,pity i cannot use dmt tool on it!
Oldjim i noticed a little while ago you gave a link to a plusnet  database regarding our own broadband connection info,this showed profile and detailed exchange info,i have been looking but cannot find it,please tell me that link again.
Also regarding bit swapping,on dmt tool on the gt,i noticed tones 46 and 58 reduced,especially 46.
Both these tones are lw transmission frequencies 46 being 198khz (radio 4),and 58 being 254khz (rte ireland).
As the adjacent tones 45/47 and 57/59 as affected by the am bandwidth of the transmissions,i notice constant bitswapping of these adjacent tones,this will be due constant varying am modulation of the transmitters causing the analysis of spare bits to be re evaluated.
Depending on what the sig strength of these 2 lw transmissions are to you,will of course alter the effect.
Paul.

[#12]

Did you mean this https://portal.plus.net/my.html?action=data_transfer_speed
Actually this one gives all the options https://portal.plus.net/my.html?action=myconnection

[#13]

Jim - I was postulating that the change in noise on the line occured in such a way so that bitswapping would not be able to replace the tones that were lost due to an overall increase in noise. This increase in noise was shown by the decrease in sync.
However, it sounds like the router may have just decided to give up on bitswapping so please let us know your findings!

[#14]

Thanks jim for the links.
Another note on bitswapping i noticed.
If i were to re sync in the afternoon,more tones are used  than if i were to re sync at midnight (increased mw noise etc).
As the higher tones drop away during the evening,and once unusable,they are disguarded,they are never then re used again for the same sync.
If the sync holds overnight,then the same reduced tones available are used,so their is less room for spare bit capacity during the day also.
Could it be that once the spare bit capacity is tight,the chipset gives up on bitswapping if any further snr reduction is seen ?
The only difference long term of same sync between day and night would then be existing tone snr difference,this could possibly make the difference if bitswapping was locked out or not in this situation ?
Ben just noticed your reply,are we possibly thinking from the same hym sheet ?

[#15]

I am not an expert - rephrase that I know very little of the intricacies - I read this http://www.kitz.co.uk/adsl/adsl_technology.htm#bit_swapping
What happened in my case is that the line resynched at about 6.3 dB in mid morning and normally as evening draws in there is fairly constant bit swapping over the available range to compensate for the reduced noise margin on some tones. in this case it didn't happen and the overall noise margin dropped from 6.3dB to 4 - 4.5 dB (the normal overnight range) but then carried on dropping down to 3dB overall which was effectively.unusable