Adsl Speed Consistency, Or What...

[Priceless]

I have recently had some "interesting" experiences trying to use Skype. Not their fault though, I'm on TOT... After my latest three interrupted calls within 10 minutes, I used the TV Speed Test and came up with the following results on my "Gold Cyber" subscription. (It is supposed to give me 1024/512 kbps.) The results are from tonight, April 8.

Time / Downstream / Upstream

21:56 / 254 / 123

21:57 / 856 / 419

21:59 / 239 / 122

22:01 / 856 / 419

22:03 / 270 / 122

Can anybody come up with a plausible explanation as to why the speeds should vary like this? Since ADSL is built on several users sharing a certain bandwidth, I can understand why speed will go down in the evening with high loads, but why should it behave like a yo-yo ?

Edited April 8, 2007 by Priceless

[monty]

There's several factors influencing the quality of VOIP connections. Speed is only a part of it and as long as you have 128kbps either way you should be fine.

Packet loss, jitter and QOS are things which seriously mess up VOIP if they are not up to scratch. Basically they indicate how steady the stream of data can flow. Which most probably is not good on your ADSL.

http://myspeed.visualware.com/voip/

This test specifically checks the factors important to VOIP connections...

[Priceless]

There's several factors influencing the quality of VOIP connections. Speed is only a part of it and as long as you have 128kbps either way you should be fine.

Packet loss, jitter and QOS are things which seriously mess up VOIP if they are not up to scratch. Basically they indicate how steady the stream of data can flow. Which most probably is not good on your ADSL.

http://myspeed.visualware.com/voip/

This test specifically checks the factors important to VOIP connections...

