Interpreting speedtest results

At some point today I'm supposed to have been LLU'ed, by Talk Talk, and should now be experiencing "upto 8meg", rather than the 2meg I've had upto now.
I don't see any difference, and my speedtest results seem to bear that out, although I never ran a test before.
Currently I'm getting between 1050 and 1062Kbps (Down) and between 191 and 207Kbps (Up)
Can anyone explain to me??

what are the modem sync speeds up and down ? you get these from the router status page or similar. Links in sig below may help.

Sorry I'm a total dork with this, and though I've looked on the router interface, I don't know what I'm looking for!
I've just connected with TT3, and went live last week using a speedtouch 585v6 wireessrouter, a used one from dsl depot, so no help there then!
I've been attempting to enable encryption WPA/PSK, supported by the router but I cannot find out if the Lan card in my PC also supports it, or indeed if it has to, it's an intersil prism, no model number or other distinguishing features mentioned on the properties screen.
Upshot is, I seem to have set up a Lan with my chosen SSID which was protected, alongside the generic Lan, speedtouch xyz... unprotected. Then found the computer could "See" the two of them but couldn't connect to the one with my SSID, and come hell or high water, would not look for the other one! even when I promoted it to the top of the "order of connections" list.
After loosing connection several times and taking 4 Hrs to re-connect the first time, I improved the next two times, 2hrs each but I've no idea how I achieved it. I'm learning nothing from the experience!!
Any words of wisdom?

See if your modem is in this list.

http://www.dslzoneuk.net/adsl_line_stats.php

Two LANs? Are you seeing a neighbours network? Change your SSID to something memorable like SIXHNET to eliminate this possibility.
The user guide for your router is available here.
I believe that your wireless adapter is capable of using WPA but it may need a driver update.

Do not attempt to set up the router over a wireless connection! Use a hard wired connection.

Edited by Deadbeat (Fri 27-Apr-07 22:47:38)

Thanks for that John,
This is what it points me at!
Perhaps it makes sense to you? : -


Link Information


Uptime: 0 days, 18:15:28

Modulation: G.992.3 Annex L Mask 1

Bandwidth (Up/Down) [kbps/kbps]: 245 / 1,213

Data Transferred (Sent/Received) [MB/MB]: 6.95 / 34.18

Output Power (Up/Down) [dBm]: 11.0 / 0.0

Line Attenuation (Up/Down) [dB]: 30.5 / 52.5

SN Margin (Up/Down) [dB]: 17.5 / 15.5

Vendor ID (Local/Remote): TMMB /

I'm afraid if up to 8 Mbps is a movable feast you are not at the banquet.

The most interesting figures are your sync rates, attenuations, and SNR Margins upstream and downstream.

For you these are 245 / 1,213 kbps, 30.5 / 52.5, and 17.5 / 15.5.

If you look here

http://www.dslzoneuk.net/adslmax_explained.php

you will see that your profile will be set at 1 Mbps if you keep that downstream sync rate. If it drops slightly your profile will be set to 500 kbps.

Check your internal wiring, it can make quite a difference.

http://www.dslzoneuk.net/socket.php


You may be better off with a fixed 2 Mbps link rather than Max ADSL.

Edited by deleted (Sat 28-Apr-07 00:00:34)

You may be better off with a fixed 2 Mbps link rather than Max ADSL.

- Supposing the BT Checker says they can get fixed 2mb, as their line is out of the fixed limits for 2mb now. Unless they can get TalkTalk to regrade them back to fixed 2mb.

If you look here

http://www.dslzoneuk.net/adslmax_explained.php

you will see that your profile will be set at 1 Mbps if you keep that downstream sync rate. If it drops slightly your profile will be set to 500 kbps.

They have been LLU'ed by TalkTalk so BT's profile system is irrelevant, hence why they could get about 1056kbps on a speedtest. If they were on ADSL MAX with a 1mb profile, speedtests would be around 900-930kbps, and no higher, just like on a fixed 1mb connection.

Edited by deleted (Sat 28-Apr-07 10:11:53)

I originally wrote 1 Mbps link but edited it to 2 Mbps when I noticed the original post mentioned being on that rate.

If you were definitely on 2Mbps before, then a possible reason for you now being down to 1.2Mbps is that in switching over they've put you on quite a high margin - 15.5 dB. You might try asking for that to be reduced to 10dB. The risk is that you'll see more errors, but at the moment your error rate is very low so there's room to experiment.

