dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
1935
mosswalker
join:2014-10-06

mosswalker

Member

Upload saturation/Buffer bloat on DSL

Just a question for someone who might know. I think i am misunderstanding something somewhere about buffer bloat.

Is the dramatic rise in latency when uploading do to buffer bloat or is it just a idiosyncrasy of DSL? I was thinking this as i get ready for my new service i ordered which is symmetrical EOC. Not sure if i am still going to see the latency increase and if so, which appliance i would look at altering que depth on to eliminate it. Or is it not going to exist in EoC ? I never see it when moving huge files across the internal network.

Anyone?
Edit ... this is similar to a question i asked before about latency but i think i never asked the question in the correct manner.

squircle
join:2009-06-23
OTWAON10

squircle

Member

It's not unique to DSL, you're experiencing buffer bloat. You'd experience the exact same thing if you saturated your uplink on cable or ethernet or fibre or anything else. If you get a router that runs Linux, it's trivial to adjust the queue depth, and you can use QoS to guarantee bandwidth for certain applications (e.g. VoIP, gaming etc.). Additionally, if you prioritize small TCP packets (primarily ACKs), you'll get a much less noticeable hit to your download speed when your upload is saturated.

It'd be also prudent for me to point out that queuing isn't inherently bad, but you can have too much of a good thing. If there is a small queue/buffer, preferably one that's adaptive to load, you'll get the best of both worlds.

Neteffect
@bell.ca

Neteffect

Anon

Ahhh .,. i wasnt clear. I mean i dont even get to 50% of the upload bandwidth and my latency goes off the charts. From 16 to 6 to 900 area ... i think though that it is saturation once it gets off my line to the CO. I was thinking or thought i understood where it would be. In the modem, but i am told that is not it at all. I will just wait and see what EoC brings me and deal with it then. I cant do anything about Bell DSL .

squircle
join:2009-06-23
OTWAON10

squircle

Member

That's definitely not typical of any DSL connection I've ever used; there's certainly something wrong for you somewhere in the chain.
HELLFIRE
MVM
join:2009-11-25

HELLFIRE to mosswalker

MVM

to mosswalker
said by mosswalker:

Is the dramatic rise in latency when uploading do to buffer bloat or is it just a idiosyncrasy of DSL?

A dramatic rise in latency can be due to anything. Trick is isolating where it's coming from and what's causing it.

Best place to start is
a) get a baseline of what expected latency is when doing the uploading
b) perform a tracert between the system(s) who are talking with one another
c) does latency affect any other connectivity? Or as I call it, "is it network latency or endhost / application latency" as there's a BIIIIIG
difference between the two.
d) validate each hop to determine whether it is having issue(s) or not.

Last one is tricky, the first one being whether you have access to it or not. Obviously if it's some core router belonging to your ISP,
they're likely to tell you to pound sand if you were to ask for access.

My 00000010bits

Regards
Cloneman
join:2002-08-29
Montreal

Cloneman to mosswalker

Member

to mosswalker
From Wikipedia:

In other words, over-sized buffers have a damaging effect only when the link they buffer for becomes a bottleneck.

Therefore bufferbloat can only have an impact when the upload is near 100%. Which also means, bufferbloat should not come into play when a proper QoS configuration is in place, or when you artificially limit your upload to say, 75% in the application.

The article goes on to say MTR can help pinpoint the problematic router.

I would suspect something much simpler in your case, it's probably just a poor/noisy DSL signal, causing erratic effects when you try to use any significant upload bandwith. This is resolved by looking at line stats with your ISP. (The Bell Direct Forum is _very_ good for this).

One thing with ADSL is it that it relies on the ATM network which has a fixed cell size. Small packets (like ping, VoIP have to fit in "fixed" size cells, so there's a lot of overhead for them, which may contribute to additional latency, but unlikely that its in the 900ms range.

I've seen much greater latency with ADSL versus VDSL when the line is saturated. I don't know weather this is a function of having more upload bandwith available or VDSL's superiority, or non-reliance on an ATM network.

Neteffect
@bell.ca

Neteffect

Anon

Well thanks for the responses you guys. I am just going to wait for them to install my EoC . I left Bell, i am tired of the BS. Going to see if this turns into a win win for me.
mosswalker
join:2014-10-06

mosswalker

Member

Its up and running. Man what a difference Quite happy right now that Bell told me to take a hike. This EoC is night and day difference from consumer broadband.


FreeRessy15
@teksavvy.com

FreeRessy15

Anon

Producer/consumer problem. Question was if the latency is in effect a product of buffer bloat or the technology. The question is a bit redundant since regardless there is a queue and the latency is proportional to it.

The speed of an electron doesn't change (it would be unproportionate here anyway) - how the network recovers is entirely another matter. Robbers will burst, DSL I'm assuming has some degree of burst as well. Less any artificial impediments, "burst" is just bs for buffer recovery. This is why when you look at a packet trace you can see sub ms ipg - the packets were bursts either by the CPE or upstream. It isn't inherently bad except ... well, buffer bloat.

Personally I'd prefer 2xRTT and networks stop hiding it from end applications. Applications that can adapt, will.

tl;DR - Upload is a feedback to control download where loss isn't a factor.

Guspaz
Guspaz
MVM
join:2001-11-05
Montreal, QC

Guspaz to mosswalker

MVM

to mosswalker
Electrons generally move exceptionally slowly (like tiny fractions of a centimeter per hour), or with AC they don't really move at all, they just vibrate back and forth... The important measurement is in fact how fast the electromagnetic wave moves, and that varies depending on the medium. Data cables typically do 42% to 72% of the speed of light. That might seem to be fast enough not to matter, but over a distance of even a thousand kilometers, the difference can be measured in milliseconds.

Fiber optic cable is typically faster, at around 70% or so, but wireless transmission is the fastest of all. Microwave transmissions (like wifi) go at essentially the speed of light: atmosphere doesn't slow it down much. That's why you hear about high-speed stock trading switching from fibre to wireless: they can reduce latency by tangible amounts.

FreeRessy15
@teksavvy.com

FreeRessy15

Anon

Even if you move the problem to another domain - tcp vs udp, fiber vs rf, bigger pipes, upstream proxy - there is till a fundamental problem of an asynchronious feedback (flow control) to an unabted process designed to be synchroious (TCP). It indeed isn't so much a problem where the parts of a flow is suffient to support the whole; it is when one part becomes congested - queued. If you notice it or not becomes inconsiquential for microbursts but is quite perceived with voip, ssh, gaming, initial syn-ack etc. To wit, a lot of this if reported at all is hidden behind numbers few read or understands. HFT users obviously would.

You could certainly infer such but I know of no _end user_ monitoring that takes ipg or queue depth into account for example, they simply report over a period (typically 1 second for real time). Measuring PPS would not help here either.

Speedtest does a remarkable job at misrepresenting this and utterly fails at higher speeds. They effectively are measuring a providers ability to burst -- completely the opposite. Gives pretty numbers but doesn't explain why regular downloads are slow.

Despite google claiming to "discover the microburst problem" there is some instrumentation like web100 that does at least make an attempt - domain specific of course.