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)