Print

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

[renluop]

There seem to be in Kitz and elsewhere some mention of the TP-Link getting very hot. Sheddy.. was one such commenter, IIRC.
Does that still apply?

Eric, ou mention "low cost", what would lie between that and "high cost"?

Edit: I see the HG622 mentioned as VDSL, were it to be found new or used, is it also ADSL too?

[roseway]

I've no personal experience with the TP-Link, so I can't comment.

There's the Billion 7700N, which is a slightly cut-down version of the 7800N. As far as I can see, 'cut-down' merely means that it has 10/100 ethernet ports in place of the gigabit ports of the 7800N. Not something which will affect you unless you have a very busy home network.

The HG622 covers ADSL as well as VDSL2. I use one myself on an ADSL2+ connection from time to time, and there are others here who also do.

[renluop]

They're probably not worth that much now, but graphs etc for 24 hours from 15:30 yesterday are attached in a zip.

[renluop]

PN have agreed a SNR reset as connection has looked clean recently.

Thanks for all your comments.

[kitz]

Apart from noise, is there anything else that might be the cause of the erratics.....router (TG582N) playing up....overheating. The base feels warm having been on from late last night to now, but not uncomfortably so. i Have a TG 585 v7 I could try.

Not really, although it has been known in the past that some router f/wares have been less efficient with bit-swap.  Why this should be I dont know as the algorithm should be similar across the board, so possibly a bug.  Some routers are warmer than others not necessarily anything to do with bit-swap, although if the router is performing lots of bit swapping then the processor will be working hard and will contribute to heat.

Bit swap could be seen as a first line of defence against brief burst type noise spikes.  Without bit swapping most lines would see a lot more errors and loss of syncs.   The tones where the most bit swap occurs should mirror the tones where SNR is lost from.  For example when I had the line fault which affected my U0 channel, then thats where all my bitswap was happening, and none in the higher frequencies.  You can also use the bitloading graphs to see where noise has been problematic.. again an example would be on my line, that after a while U0 would have no bits loaded as bit-swap had shunted all the data to be distributed & transmitted over higher frequencies.

[renluop]

Thanks for that interesting info.

Last night- this morning telnet showed there had been 9 resets, and from graphs there were shown 2 resyncs which brought speed down from 7331/888 to 6727/792 kbps and some heavy fluctuations in u/stream SNR.

Me thinks it's time test socket, and a suicidal Ethernet run up to spare room.