|
Upload saturation/Buffer bloat on DSLJust 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. |
|
|
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
Anon
2015-Mar-26 10:27 am
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 . |
|
|
That's definitely not typical of any DSL connection I've ever used; there's certainly something wrong for you somewhere in the chain. |
|
|
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 |
|
|
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
Anon
2015-Mar-26 4:51 pm
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. |
|
|
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
Anon
2015-May-5 11:05 am
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. |
|
GuspazGuspaz MVM join:2001-11-05 Montreal, QC |
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
Anon
2015-May-5 2:52 pm
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. |
|