Kitz Forum
Chat => Tech Chat => Topic started by: Weaver on July 06, 2018, 04:58:04 AM
-
Why is it that some people really really hate interleaving on their DSL lines? Gamers are one well-known group. Is that all though?
-
I guess a lot of it is about it being a clear number you can measure and that creates a heavy subjective influence.
But modern websites can create an insane amount of requests from other places before loading, and a good deal of those will not be in parallel. With enough serial requests you can get up into noticeable fractions of a second.
Say your baseline latency is 10ms, add 16 for the minimal level of interleaving and it would take 20 ads/scripts/widgets/etc that depend on each other - far from unheard of in the modern web, to generate over half a second of time before your "simple page" loads. For every page load. This sounds tiny but the results seem to be clear in browsing feel.
I remember articles from years ago, cant remember the analysts, might of even been google, about whether people stayed on a page. It was strongly correlated with page load time in the ms range. People are super sensitive to it, so a doubling in latency (which interleaving often does and more) could have a significant effect on peoples perception of their experience.
That at least is one reason I believe people care about latency.
As for the gaming one, its an even stronger subjective effect... I lost because of this etc.
-
Given that the client is allowed to fire up multiple parallel TCP connections (in http 1.x anyway, not sure about http 2.0) as you say if you had objects that depend on one another, then that would be bad. A css file that references a bitmap or a font file would be an example. I wouldn't have thought you could get long chains of them, although an i frame that references something else might add another step into a chain making it longer still.
But given that we have to put up with TCP slow-start in HTTP every time then there is that to consider in the long chain case. I wonder how much delay that contributes compared to round trip time?
I currently have an RTT of ~40ms, with interleave has recently been reduced a bit due to PhyR Broadcom L2 RETX on ADSL2.
So, my questions:
* Do we really think that anyone notices that, or times two, or times three even in a longer chain?
* Or, do they just think that they will notice it?
* Or do they actually experience slowness, but it is due to other reasons, like slow-start? Or lack of cacheability of the objects on the server due to rubbish design or server config?
Rubbish web design meaning no cacheability will really hurt visitors and the server, because all this junk like js, CSS, bitmaps, favicons, fonts, P3P is all highly cacheable so it just needs the server config to be done right. And stuff needs the usual headers - date stamps, etags. Plus the handling of conditional GETs must be done properly. Cacheability completely does away with aabsolutely all of those delays because if it is does right then there should not even need to be any requests at all of any kind for those files. Maybe there is still a lot of this madness and ignorance about. I have indeed seen some shocking sites. A particularly sluggish tourism website for somewhere in the Channel Isles that I remember had the browser refetching absolutely everything even when you move from page to page within the site and then do a back! Some poor fools who are just copying magic incantations that the have seen somewhere with zero understanding are actually going out of their way to explicitly try to disable all caching because “caching is bad”, someone has told them, “dangerous”. It is vital to thrash the server as hard as possible at all times, and to rack up the biggest possible bill for network i/o.
It is true it seems to me that websites have remained fairly sluggish in terms of time to fire up a page over the last 15 years or so even though internet connections have got vastly faster. It is perhaps the increasing amount of page complexity, mountains of javascript, perhaps lots of ads and trackers, stupid social media buttons have proliferated, that junk is an example of something that was not there 16 years ago. The latest bloatware fads of 2028 are a (i) new wave of moronic cowardly cookie law notices and (ii) a rash of CSS position:fixed (iirc0windows that just do nothing but cut down you viewport size and rob you of vital screen real estate all because the designers are pushing some function as being so vital that not having it permanently visible could bring disaster and having to scroll would be an unforgivable tragedy.
-
On the original question - maybe because their router stats used to say "FastPath", so they assume they're now on a "slow path".
-
You make a lot of good points Weaver. I'd love an actual web dev to weigh in though.
-
Hi
As some may know already, we are a hosting company (actually classed as ESP), and after reading weaver post, I thought I would check a few client sites.
As you can see, the issues tend not to be on the servers/clusters which slow things down (albeit I accept some delays are caused by servers/clusters at times, perhaps by Mysql quese etc... but these are generally carefully tuned and monitored) but in general, a server loading less then 5 is completely acceptable to users viewing websites.
The important point is time to first byte and in general, it is then down to website code.
Interestingly though, some clients wanted full compression turned off for some sites, as they server 4K content, and stated compression caused picture loss (I could not see it myself when I checked but we made the changes for them)
CDN are good, as they cache static (you decide what to cache), and then the website is parallel fed on load of website.
A point to also note, is if users have changed their browser settings for parallel streams, but lets say not many do (even Azure advices parallel changes to speed up Azure browsing/downloading using a browser)
Lastly, be aware of tricks to make you think a page has loaded fully, as it may not have, but most sites become usable prior to fully loaded. As an example, ebay does not fully load for a long time, but looks to load quickly and uses this preceived load trick as I remember, but sorry if I am wrong
From a gamers point of view, there are many tricks gamers use to make latency work for them, such as light switche, which induces high latency (were it is low) when joining a game session, and once the game servers has equalised each session for latency, they turn of light switch, so they now have an advantage over other players (usually easily spotted by players) but if you get caught cheating, your usually banned for life on our name tag
I hope that helps a little
Many thanks
John
Details
First Byte Time (back-end processing): 100/100
98 ms First Byte Time
400 ms Target First Byte Time
Use persistent connections (keep alive): 100/100
Use gzip compression for transferring compressable responses: 100/100
64.3 KB total in compressible text, target size = 64.3 KB - potential savings = 0.0 KB
Compress Images: N/A
Use Progressive JPEGs: N/A
---------------------------------------------------------------------------------------------------------
Details
First Byte Time (back-end processing): 100/100
94 ms First Byte Time
400 ms Target First Byte Time
Use persistent connections (keep alive): 100/100
Use gzip compression for transferring compressable responses: 100/100
302.0 KB total in compressible text, target size = 302.0 KB - potential savings = 0.0 KB
Compress Images: 100/100
9.3 KB total in images, target size = 9.3 KB - potential savings = 0.0 KB
Use Progressive JPEGs: N/A
Leverage browser caching of static assets: 45/100
FAILED - (No max-age or expires) - http://domain.url/interworx_logo.gif
FAILED - (No max-age or expires) - https://www.domain.url/billing/templates/six/css/all.min.css?v=cc7ac8
FAILED - (No max-age or expires) - https://www.domain.url/billing/templates/six/css/custom.css
FAILED - (No max-age or expires) - https://www.domain.url/billing/templates/six/js/scripts.min.js?v=cc7ac8
FAILED - (No max-age or expires) - https://www.domain.url/billing/assets/img/logo.png
FAILED - (No max-age or expires) - https://www.domain.url/billing/templates/six/fonts/fontawesome-webfont.woff2?v=4.7.0
WARNING - (24.0 hours) - https://fonts.googleapis.com/css?family=Open+Sans:300,400,600|Raleway:400,700
Use a CDN for all static assets: 50/100
FAILED - http://domain.url/interworx_logo.gif
FAILED - https://www.domain.url/billing/templates/six/js/scripts.min.js?v=cc7ac8
FAILED - https://www.domain.url/billing/assets/img/logo.png
FAILED - https://www.domain.url/billing/templates/six/fonts/fontawesome-webfont.woff2?v=4.7.0
FAILED - https://www.domain.url/billing/templates/six/css/all.min.css?v=cc7ac8
FAILED - https://www.domain.url/billing/templates/six/css/custom.css
CDN's Used:
domain.url :
www.domain.url :
fonts.googleapis.com : Google
fonts.gstatic.com : Google
---------------------------------------------------------------------------------------------------------
Details
First Byte Time (back-end processing): 100/100
261 ms First Byte Time
400 ms Target First Byte Time
Use persistent connections (keep alive): 100/100
Use gzip compression for transferring compressable responses: 100/100
53.8 KB total in compressible text, target size = 53.8 KB - potential savings = 0.0 KB
Compress Images: 89/100
1,018.7 KB total in images, target size = 904.1 KB - potential savings = 114.6 KB
WARNING - (118.0 KB, compressed = 59.5 KB - savings of 58.5 KB) - https://www.domain1.pink/plugins/language_switch/flag_sprite.jpg
WARNING - (41.6 KB, compressed = 23.1 KB - savings of 18.6 KB) - https://www.domain1.pink///_data/i/upload/2015/06/13/20150613124312-d99a8126-cu_s9999x200.jpg
WARNING - (22.1 KB, compressed = 12.0 KB - savings of 10.2 KB) - https://www.domain1.pink///_data/i/upload/2016/03/03/20160303232717-00f99757-cu_s9999x200.jpg
WARNING - (22.2 KB, compressed = 12.6 KB - savings of 9.6 KB) - https://www.domain1.pink///_data/i/upload/2015/07/10/20150710202107-82db246b-cu_s9999x200.jpg
WARNING - (39.4 KB, compressed = 33.4 KB - savings of 6.0 KB) - https://www.domain1.pink///upload/2015/07/10/20150710202107-82db246b.jpg
WARNING - (16.8 KB, compressed = 11.2 KB - savings of 5.6 KB) - https://www.domain1.pink/themes/Sylvia/images/top-left-bg.jpg
WARNING - (10.3 KB, compressed = 6.0 KB - savings of 4.2 KB) - https://www.domain1.pink///_data/i/upload/2015/06/13/20150613124316-2c0e5aa8-th.jpg
WARNING - (8.9 KB, compressed = 7.0 KB - savings of 1.9 KB) - https://www.domain1.pink/themes/Sylvia/images/bottom-left-bg.jpg
Use Progressive JPEGs: 34/100
96.3 KB of a possible 270.4 KB (36%) were from progressive JPEG images
FAILED (118.0 KB) - https://www.domain1.pink/plugins/language_switch/flag_sprite.jpg
FAILED (39.4 KB) - https://www.domain1.pink///upload/2015/07/10/20150710202107-82db246b.jpg
FAILED (16.8 KB) - https://www.domain1.pink/themes/Sylvia/images/top-left-bg.jpg
Info (8.9 KB) - https://www.domain1.pink/themes/Sylvia/images/bottom-left-bg.jpg
Leverage browser caching of static assets: 50/100
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/galleries/MyVideoClip/pwg_representative/IMG_0256-cu_s9999x200.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2017/05/19/20170519101423-1e803900-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2017/05/19/20170519101337-59917276-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2015/06/18/20150618141148-3c224d76-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2017/05/19/20170519101440-b848289b-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2017/05/19/20170519101317-ac5710ef-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2017/05/19/20170519101426-677feade-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2017/05/19/20170519101326-54a56fa9-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2016/06/01/20160601121820-d47fd431-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2015/06/18/20150618141214-2f2b0a89-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2017/05/19/20170519101430-fe62e4b1-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2015/06/18/20150618141202-4e420dca-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2015/06/13/20150613124316-2c0e5aa8-th.jpg
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2015/06/18/20150618141149-80554b9f-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2015/06/18/20150618141216-dcdad455-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2017/05/19/20170519101443-be137978-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2017/05/19/20170519101334-93ff8287-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2016/06/01/20160601122324-37ff76d8-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2017/05/19/20170519101311-1a611c33-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2015/06/18/20150618141212-18dc5609-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2015/06/18/20150618141154-92cad752-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2017/05/19/20170519101309-3452ee84-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2017/05/19/20170519101446-dfc1c088-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2017/05/19/20170519101453-6d2928ae-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2017/05/19/20170519101435-17d2b5a0-th.png
WARNING - (4.0 hours) - https://www.domain1.pink/_data/combined/jjavwu.js
WARNING - (4.0 hours) - https://www.domain1.pink/themes/Sylvia/images/transparent.gif
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2016/03/03/20160303232717-00f99757-cu_s9999x200.jpg
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2015/06/13/20150613124312-d99a8126-cu_s9999x200.jpg
WARNING - (4.0 hours) - https://www.domain1.pink///themes/default/images/ajax_loader.gif
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2015/07/10/20150710202107-82db246b-cu_s9999x200.jpg
WARNING - (4.0 hours) - https://www.domain1.pink///plugins/Media_Icon/template/media_icon.css
WARNING - (4.0 hours) - https://www.domain1.pink/_data/combined/prf8r9.js
WARNING - (4.0 hours) - https://www.domain1.pink/_data/combined/vdk6v8.css
WARNING - (4.0 hours) - https://www.domain1.pink/themes/Sylvia/images/bottom-left-bg.jpg
WARNING - (4.0 hours) - https://www.domain1.pink/themes/Sylvia/images/top-left-bg.jpg
WARNING - (4.0 hours) - https://www.domain1.pink/themes/Sylvia/images/fillet.gif
WARNING - (4.0 hours) - https://www.domain1.pink/themes/Sylvia/images/menuId_top.gif
WARNING - (4.0 hours) - https://www.domain1.pink/plugins/rv_menutree/img/bpm.gif
WARNING - (4.0 hours) - https://www.domain1.pink/themes/Sylvia/images/menuId_bottom.gif
WARNING - (4.0 hours) - https://www.domain1.pink/themes/Sylvia/images/menuId_sides.gif
WARNING - (4.0 hours) - https://www.domain1.pink/themes/Sylvia/images/menuBox_sides.gif
WARNING - (4.0 hours) - https://www.domain1.pink/themes/Sylvia/images/menuBox_top.gif
WARNING - (4.0 hours) - https://www.domain1.pink/themes/Sylvia/images/menuBox_bottom.gif
WARNING - (4.0 hours) - https://www.domain1.pink/plugins/language_switch/flag_sprite.jpg
WARNING - (4.0 hours) - https://www.domain1.pink/themes/default/s26/outline_ff3363.png
WARNING - (4.0 hours) - https://www.domain1.pink/_data/combined/12idky6.js
WARNING - (4.0 hours) - https://www.domain1.pink///_data/i/upload/2017/05/19/20170519101313-e30f7456-th.png
WARNING - (4.0 hours) - https://www.domain1.pink///upload/2015/07/10/20150710202107-82db246b.jpg
WARNING - (4.0 hours) - https://www.domain1.pink///local/favicon.ico
Use a CDN for all static assets: 100/100
CDN's Used:
www.domain1.pink : Cloudflare
-
I used a couple of good tools many years ago to check cacheability and give performance improvement tips, can't remember now it was so long ago.
On the forums though I hear people getting really steamed up about interleave, and many of them give me the impression that they believe - incorrectly of course - that interleave reduces throughout. Latency and throughput are completely different things, but of course with a stop-and-wait or ping-pong protocol, or inadequate window size, then latency could start to limit throughput, but that is a configuration problem or an o/s problem and not the fault of interleaving. Also if you just had a long fat network, such as satellite, or a path to New Zealand with a very large number of hops, so that there was some other reason than interleaving causing a long RTT then exactly the same throughput hobbling thing would happen if you combine that with an inadequate window size or even a completely stop-and-wait protocol. Latency is only a problem for throughput if things are not set up correctly and nowadays we have had TCP window scale for a long time so there is no proper reason for silly inadequate window sizes.
-
16ms [8ms DS/US] interleaving latency is practically almost meaningless for anything not real-time, when there's anything interactive going on it's going to actually make it slower [like websites, as johnson said], but my ping to europe is 70-120ms, for 80ms an extra 16ms is a 20% increase, but how much worse is 96ms? as jonhson said it's more about the experience than "internet health". some people have higher needs though.
it would affect chain query performance, like background interactions, 10 chain queries being 16x10=160ms but that's 16% of a second.
-
Considering how much some gamers spend on monitors to reduce input lag by 1-2ms you could then appreciate how frustrating having 8/16ms added latency is.
Add to that the roughly 10% overheads it takes off your sync speed then I would rather be fastpath everyday of the week.
It's that important too many that it is a factor in deciding ISP.
I used Talktalk LLU ADSL for years because of the control of DLM it gave.
When connected to my ECI cabinet my line could not retain fastpath with the OpenReach Standard DLM profile.
I would need to choose an ISP who uses the Speed profile to keep interleaving away.
-
Considering how much some gamers spend on monitors to reduce input lag by 1-2ms you could then appreciate how frustrating having 8/16ms added latency is.
i honestly still can't, given there is a thing called reality and i don't think gaming deaths have any direct correlation with real life, opposed to something serious. people mine bitcoin for personal wealth, this isn't different. but, this is the new age, so what i say is "stupid". in the end everything will roll where people point it at, if he cares he's going to be impacted by the 16ms. although in a perfect world, i would understand that gamer. i'm speaking in general of course, because as you said interleaving can be turned off, perhaps as a trade-off for a lower sync. latency impact on gaming however, especially 16ms, is going to matter only in some situations, mostly action games, and won't make the player any better, in general it can also make the player lose sometimes [team vs team game], and the fact that it's on that player's end isn't as significant as input/output lag [mouse/screen], because he wouldn't die before he had seen it, just the same effect as distance-caused latency. some youtubers make money off of this but it boils up to what he can work with anyway, taking off 1ms is going to be done out of principle, by me too, but frustrating is a different thing.
would rather
sums it up nicely
-
Add to that the roughly 10% overheads it takes off your sync speed then I would rather be fastpath everyday of the week.
I think that only applies to how it is used on Openreach's FTTC. My ADSL line achieves a higher sync speed with interleaving than without. But the BTWholesale DLM tends to want to turn the interleaving off, so I've had it set to always be on.
Yes, part of the problem is that people can see the delay added and the number of FEC bytes in the stats, but they can't so easily see the effect of the coding gain and the impact on the CRC rate.
-
An increase in latency also has an impact on TCP slow start (https://en.wikipedia.org/wiki/TCP_congestion_control#Slow_start).
As latency increases, connections will take longer to get up to speed.
-
My G.992.3 service is interleaved. I'm quite happy with that. :)
Just in case it was missed, I'd like to echo what 4c typed --
On the original question - maybe because their router stats used to say "FastPath", so they assume they're now on a "slow path".
I will go as far as suggesting that "FastPath" should be eradicated and all xDSL services should be interleaved. The full range of interleaving should be possible . . . starting at 1 and increasing as a binary sequence. By that I mean 1, 2, 4, 8, 16, 32 . . .
And before anyone points the attack-hounds in my direction, please consider what an interleaving depth of 1 actually means. :angel:
-
Hi
I hope no one minds, but I’m losing track of the question, or perhaps didn’t fully understand the question (easily done at my age, with the heat and everything going on here)
In terms of gaming though, 20ms or less is considered good, 160ms and above would become noticeable to online gamers playing (gta5 etc...)
I am a gamer and connect to servers around the world, usually anywhere between 37 - 140 ms, which is not noticeable in play.
This is usually because the game servers do attempt to equalise all session players latency (which will vary), so no one should have any real latency advantage. So if you connect to a game server at 10ms, and the worst session gamer is 140ms, the latency adapter will equalise so the player with 10ms is increased in delay to match the player at 140ms as a crude example.
Next gamer moan as in the old days would be the length of patch cables not been equal haha
The reality is on shift, I am ranked around 860 from world players (I have not given exact rank so no one knows my tag) and I won players on lower latency as well as higher latency. Some though, as I said use light switch cheat but you instantly know this is used if you know what to look out for
Many thanks
John
-
Perhaps another reason for people to hate it is because it can be viewed as the DLM masking problems, assuming someone has had interleaving applied due to some DLM action. Then there's the horrific injustice / unfairness element of your line not being as good as someone else's, as if all lines can be better than average. ::)
There are probably two different groups of people:
People who actually notice the difference in latency.
People who look at their DSL stats and/or ping monitor and complain about the numbers changing, or need to ask if their numbers are bad.
-
I'm not sure there's a psychological aspect to it.
Latency at the transport layer is sometimes magnified at the application layer. When you read about people 'whinging' because they're seeing a mere +10ms on their round trip game, you can almost guarantee it *feels* like an extra 250ms~ in their game or telnet session.
Visual reaction times for regular gamers have been measured in the 160 - 280ms region, however, auditory reaction times are lower still and start around 110ms. When you start adding 10 - 20ms for each datagram, those that are hypersensitive to such changes have to endure this state of incongruence. They have to retrain their eyes and ears to some new, unknown and somewhat unpredictable value.
What makes this worse, is when developers think it's a great idea to build lag compensation into the game. Please stop doing this :P
-
playing at 30ms vs 80ms definitely feels entirely different for action games that don't use lag compensation, and makes 80ms look like 200ms [same ratio as 30ms vs 80ms], so 46ms is going to be noticeable compared to 30ms, or 54ms, 62ms, and so on. playing at 150ms due to distance lag it's less of a % difference, so 180ms is somewhat negligible in the context [speed of light not fast enough :o]
What makes this worse, is when developers think it's a great idea to build lag compensation into the game. Please stop doing this :P
yeah it makes it even more unfair when playing with lags, for the one that's more skilled, so the lags lessen the skill factor - despite being more "fun" :-\
-
@boost
Have you seen this (https://forum.kitz.co.uk/index.php/topic,21600.msg373469.html#msg373469)?
-
I don't know why j0hn says that interleaving "takes 10% overheads off your sync speed". That simply is not true, from my reading of the standards docs for ADSL. Interleave factors not equal to 1 do not have any associate protocol overhead. See G.992.3 p 31 framing picture. I am not familiar with VDSL2 but a brief squint at the G.993.2 equation for NDR on page 74 does not mention interleave depth parameter and description of convolutional interleaver on p64 have not mention of overheads. Maybe I have missed something. Perhaps j0hn will explain.
The point made about latency affecting slow start is indeed a good one. That indeed critically affects effective throughout with small downloads. They are beyond help anyway as using TCP for small objects is just a performance disaster, and this is why HTTP 2 has fixed this by getting rid of the multiple slow-starts iirc.
[Moderator edit to fix an incorrect auto-correction.]
-
I don't know why j0hn says that interleaving "takes 10% overheads off your sync speed". That simply is not true, from my reading of the standards docs for ADSL.
It is very true with OpenReach's implementation on VDSL2.
-
@boost
Have you seen this (https://forum.kitz.co.uk/index.php/topic,21600.msg373469.html#msg373469)?
All I see is a thread full of frustration.
Sky. Believe in better!
-
Given that the server is allowed to fire up multiple parallel TCP connections (in http 1.x anyway, not sure about http 2.0) as you say if you had objects that depend on one another, then that would be bad.
A server is not allowed to fire up multiple parallel TCP connections. It's not allowed to fire up any TCP connections in the normal browsing scenario.
-
I mistyped that, I meant client of course. What I wrote was complete nonsense.
-
I don't know why j0hn says that interleaving "takes 10% overheads off your sync speed". That simply is not true, from my reading of the standards docs for ADSL.
For FTTC it makes a BIG difference to your sync speed.
Last time I was interleaved, I immediately went from 73.9Mbps to 67.8Mbps. Bear in mind that was "interleaved low" profile. "Interleaved high" profile would reduce the sync speed further as the level of INP is increased. So 10% is probably a fair figure to use as a rough example.
It's not so much interleaving that reduces the sync speed, but rather the fact RS encoding that comes with interleaving incurs overheads which reduces the available sync speed.
On adsl1 'Interleaving' on a line syncing at 8128 would reduce the sync to 7616. When I was on BE* Interleaving reduced line speed by just over 2Mbps.
-
Why is it that some people really really hate interleaving on their DSL lines? Gamers are one well-known group. Is that all though?
Its simple really.
RTT is a key factor in performance, for most use cases its more important than burst speed.
e.g. a 10ms 10mbit connection for most things on the internet will offer smoother performance than a 100ms 100mbit connection.
a DNS lookup requires at least 2 x RTT to get a result back to the client. A website could easily have a dozen DNS lookups.
Establishing a connection to a webserver, again multiples of RTT before you even start downloading data.
Streaming will ramp up to higher throughput faster when RTT is lower.
Things like FTP where every command packet has to be acknowledged speed up significantly when RTT is lower.
Then there is of course gamers twitch shooter gamers are hyper sensitive to latency.
Where its not so important and burst speed becomes king is things like bulk downloads, so steam downloads, PSN downloads etc. Although RTT can still be a bottleneck if RWIN is saturated.
Very low burst speed like adsl1 speeds will be a bottleneck for various use cases, so my above post is assuming your burst speed is already at least about 15mbit.
-
Wouldn't a normal UDP DNS question and answer be one RTT?
-
yeah sorry, RTT been both ways it 'can' be one RTT depending on the lookup been carried out as well as the resolver/forwarder configuration to optimise lookups.
-
I still think most people are substantially underestimating the psychological aspects.
Do you think people would be campaigning for interleaving to be removed if all lines had interleaving? I don't think people would be complaining about ECI cabinets so much if ECI were all that was installed. The problem is that one thing (ECI cabinets, interleaving) is not as good as the other thing (Huawei cabinets, no interleaving), and that's not fair.
-
The problem is that one thing (ECI cabinets, interleaving) is not as good as the other thing (Huawei cabinets, no interleaving), and that's not fair.
"Good" in this context depends on your perspective. Interleaving might be "bad" for latency, but "good" for error correction.
Life isn't fair: this is just another example of the desires of one group of people being given preference over the desires of another group. It feels "right" if you are in the first group, but "wrong" if you are in the second group.
-
I was intentionally not counting ping-pong type cases as I was only talking about throughput, and the word doesn't imo really apply if you are not keeping the line 100% in use any way. I mean if you choose to send packets more slowly than you can, then you cannot say you have a slow line. aim talking about the capacity of a link not the speed of any use case, if you see what I mean.
That is not to say that RTT is not important or that stop-and-wait type scenarios are not important, indeed no, it's just that for my present discussion that would be a different question, one is about links and the other is about use cases.
I think Kitz is actually agreeing with me, sometimes the engaging of interleave is accompanied by extra RS codword bloat? Is that correct. about that is just a choice made by the designers, it does not mean that the reduction in throughput was caused by interleave itself - is that correct?
So if I am understanding Kitz correctly, then I am disagreeing with J0hn and maybe getting an understanding of his opinion?
So could the answer be that you happen to get an additional phenomenon kicking into place when you choose a setting called 'interleave' but the name is misleading because it comes with a free side dish of onion rings that you did not order?
-
I still think most people are substantially underestimating the psychological aspects.
Do you think people would be campaigning for interleaving to be removed if all lines had interleaving? I don't think people would be complaining about ECI cabinets so much if ECI were all that was installed. The problem is that one thing (ECI cabinets, interleaving) is not as good as the other thing (Huawei cabinets, no interleaving), and that's not fair.
Not sure what ECI vs Hauwei has to do with interleaving.
I think the point you trying to make is if someone has e.g. always been interleaved, would they be bothered given they never experienced fast path latency? Probably not no. Also fast path in somewhere like scotland would perhaps be similar to a high interleaved connection in london.
-
I was intentionally not counting ping-pong type cases as I was only talking about throughput, and the word doesn't imo really apply if you are not keeping the line 100% in use any way. I mean if you choose to send packets more slowly than you can, then you cannot say you have a slow line. aim talking about the capacity of a link not the speed of any use case, if you see what I mean.
That is not to say that RTT is not important or that stop-and-wait type scenarios are not important, indeed no, it's just that for my present discussion that would be a different question, one is about links and the other is about use cases.
I think Kitz is actually agreeing with me, sometimes the engaging of interleave is accompanied by extra RS codword bloat? Is that correct. about that is just a choice made by the designers, it does not mean that the reduction in throughput was caused by interleave itself - is that correct?
So if I am understanding Kitz correctly, then I am disagreeing with J0hn and maybe getting an understanding of his opinion?
So could the answer be that you happen to get an additional phenomenon kicking into place when you choose a setting called 'interleave' but the name is misleading because it comes with a free side dish of onion rings that you did not order?
Weaver I will admit I am now confused. If you are saying your question was only intended for throughput then your first post doesnt suggest that at all.
RTT affects everything even throughput, in the older days of Windows XP, RWIN was a static value and was dependent on the speed of the ethernet port, around 4k for 10mbit, around 16k for 100mbit and around 64k for gigabit. On the internet they often caused bottlenecking even on adsl speeds because so many downloads were over high RTT (lack of CDN's).
Now days the RTT limitation on throughput is mitigated via a combination of CDN popularity to provide low RTT servers and modern OS's which autotune RWIN to higher values.
The point of my post was that if I e.g. download a game of steam, I dont really care if it takes 2 or 3 or 4 hours to download, I can wait. But if I am doing something like loading a web page I am sensitive to the response time. The one activity I do where the capacity of the line has a meaningful effect is probably streaming, higher burst speed allows more buffered content to load quicker so video content starts playing earlier and at higher resolutions. I have even posted a fair few times I could probably get by on a 40mbit service, but I stick to the higher speed service due to my technical nature and its a just because I can thing.
On a psychological level people seem much more sensitive and more likely to moan with line banding vs interleaving, even tho the former has less of a negative affect on performance.
-
I think I rather drifted off topic myself because I got drawn into discussions about actual performance rather than psychology which was my original question.
And I was using a different interpretation of the word 'throughput' - I was meaning dsl link throughput, whereas you were using a more inclusive interpretation 'system performance' including the behaviour of the devices at the two ends, software and the use case, so that you were dealing with real world actual performance. That was just my particular choice of terms/topics.
I think that you and I are fully in agreement on all points, but I may have expressed myself poorly.
My point about 'psychology' was concerned with the question of why do people get steamed up specifically about interleave rather than just saying 'my internet x activity eg web browsing is slow'. If people do not know about the effect of rtt on page opening time for complex webpages that are not cached especially where objects are small, then they will not be able to blame interleave. So the question then is whether or not people are aware of the link and then blame interleave for poor responsiveness in web browsing.
I wonder if people consider that high interleave depth can have large performance benefits, and that it is done for a reason, not to hurt performance. I would argue that if intelligent system tuning is done correctly, which is quite an 'if', the use of high interleave depth allows you to push for higher sync speeds which increase error rates while on the other hand interleave reduces a certain type of errors, so that it can be a trade off that allows you to get a higher link speed without breaking a certain chosen error rate limit. Does that sound reasonable? I think doing this kind of assessment must be pretty hard though, as knowing the pattern of error types is not straightforward.
I myself have always tried as hard as possible to do what ever I can, which is usually not much, to push up interleave depth as far as I can, as I don't care at all about rtt. I am hoping that I have modern software that uses large window sizes. But I desire every ounce of raw link throughput (in my terms, ie sync rate, allowing for bloat) that I can get with links as slow as I have.
-
Presumably because people have learned it's not enough to express they are receiving bad service, they must find as much information as possible to contribute to the solution.
It's almost certainly the reason any of us use this forum :P
However, not all end user research is as exhaustive as it could be. We are experts at filling in the blanks with the little to no information we possess, I suppose? :)
-
Not sure what ECI vs Hauwei has to do with interleaving.
The point was that I think people aren't complaining so much about the technical differences, they are complaining because they consider one worse than the other.
I think the point you trying to make is if someone has e.g. always been interleaved, would they be bothered given they never experienced fast path latency? Probably not no. Also fast path in somewhere like scotland would perhaps be similar to a high interleaved connection in london.
They'd probably be a few people freely giving their opinion on what idiots Openreach are and how if they were in charge they'd operate the DSL lines so much better.
-
I wonder if people consider that high interleave depth can have large performance benefits
The interleaving depth number is largely irrelevant, but yes, lots of people probably do think that a larger depth number is "more interleaving", and then people will be watching their stats, and if they see line rate and interleaving depth both go down slightly, they'll erroneously conclude that the reason for this must have been the DLM turning down the interleaving depth a little.
-
Interleave takes its toll with serial transactions and the extra delay introduced. Nothing to do with throughput as far as browsing goes.
I've used a modem with old firmware and had interleave applied due to behaviour of Openreach DSLAMs and noticed almost immediately. Nothing to do with psychology and I don't obsessively monitor my connection so wasn't aware objectively that it was there.
-
None of which really answers the original question though.
I take it then that pretty much everyone here is of the opinion that all the people complaining about interleaving will be doing so for perfectly valid reasons largely originating from the additional delay? And it's got nothing to do with people knowing that their line has got worse? You may have noticed the change, but would you be complaining if your line were always like that?
-
I understand now Weaver, so do people complain simply because they can because they interleaved without understanding the pros and cons of it?
Some probably do yes. But as ignition has said, there is also valid complaints, as interleaving does impact performance in a way that can be noticed.
-
Chrys - exactly. I myself think, "ooh good, I have a high interleave depth, that might mean the possibility of a faster sync rate".
-
Chrys - exactly. I myself think, "ooh good, I have a high interleave depth, that might mean the possibility of a faster sync rate".
??? I myself think there goes a good chunk of my sync speed, plus delay :(
So could the answer be that you happen to get an additional phenomenon kicking into place when you choose a setting called 'interleave' but the name is misleading because it comes with a free side dish of onion rings that you did not order?
Yup. RS Error Correction is almost always turned on at the same time as interleaving.
It's not so much interleaving that reduces the sync speed, but rather the fact RS encoding that comes with interleaving incurs overheads which reduces the available sync speed.
One of the things I kept pointing out during the introduction of G.INP is that people tend to use the word Interleaving when really we should be saying Error Protection. In short, you have INP which uses Interleaving and FEC (RS encoding). Then you have G.INP which uses retransmission.
-
Unless you're using a modem which has a Lantiq/Infineon chipset, in which case RS is applied on the downstream whether fastpath or not.
I happen to notice when 'traditional interleaving' is applied. My thoughts are something along the lines of "a bit of sync rate lost and increased latency". As a person who plays quite a bit of first person shooter games online I notice the difference (as strange as it might sound to some), so I much prefer the lowest latency possible. I'd rather have a slightly reduced sync rate instead of 'traditional interleaving'.