Probably of little interest to you, but your stats also show that TalkTalk are using reach extended ADSL2 (G.992.3 Annex L) for your connection which should actually improve things further as you have rather a long line (52.5dB attenuation). That's the first I've heard of any ISP using RE-ADSL2. It's a shame that TalkTalk's innovation with the use of ADSL isn't matched by their customer service.

In reply to:

---

If you look here
http://www.dslzoneuk.net/adslmax_explained.php
you will see that your profile will be set at 1 Mbps if you keep that downstream sync rate.

You may be better off with a fixed 2 Mbps link rather than Max ADSL.

---

There's no ADSL Max involved here so none of this applies! This is an Opal Telecom ADSL2 LLU connection.

He may still be better off on a fixed 2 Mbps link.

RE-ADSL2 should achieve a considerably faster connection than an a 2Mb ADSL1 one once it's correctly set up, especially as it won't be capped by ADSL Max IP profiles which can really slow things down in this range of speeds. Unfortunately the OP is going to have to battle with TalkTalk CS to achieve this. Anyway I'm afraid it's academic as there's no way TalkTalk will put the OP back on the BT 2Mb as it costs them considerably more.

Do you think they could squeeze much more out of that line? There seem to be quite a few errors at the current SNR Margin.

137 uncorrected errors in 18 hrs is very low. Most people don't notice 20 times this rate. Also the OP is saying that the line used to operate reliably at 2Mbps (which would have been ADSL1), so this must have been with a considerably lower margin. Assuming of course that BT haven't made a hash of connecting the line to the new DSLAM.

I was looking at the errors versus the amount of data transferred.

I don't know at what rate errors increase with sync rate but I wouldn't have thought it would be linear.

I haven't seen any graphs of error rate versus sync rate - they would be interesting (unless it is linear in which case they would be boring).

In reply to:

---

I was looking at the errors versus the amount of data transferred.

---

That's not an appropriate reference. The error rate is completely independent of the data transferred. It's a count of errors occurring in the channel regardless of whether the channel is transferring data at the time.

In reply to:

---

I don't know at what rate errors increase with sync rate but I wouldn't have thought it would be linear.

---

At the risk of sounding like National Rail, it all depends on the sort of noise! In other words you can't tell until you try it. Again though, we know the line has operated on 2Mbps successfully on a less efficient version of ADSL, so it should comfortably be able to operate at 2Mbps on RE-ADSL2.

Well! I'm mesmerised by all this technical talk!!
My one brain cell seems to be telling me that I'm probably on an 8meg line now.
I was possibly better off on the old BT 2meg line.
Encountering the TT customer service experience will probably be futile and painfull!
Final Questions,
Will I notice the difference?
will it restrict my use of the net?
Lastly, Thankyou all for the professional scrutiny, and your time and trouble. It's appreciated.

In reply to:

---

That's not an appropriate reference. The error rate is completely independent of the data transferred. It's a count of errors occurring in the channel regardless of whether the channel is transferring data at the time.

---

Not sure that I understand that. The errors such as FEC and CRC are checksum errors on the data transferred.

In reply to:

---

Well! I'm mesmerised by all this technical talk!!

---

Apologies - point taken! Yes, you can definitely say that you've transferred to TalkTalk's 'up to 8Mb' service, and that the improved technology they use on this service should be able to achieve a better speed than the 2Mbps you had before. Unfortunately they currently appear to have configured the new service so that this is not the case. The 'noise margin' is the parameter in question. This is set by the ISP as a compromise between line reliability and speed. The higher the margin then the better reliability but the lower the speed. What I think from your stats is that they've set this far too high.

You can either ask them to lower it, or a possible alternative would be to ask them to set you on a fixed 2Mbps on the new service. The former gives you the possibility of exploiting the improved technology to go to even higher speeds. The latter is probably simpler to ask for.

Hope that makes more sense!

Nope, they're errors on the channel. The channel operates continuously at the sync speed, regardless of whether there's any data to actually transfer. Essentially what happens is that dummy bytes are used to fill in the gaps when there's no real data bytes to send. This allows the FEC and CRC counts to be used to determine the reliability (at a particular margin) continuously, regardless of how much the line is actually being used. All you need to take into account is the time period.

You may notice a difference if the download speed stays as it is, not in general browsing, but if you view video streams and download large files.

It will not restrict your use of the net except as above.

A lot of threads veer off topic. If anything this thread was not too bad as it at least was mainly addressing your line problems.

I hope six_h gets fixed up OK and thank you all for a most interesting thread. I certainly can't say that I understand it but I think it has answered some of the questions I haven't dared to ask so far! Great stuff.

