I'm trying to model ADSL access link bandwidth shaping. With a link of
18Mbps, I'm using a token bucket filter (tc + netem) to model 10Mbps,
8Mbps and 2Mbps access plans. I have a couple of questions:
- do ISPs typically use token bucket filters with large bursts to shape traffic?
- what kind of burst sizes and latencies/limits are typically used for
the filter?
Thanks in advance,
Srikanth
Srikanth Sundaresan wrote:
I'm trying to model ADSL access link bandwidth shaping. With a link of
18Mbps, I'm using a token bucket filter (tc + netem) to model 10Mbps,
8Mbps and 2Mbps access plans. I have a couple of questions:- do ISPs typically use token bucket filters with large bursts to shape traffic?
- what kind of burst sizes and latencies/limits are typically used for
the filter?
You will definitely have to account for latency.
For emulating cable traffic, latencies (in the USA) will be about
60-80ms to typical sites. Burst mode in my experience occurs only for
about the first 15 seconds, then is throttled back (though not always;
seems to depend on time of day).
For DSL, I seem to recall latency being about 90-110ms (note, I haven't
used DSL in many years). Burst mode was generally not noticeable or
available, that is, you got the same speed regardless of downloading a
1MB jpeg or a 640MB .iso file.
IMHO, IME, ISTR, YMMV...
--Patrick
- do ISPs typically use token bucket filters with large bursts to shape traffic?
- what kind of burst sizes and latencies/limits are typically used for
the filter?You will definitely have to account for latency.
For emulating cable traffic, latencies (in the USA) will be about
60-80ms to typical sites. Burst mode in my experience occurs only for
about the first 15 seconds, then is throttled back (though not always;
seems to depend on time of day).
And queues of 1 second at line rate are not uncommon, so if you load the link, things lag.
For DSL, I seem to recall latency being about 90-110ms (note, I haven't
used DSL in many years). Burst mode was generally not noticeable or
available, that is, you got the same speed regardless of downloading a
1MB jpeg or a 640MB .iso file.
Now more typically 40ms. And yeah, no bursts over normal line rate. Most turn down line rate for other plans, not shape.
Hi!
- do ISPs typically use token bucket filters with large bursts to shape traffic?
- what kind of burst sizes and latencies/limits are typically used for
the filter?
You will definitely have to account for latency.
For emulating cable traffic, latencies (in the USA) will be about
60-80ms to typical sites. Burst mode in my experience occurs only for
about the first 15 seconds, then is throttled back (though not always;
seems to depend on time of day).For DSL, I seem to recall latency being about 90-110ms (note, I haven't
used DSL in many years). Burst mode was generally not noticeable or
available, that is, you got the same speed regardless of downloading a
1MB jpeg or a 640MB .iso file.
The latency i have here on my DSL is ~ 16-22 ms. So its much lower, factor 4...
Bye,
Raymond.
On Tue, May 4, 2010 at 08:54 UTC, Raymond Dijkxhoorn wrote, quoting Patrick:
For emulating cable traffic, latencies (in the USA) will be about
60-80ms to typical sites.
[...]
For DSL, I seem to recall latency being about 90-110ms (note, I haven't
used DSL in many years).
[...]
The latency i have here on my DSL is ~ 16-22 ms. So its much lower, factor
4...
Either you're looking only at the loop contribution, or you're in the
SF bay area and nearly every "typical site" is available locally.
Here in the relatively backwater Seattle suburbs, unless it's served
by Microsoft or a content distribution network, there are substantial
latencies to typical sites.
To make it concrete I used Windows ICMP tracert against a few sites
from both cable and DSL in the Seattle suburbs. First from a
consumer-grade cable offering:
Then from a business-class telco DSL (complete with more than 1 static
IP, someone tie me down lest my soul escape my body from sheer joy!):
Note I made no attempt to ensure I was tracing to the same numeric IP
address from both, and the tests were simultaneous.
Cheers,
Dave Hart
P.S. A special flip of the bird to those IWFs who filter all ICMP at
the edge and break path MTU detection.
Hi!
Either you're looking only at the loop contribution, or you're in the
SF bay area and nearly every "typical site" is available locally.
Here in the relatively backwater Seattle suburbs, unless it's served
by Microsoft or a content distribution network, there are substantial
latencies to typical sites.To make it concrete I used Windows ICMP tracert against a few sites
from both cable and DSL in the Seattle suburbs. First from a
consumer-grade cable offering:Then from a business-class telco DSL (complete with more than 1 static
IP, someone tie me down lest my soul escape my body from sheer joy!):
I am in the Netherlands, and its pretty common there to have low latency on DSL 
Bye,
Raymond.
On Tue, May 4, 2010 at 08:54 UTC, Raymond Dijkxhoorn wrote, quoting Patrick:
For emulating cable traffic, latencies (in the USA) will be about
60-80ms to typical sites.[...]
For DSL, I seem to recall latency being about 90-110ms (note, I haven't
used DSL in many years).[...]
The latency i have here on my DSL is ~ 16-22 ms. So its much lower, factor
4...Either you're looking only at the loop contribution, or you're in the
SF bay area and nearly every "typical site" is available locally.
Here in the relatively backwater Seattle suburbs, unless it's served
by Microsoft or a content distribution network, there are substantial
latencies to typical sites.
I am not sure what the point is in mixing in speed of light latency. If your "typical sites" are, say,
Indian cricket blogs, you will typically have a high latency from the US. What does that tell
you about your DSL or Cable system, except that it is somewhat removed from India ?
Regards
Marshall
Most of the ADSL installations I've seen in SBC 13 state area had interleaving turned on, which significantly increases latency. I suspect that's why many cable MSOs in the same territory have "cable is better for gaming" marketing campaigns running all the time.
So the latency you see on an ADSL line is dependent on how the carrier set up the DSLAM.
--Chris
same as in the HFC and QAM modulation values and so on and so forth .....
services that are requiring a connection-oriented service such as a gaming clan/cloud are highly affected when working in latency and jitter network based environments such as the ethernet based ones and SMDS .......
Interleaving is good because it reduces bit error rate on the line. Would be good though if the carrier let the customer change the properties of the line to optimize for different things, high snr target/no interleaving for low bw/low BER/low latency applications, low snr target/interleaving for file transfers.
We're an ISP that has four access technologies. Both cable and DSL modem
link times are affected by configured rate and sync rate, respectively.
My home CM is at 15/1 Mbps and one-way latency is 4 to 5 msec. My home DSL
modem is at 15/1 Mbps (with interleaving) and has a one-way latency of 15 to
16 msec. And FTTH at 15/1 Mbps is about 2 msec.
In regards to burst mode, the cable modem file specifies how many bytes are
given that top speed, not time. If the port is heavily utilized, "top"
speed may not be attained during that burst session.
Frank
It's common for ISPs in Australia who own their own DSLAMs to do this
via 'line profiles'. I'm on the most aggressive one, and have line
latency of around 9.5 to 10ms.
Also what is interesting is that ADSL firmware in the modem can
contribute significantly. I used to need to be on ADSL1 with
interleaving to get any sort of reliable line sync. After a
modem firmware upgrade, which I knew also involved an ADSL chipset
firmware upgrade, I didn't get any more bandwidth, but was able to get
stability (i.e. no loss of sync for weeks on end) without interleaving.
Regards,
Mark.