Kitz Forum
Broadband Related => ADSL Issues => Topic started by: willbard on March 19, 2017, 05:11:15 PM
-
I am on a long line (BT measured at 9.2 km in 2006 when bband implemented). Speeds are slow but reliability has been OK. Last October work was started locally preparing for FTTP. Coincidentally my bband connection lost reliability at about this time and was down completely for more than a month but since January has been up more than down. My query is about synchronisation speeds. I'm used to seeing Up/Down speeds such as 576/288 but since the end of Feb they have become, to my eyes, odd but I don't know whether this is significant. Examples are (RX/TX, down/up) taken using routerstats and checked by logging in to the router (Thomson TG 582)
498/611, 398/595, 523/603, 608/579, 771/587, etc.
There have been at least 16 different synchronisation pairs since 28th February with the most recent from earlier today at 787/611. Incidentally this followed a brief telephone line drop immediately after a phone call ended - synchronisation was within a minute or two of the line being restored.
The router is connected to the master socket via a BT faceplate.
Are these speeds normal or do they suggest a particular kind of fault?
-
I'm guessing that you used to be on a fixed rate service using ADSL1.
It looks like you're now on a rate adaptive ADSL2/2+ service, so you'll get whatever speed your line can manage at the time it connects. All the different speeds look normal.
-
Many thanks.
I didn't know enough to realise the speeds were normal and was surprised that so many were not multiples of 2. Any service change hadn't been communicated to me but that doesn't matter as long as I have a connection.
-
Welcome to the forum.
Can you put some details of your exchange http://www.dslchecker.bt.com/ but remove your phone number before posting.
also some router graphs/stats etc..
Have you notice it dropping out when the phone was used before ? when I had a HR joint
( http://forum.kitz.co.uk/index.php/topic,4620.0.html ) I had problems of loosing sync.
-
Sounds like you are on adsl2 on a 21CN exchange, like me. My lines are around 7.3km by road, but I recently read some note by BT that suggested 8km (is that correct from those field notes, Kitizens?) my downstream line attenuation is ~65 - 67 dB. I think your speeds are not too far off for the length of line. My ADSL2 speeds are far higher at 2.7 - 2.9 Mbps downstream sync rate. I have a number of advantages:
* shorter line,
* if I remember correctly it has been suggested that I enjoy very thick copper,
* I would also be amazed if my noise levels are not extremely low relatively speaking because of the lack of electrical activity or civilisation along the last so-many miles (the most critical ones) of the route,
* aggressive modems,
* zero house-internal wiring, no extensions, no phones, and no filter at all,
* totally over-the-top mains-filtering, for what it's worth, if anything,
* Burakkucat's no-ADSL2+-tweak (below) possibly,
* 3dB downstream target SNRM, which is just cheating, trading reliability for speed.
Faster modems might do better, and my own preferred DLink DSL-320B-Z1 modems are very cheap at ~£15 and so if you wish to give one a try then it's only a small financial risk. These are (should be) modem-only devices, not dsl routers, so you will need a router of your choice (with the usual firewall + possibly NAT and maybe wireless too) to go along with it - a two-box system.
These modems are available pre-configured for safe ADSL1/2/2+ operation as modem-only devices from the Andrews and Arnold shop, https://aa.net.uk/broadband-accessories.html. Do not use one of these devices as a combined router plus modem as they have horror security holes, and even with those fixed (poss so with firmware v1.06) they are very bug-ridden and crap as routers so I have been warned. The config will work with any ISP and no login details details are required, you just plug them in and they will work. If you get one, ask about securing the LAN-side admin http interface if the modem is accessible from your main LAN through your router.
However, to get the best out of them, I would strongly suggest that you tick the BITSWAP tickbox in the advanced ADSL config menu, as for some reason AA are neglecting to do this, and neglecting this should really stuff performance / reliability, unless AA know something I don't about a bug in the UI. If you get hold of one, ask for help with this tweak if needed. A second tweak: Burakkucat has suggested, reasonably, I think, that it might be an idea to also change the advanced ADSL auto-dsl-mode setting to be ADSL2-only, which he and I have done.
By the way, are you on LLU? Who is your ISP?
-
Thanks both for the information & suggestions.
My exchange is Llanymynech, cabinet 6 & attached is the info from dslchecker.bt.com
Also attached is current Stats summary from RouterStats
The line has dropped before when phone used but this is eceptional rather than usual.
I need a bit of time (& knowledge) to digest all yr comments, Weaver, but thanks for them & I will be following them up.
BT are due on Wednesday to measure the line length so I'll wait and see what happens after that. Things seem to have settled down a bit now - it was just what seemed like odd sync speeds that I'd not seen prior to the beginning of Feb. that prompted my original query.
Don't know re adsl2 but 21CN & LLU apply (I think). ISP currently Plusnet.
-
https://www.samknows.com/broadband/exchange/WNLMY
-
So since you are PlusNet I presume you are not LLU? Is that correct? Don't know anything about PlusNet, but I'm just assuming that will be BT Wholesale.
It says on Samknows that there are Sky and TalkTalk Wholesale LLU lines available.
-
Looking at the displayed statistics I see --
DSL Type: ITU-T G.992.3
So that tells us that the circuit is "trained" and "up" as ADSL2, just as Weaver has advised.
-
It's unusual how good your upstream is, wish my upstream sync rates were that good.
-
I'm assuming this line has no interleaving from the zero FEC counts.
On my line, setting interleaving to always on rather than auto did reduce the upstream rate slightly. The amount of FEC/interleaving on the downstream is probably about the same as on auto, but I think it puts much more on the upstream than auto did.
Although it's all BTWholesale, there are different manufacturers of the exchange equipment, which could also contribute to slight differences in performance.
-
> setting interleaving to always on rather than auto did reduce the upstream rate slightly.
Weird. That's interesting. Why should that be?
-
The usual minimum INP values set are INP=1 for the downstream, and INP=2 for the upstream. Interleaving set to auto operated the upstream with little to no interleaving plus some FEC. I guess to achieve INP=2, there's a lot more FEC data using up the bandwidth, although I lack stats with all the framing parameters.
While looking back at old stats, it did also remind me that how good a modem is on the downstream does not necessarily match how good it is on the upstream.
-
It is interesting for me to read through the above posts, and thank you for them, and makes me realise how little I know about some of the technicalities of broadband connection. It was the strange, to me, sync rates coupled with unreliability that triggered my initial query. Speed is obviously not unimportant but continuity of connection is more important first.
For the 6 weeks up 28th Feb synchronisation was always 576/288 kbps Down/Up although there were frequent breaks in service including one of several days.
Since 28th Feb there have continued to be frequent breaks but, so far, at least 19 different sync. rates although the last few days have been a bit more stable. The current Down/Up is 811/619 kbps has been unbroken for 26 hours. Fingers crossed & we'll see what BT have to say following tomorrow's visit to measure the line length.
Again, thanks for the various comments. Much appreciated & I'll keep learning
-
P.S.
I had to laugh - 5 minutes after my last post we had a power cut of about 2 hours duration. At least sync was quick when power restored. For interest here is the log extract:
Jan 1 00:01:17
xDSL linestate up (ITU-T G.992.3;
downstream: 630 kbit/s, upstream: 643 kbit/s;
output Power Down: 15.1 dBm, Up: 12.6 dBm;
line Attenuation Down: 74.5 dB, Up: 41.1 dB;
snr Margin Down: 3.3 dB, Up: 6.0 dB)
-
That downstream attenuation is enormous compared with mine. You win an award.
It's amazing seeing an upstream almost as fast as the downstream. I don't get nearly that performance.
-
I don't know how quickly those statistics were harvested one the power was restored but I note that the DS SNRM is showing as 3.3 dB.
-
I can't claim any (knowing) influence on the downstream attenuation so any award is just luck.
Engineer visit today said line too long and I'm probably the last property in the lane to be able to get broadband. But we'll leave things as is for the moment. Fibre imminent!
The stats were harvested almost immediately after power restored (within a few minutes). Since then speeds have dropped a bit but at least the line is holding and the engineer tells me there is tweaking that can be done if the instability returns.
The current stats below & I've now got used to what I thought were the peculiar speeds.
Link Information
Uptime: 0 days, 9:31:19
DSL Type: ITU-T G.992.3
Bandwidth (Up/Down) [kbps/kbps]: 603 / 623
Data Transferred (Sent/Received) [MB/MB]: 75,65 / 473,97
Output Power (Up/Down) [dBm]: 12,6 / 0,0
Line Attenuation (Up/Down) [dB]: 41,3 / 74,5
SN Margin (Up/Down) [dB]: 6,9 / 2,8
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / IFTN
Loss of Framing (Local/Remote): 86 / 0
Loss of Signal (Local/Remote): 11 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 610 / 4
FEC Errors (Up/Down): 0 / 0
CRC Errors (Up/Down): 57 / 598
HEC Errors (Up/Down): 49 / 283
-
I can tell you no further improvements can be made on your E-side cable (the cable from Exchange to Cabinet), as can sometimes be done.
Your particular Cab has just the one cable feeding it, as opposed to some others that may have up to 5/6 different cables feeding them.
These cables are made up of different poundages (thickness) and are generally a hybrid of Copper and Ali metal. Copper has a better resistance value than Ali, and therefore generally a cable made up of as much Copper as possible, will provide better speeds than one made up of mainly Ali.
Fingers crossed for FTTC coming to you soon. :)
-
Thanks again for the various comments. It's been very helpful and I've learnt a lot and won't take up any more of your time.
The engineer here a few days ago was very patient and helpful, found one or two dodgy bits and fixed them and things seem to be more stable now. Current stats are;
Uptime: 1 day, 10:13:52
DSL Type: ITU-T G.992.3
Bandwidth (Up/Down) [kbps/kbps]: 635 / 826
Data Transferred (Sent/Received) [MB/GB]: 154,71 / 1,10
Output Power (Up/Down) [dBm]: 12,8 / 0,0
Line Attenuation (Up/Down) [dB]: 41,5 / 73,0
SN Margin (Up/Down) [dB]: 6,2 / 2,6
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / IFTN
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 2.589 / 0
FEC Errors (Up/Down): 0 / 0
CRC Errors (Up/Down): 184 / 4.670
HEC Errors (Up/Down): 79 / 3.279
-
Compared with the previous data set, the latest set of statistics shows an improvement.
[Duo2 ~]$ sdiff 20170323-stats.txt 20170325-stats.txt
Uptime: 0 days, 9:31:19 | Uptime: 1 day, 10:13:52
DSL Type: ITU-T G.992.3 | DSL Type: ITU-T G.992.3
Bandwidth (Up/Down) [kbps/kbps]: 603 / 623 | Bandwidth (Up/Down) [kbps/kbps]: 635 / 826
Data Transferred (Sent/Received) [MB/MB]: 75,65 / 473,97 | Data Transferred (Sent/Received) [MB/GB]: 154,71 / 1,10
Output Power (Up/Down) [dBm]: 12,6 / 0,0 | Output Power (Up/Down) [dBm]: 12,8 / 0,0
Line Attenuation (Up/Down) [dB]: 41,3 / 74,5 | Line Attenuation (Up/Down) [dB]: 41,5 / 73,0
SN Margin (Up/Down) [dB]: 6,9 / 2,8 | SN Margin (Up/Down) [dB]: 6,2 / 2,6
System Vendor ID (Local/Remote): TMMB / ---- | System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / IFTN | Chipset Vendor ID (Local/Remote): BDCM / IFTN
Loss of Framing (Local/Remote): 86 / 0 | Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 11 / 0 | Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0 | Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): - | Loss of Link (Remote): -
Error Seconds (Local/Remote): 610 / 4 | Error Seconds (Local/Remote): 2.589 / 0
FEC Errors (Up/Down): 0 / 0 | FEC Errors (Up/Down): 0 / 0
CRC Errors (Up/Down): 57 / 598 | CRC Errors (Up/Down): 184 / 4.670
HEC Errors (Up/Down): 49 / 283 | HEC Errors (Up/Down): 79 / 3.279