In reply to:

---

The channel operates continuously at the sync speed, regardless of whether there's any data to actually transfer. Essentially what happens is that dummy bytes are used to fill in the gaps when there's no real data bytes to send. This allows the FEC and CRC counts to be used to determine the reliability (at a particular margin) continuously, regardless of how much the line is actually being used. All you need to take into account is the time period.

---

I didn't know that and I also take the amount of data transferred/received into account as well as the uptime!

would ReADSL help with a line capable of 4M or so on ADSL2+ ? as "READSL focuses a higher power density within a constricted downstream and upstream bandwidth (narrowed frequency usage, same total power)" I was of the opinion that it has a limited speed capability and should only be used on long lines where otherwise there is no service or a really slow one. Sounds like T-T have the OP on the wrong profile.

Yes, the channel does operate continuously. But you are assuming that errors in idle cells are counted in the reported error statistics. My own modem does not appear to do this. I can leave it on for six hours and see no errors. I then download 500 megabytes and see 30 or so FEC errors and a couple of CRC errors, say.

In reply to:

---

But you are assuming that errors in idle cells are counted in the reported error statistics.

---

I'm not assuming anything. Perhaps it would help to explain the layers in ADSL. At the bottom you have the G.dmt layer itself. This layer provides a continuous byte stream channel service (eg: fast channel or interleave channel) to the layer above. The layer above is ATM. It's ATM that delineates the chosen channel byte stream into cells, and provides a data packet service to the next layer above. The next layer above might be PPPoA or ethernet for example.

When ATM is given a data packet to send, it fragments this into ATM data cells. When it doesn't have anything to send, it pads with ATM idle cells.

Now the point of all this is that the CRC and FEC handling is all part of the G.dmt layer. This layer is completely oblivious to where the cells are in the byte stream, never mind which cells contain packet data. So in fact an FEC codeword typically contains a number of cells, including cell fragments at the start and end, and these cells might be a mix of data and idle. FEC has absolutely no idea. Similarly for the superframes on which the CRC is calculated.

Make sense now?

In reply to:

---

would ReADSL help with a line capable of 4M or so on ADSL2+

---

Well, as always it depends on the line noise. If the noise is such that only the lower channels are usable, then yes ReADSL2 will help by increasing the power on these channels. Alternatively it is certainly a possibility that the choice of ReADSL2 has prevented use of upper channels which otherwise would have allowed a higher speed. Difficult to tell. The Annex L downstream mask supports increased power all the way up to 552KHz, ie: about half the channels, although I don't know whether BT restrict this.

Annex L should ideally be turned on automatically (if supported by both ends) during negotiation - in other words the modem should decide whether it's beneficial. Still I guess it's possible that the DSLAM has been configured to force it.

Anyway, the fact that there's 15.5dB of SNR to spare suggests that even with the channels that the modem is working on it is capable of a considerably larger speed. With only half the channels in use, a 5dB margin drop will increase the sync to 2Mbps.

Yes, that makes perfect sense.

It's just unfortunate it doesn't tally with my limited practical experience. I can leave the router on all day but unused and very few, if any, errors accumulate. However when I transfer lots of data errors do accumulate, apparently at a much higher rate.

One possible explanation for this is that your PC might itself be causing more noise on the line when it's working, transmitted either via the mains or wirelessly. Computers are electrically very noisy beasts, especially when they're working hard. (Memories of when engineers used to use ordinary MW radios as a diagnostic tool to monitor the processing on mainframes... )

PS - or it might even be a slightly suspect router. Routers have been known to generate their own noise. All it takes is for the isolation between the line front end and the router CPU to be below par.

Edited by cahaddras (Sun 29-Apr-07 13:37:02)

I'll have to see if I can quantify the effect I think I am seeing.

I'll start logging error counts against time and compare with my usage patterns to see if it's all in my mind or not.

I just had a browse in the TalkTalk forum, and it seems that some posters have been asking for their noise margin to be dropped from 15dB to 9dB with very successful results. So it looks like at least some people in their customer support team must understand how to get this done for you. Why not give it a try, and post back here with the results.

Just came back to this and found this chart, showing a typical effect of Annex L in yellow. Whilst you always need to take these general charts with a large pinch of salt for any specific case, 52.5dB attenuation puts the OP around the 4 - 4.5km mark which is comfortably within the range benefited by Annex L. The actual stats suggest that this is quite a noisy line as well, so this would tend to push the OP further into the beneficial range.

useful chart for relative expectations, thanks.