After a lot of research I discovered that what I wanted to do apparently has to be done at the DSLAM which is a pity, here's an article which I think many people may find interesting. If for example, I were to ask telecom nicely, would they do as other ISP's have done around the world and remove interleaving for just myself? Or at least reduce it to a much lower level, as I understand it Telecom New Zealand set it to 30 ms but I could be wrong. For a very prolific quake player I can tell you that 30 milliseconds makes all the difference. Ping is the *sole* reason why we have ADSL, there are no other solutions for where we live that are within our budget (Palmerston North) that come close, although I suppose if I was in Wellington I could simply get cable which sports 30 ms like pings... in any case I hope some lovely person from Telecom reads this and considers my request. If we had to sign something to get it done then we wouldnt' mind doing that ;). The URL is here: http://www.dslreports.com/shownews/205, sorry for posting the whole thing here but I thought it would be more convenient.

In addition... this URL here leads me to believe that this can be done on a per customer basis, in which case if the customer is happy with the change, should it not be doable? http://www.dslreports.com/shownews/439

Latency and Interleaving
For internet telephony or interactive applications such as remote administration over a telnet session, latency is a key (and much discussed) attribute of the connection.

At the moment, the class of users most obsessed with latency would have to be the online gaming community. They are often buy entry level residential ADSL lines, with high download speeds, and are dismayed to read that friends on slower SDSL or IDSL lines are getting better ping times!

The first reaction of a disappointed gamer is to blame the ISP for routing inefficiencies or congestion, and although that is often the root cause, there is more to latency than just many hops and/or long distances.

ADSL modems commonly employ data Interleaving, which is a technique to increase resistance to noise bursts on a line. Interleaving "smears" out micro bits of data (interleaves them over time) so that a short burst of signal destroying noise can only remove part of any given larger block. Data blocks reserve some space for error-correction data.. which can salvage a partially damaged block. Interleaving increases the chance that noise on the line will only cause partial damage, not complete loss. Thats the good news.

The down-side of Interleaving is that it increases latency! this is because your little (say) quake movement packet is smeared out over several packets before it can be fully sent or fully received.

ADSL modems with typical Interleaving defaults can be 10-30ms behind in latency over equivalent speed SDSL modems... this means latency to any point for some ADSL modems can be at best 50ms! On the same setup, the aforementioned SDSL modems that typically add only 10ms. So for use of a nearby server, ADSL Interleaving can be the biggest single source of latency that you have.

Unfortunately, there is little clear information supplied with, or available online, about what latency a given DSL modem or ISP connection has built-in.

Some ADSL modems allow the user to turn off Interleaving, or turn it down to a narrow range, at the expense of possible data-loss on noisy lines. The Cisco 675, for example, has a full operating system inside it, and one of the attributes of the ether interface is Interleaving. See Randy Lutton's US West page). Some ISPs may be delivering this unit with Interleaving on, and some off. In other cases, it is the DSLAM (central office equipment) that has the Interleaving set, and this cannot be changed.

Regards,
Anton Smith
Silicon Dreams Hardware News and Reviews,
http://www.challenge-nz.com/silicon-dreams

This message is part of the NZ ADSL mailing list.
see http://unixathome.org/adsl/ for archives, FAQ,
and various documents.
To unsubscribe: send mail to majordomo@unixathome.org
with "unsubscribe adsl" in the body of the message
Received on Fri Nov 24 02:42:14 2000