So to get this straight... (just read the Wiki stuff too)... turning off interleaving is good for VOIP purposes, but you may get some packet errors in your data? The TCP/IP stacks will take care of that anyway, so unless the errors are very bad, it won't matter??

In practice, you aren't likely to get significant packet errors on your line unless:

a) It's of bad quality with poor joints and/or interference picked up from other sources in the cableb) You are a long way (say 4km or more) from the exchangec) You have poor quality wiring in your house e.g. faulty splitters or sockets, phones connected without filters etc.

If you check the Noise Margin and Attenuation figures from your modem according to my post above, you will see whether you are being affected by any of the above factors.

Packet loss, jitter and out of order traffic in addition to latency are all factors in VoIP quality and trading off 50ms of latency when you sitting on 60ms only to get 5% packet loss because a dsl feq bin decides to get intermittent issues and not kill itself is a pretty crappy deal.

Lowering latency will also increase your TCP/IP throughput potentially if other factors remain the same as the bandwidth delay product decreases.

Also regarding peoples comments on redirecting to google, it is considered common courtesy to attempt to do something yourself before asking others. You will find people are generally much more helpful if you have demonstrated some attempt to understand the topic yourself. This is not meant to give offense, it is offered as a cold hard fact of life.

Yeah, good point Fraktul, the statement in the post you referred to was an oversimplification...

I realise that UDP is a "best efforts" service and its delivery is not guaranteed by the TCP layer of TCP/IP. Nevertheless, the TCP layer does its job where it is vital i.e. in HTTP and FTP transfers among others.

Excuse my ignorance, but what is a dsl feq bin?

I did have a look on Google, and it had this to say:

scalar (single-tap-per-bin) frequency domain equalizer. (FEQ)Coefficients utilized by a FEQ or TEQ are normally obtained through the ADSL standard

So it looks like a FEQ is an Equalizer which operates in the Frequency Domain as opposed to the Time Domain.

But this doesn't shed any light on what the "Bin" has to do with it.

Is this equaliser made from analog circuitry or is it simulated using a DSP (Digital Signal Processing) device?

If it is analog, then your comment about "intermittent issues" would make sense, but a DSP device is digital, so you wouldn't expect it to develop such issues.

Could you explain it a bit more for the benefit of lesser mortals like me?

AFAIK RA-ADSL is compromised of frequency "bins" which are units/ranges of frequency that when summed provide you with the bandwidth over which ADSL modem operates. I think 'feq' was missing the letter r in fraktul's post.

Sorry that should have been freq (frequency) bin. You can have intermittent issues with a specific or range of frequency bins without this reaching a threshold to remove these from service.

Of course interleaving greatly reduces the chance of non correctable frame corruption due to the spread of a frame over greater time (by interleaving it with others) meaning very short duration reductions in SNR in a particular frequency bin are less likely to cause frame loss and longer duration SNR reductions will result in the bin(s) taken out of service.

Also, interesting to note that TCNZ has interleaving off by default on SHDSL services.

Cheers Guys, that Wiki article on G.992.1 is an excellent introduction to the workings of DMT signalling. Certainly much easier to follow than a paper published by Cornell University that I was battling my way through.

Yes Fraktul, I can see what you mean about the way noise bursts could occur within a given time slot or frequency range (bin), thereby causing problems with UDP datagrams which would be corrupted or lost completely.

In the light of this, I think that Telecom had the right approach here:

==> Enable Interleaving by default so that the maximum amount of errors are corrected without broadband customers needing to do anything

But rather than insisting that Interleaving must remain on, I think that XNET have the right approach here:

==> If customers have a good clean line with excellent transfer speeds and want to try it with interleaving turned off, allow them to do so, with the proviso that interleaving be turned back on again if problems occur.

In my case, I haven't noticed any change in the VoIP quality over a non-interleaved line. Possibly this is because my VoIP boxes are quite old and use the H323 protocol with quite a lot of buffering.

However, what has improved is the responsiveness using VNC. Movement of the mouse pointer is now more fluid than before, and I have also noticed far fewer VNC timeouts than I had previously when using a Paradise Net connection with interleaving.