Except that I would include packet loss, jitter and some more in QoS (Quality of Service) I agree fully with what you say. All these factors are probably WAY out of what is acceptable, but I was really baffled by the "pulsating" speeds. Have you got any idea what could cause it? (In spite of 20 years in tele-/datacomms I'm not a technical guy.)

[Guest Reimar]

You should check the local connection speed as well. Most of the time the local speed is stable and fast. The international is the problem an I think that the international connection from TRUE is better than all other which running via TOT/CAT/Internet Thailand on other not using the TRUE Gateway!

And funny enough, even IP-Star is using the TOT Gateway! IP-Star user connect to Seattle for example from their comp via Satallite back to TOT and than via land/Sea line to US!! At the time I was using IP-Star, last year from April til August I trace the route that way!

[OlRedEyes]

I have CAT and TT&T, normally very slow in the day and eve, but also varying greatly, or 'pulsing', well, like 15 min pulses.

But since 2 days ago it been great and steady. Wonder if blocking youtube helps

[autonomous_unit]

As to the question of why this might happen... you have probably observed a public-address system generate "feedback" before, where a microphone picks up a sound from one of the speakers and it goes back through the amplifer, eventually generating a loud, high-pitched noise? Or you've been stuck in a traffic jam and finally come to the head of it where traffic thins out, only to see that there is no obstruction, but the traffic has formed a memory of a previous obstruction, passed from car to car through the flashing brake lights and over-reactive drivers?

Well, the same feedback principle can go into action in networks when there is a load that reacts to the behavior of the network. Instead of there being an amplifier re-generating the signal, there may be thousands of poorly behaving clients who attempt to gobble up bandwidth until something in the network breaks. Then, they "back off" and after a delay they try again. This pulsing could be the result of such a feedback cycle, repeatedly overloading some part of the network. To make matters worse, if the network also tries to respond to this overload condition by adjusting itself, then you can get a stronger tug-of-war between the client and network changes. Another real-world example would be fans stampeding a stage at a concert, or clogging exits in a evacuation... often the crowd will heave forward and back because people "retry" en masse.

There is a bit of art and science to trying to minimize these effects. Most Internet protocols and clients are carefully designed and analyzed with statistical models meant to have good behavior, for example having randomized back off so that everybody does not try to rush the gates again each time there is a blockage. Instead, some will try earlier and some later, so that a smoother flow of clients retrying over time. There is also work done by the network providers to try to filter and smooth these spikes by carefully tuning the way the network responds.

Quite likely, something at your ISP is misconfigured and unable to smooth these spikes among the users. I think that a poorly configured traffic shaper could do it, if it is too aggressive about shutting down flow and then quickly resetting to a fast rate (it would be much better to shut down gradually and take longer to open back up, so that client applications will adapt to a new steadystate bandwidth). In the past, I've observed much slower pulses (15-30 minute cycle time) when something called "route flapping" occurs; in this case, some misconfiguration causes the ISP to misroute traffic for a while, and then restore it. Often, these route flap events will affect one set of destinations, and then another, and so on in a cyclic manner; and this can be triggered by different ultimate causes.

By the way, the reason behind partial power blackouts is from the same problem. If the power system is overloaded and shuts down, turning it back on with all of the existing (too high) load will just cause repeated failures. So instead, the power grid shuts down some areas to bring the total load into an acceptable range for the generating capacity. A brown-out would be when they just let the overload continue, and the supply voltage drops until nobody gets proper clean power! I hope you can see the analogy to how the overloaded Internet capacity can be shared by brownouts for everyone or rotating blackouts for a few, etc. Whereas we'd probably prefer blackouts to brownouts with electrical power, we probably prefer smooth brownouts with the Internet.

[monty]

I'll try to recap autonomous_unit's (most probably correct) explanation in 3 words

Poor Bandwidth Management...

[Priceless]

I tend to agree with Monty's diagnosis of the problem... However, a big Thank You to autonomous_unit for reminding me what a fascinating subject Queueing Theory is. I touched on it 30 years ago (from a computer simulation angle) and enjoyed every minute!

[solo siam]

Those speeds are all plenty for skype which really only needs 64kbps or so (solid), could ping be the problem - bandwidth is one thing but the speed of the packet reaching its destination is something different.

[autonomous_unit]

Well, jitter (amount that latency changes over time) is the main obstacle to real-time protocols like VOIP, once you get above a minimum bandwidth such as about 9600 bits/second required for the GSM codec. I've run the GSM codec over a GPRS link with a 2 second latency, and it was tolerable once you got used to the "mission to Mars" delay between speaking and hearing your friend's response.

As Priceless mentioned, it is queueing theory which would show how all these things are related together... it's a very complicated topic but the main point is that the Thai ISPs seem to be hopelessly biasing their system towards aggregate bandwidth utilization, to the exclusion of responsive behavior for any individual application. As long as all the peer-to-peer applications are intentionally making it difficult to classify bulk traffic separately from interactive traffic (with encryption, random port assignments, etc.), there is little solution other than to start treating all traffic as either bulk or interactive and setting your queueing policies appropriately.

[Priceless]

I couldn't agree more, autonomous_unit. Yesterday evening I made a few measurements, using the software that monty gave us a link to. The worst result showed an average jitter of 6000.3 ms and 42.0% packet loss. At that time download speed was 376 kbps and upload was 426 kbps, but who cares?

We'll see if the TOT "technician" who's supposed to come to my house tomorrow afternoon can come up with something...

[seykota]

Those speeds are all plenty for skype which really only needs 64kbps or so (solid), could ping be the problem - bandwidth is one thing but the speed of the packet reaching its destination is something different.

Ben@H3 you mention that 64kbps or so is all that is required for skype, I assume this is voice calls, but what (solid)speed do you think is required for a video & voice call ?

seykota

[solo siam]

150kbps or so would seem about right dependng on image quality and stability of line.

[Priceless]

I feel I owe everybody an update to my earlier posts:

The TOT "technician" came by on Tuesday and checked a couple of times without catching a"slow spot". He was using the NECTEC test site http://speedtest.nectec.or.th and consequently told me that it was the Thaivisa test site that was in error and that he had another customer to visit and Goodbye!

Since then I've been doing some "research" using the NECTEC site. It only measures download speed, which is a drawback, but if you register with them (for free), it can accumulate (very basic) statistics for you. Using this feature and repeating the test over and over I get an interesting time series. This I then put into a spreadsheet and BINGO, I can see what's happening: I get two different speeds from TOT, 860 kbps half the time and 260 kbps the other half. This runs over a four minute cycle, so that I get two minutes "high" speed, then two minutes "low" speed, then two minutes "high" speed and so on. I've tested this over two half hour test periods, one this morning and one this afternoon and it is like clockwork. I enclose a graph of the afternoon test for those interested:

Can anybody come up with a plausible explanation for this phenomenon?

/Priceless

[autonomous_unit]

Try gathering a set of traceroute results to the NECTEC server during the fast and slow phases, and look for a change in the path. If the path changes at each phase, i.e. flipping back and forth between a fast and slow set of routers, then maybe there is some misconfigured route management. In that case, providing them the traceroute information with IP addresses of their routers might be useful, but this depends on you getting in contact with someone far enough up their support/engineer ladder... even if the path does not change, the traceroute may be useful if it shows a particular hop in the path where a large latency is introduced during slow phases but not during fast phases.