Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: les-70 on August 14, 2015, 11:30:45 AM
-
This morning at about 10:00am my connection went from fast path to interleaved. :( I can't see any reason at all for this. I had been running steadily for long time with low errors. I switched off on Tuesday and then back on last night (Thursday) as I was away. Connection was fine overnight with low errors then this morning interleaving!!!! I am baffled, previously the DLM has always had an excuse but this time I just don't get it. Continuous stats are on MDWS. it is a ECI CAB and HG612
-
Ive just had a look. I cant see any reason why either. :'(
The only difference is that the line was down for a few days with no connection. hmmm Im wondering. On the Huawei system, I believe that after a new DLM reset your line now doesn't go back to wide open. It starts off interleaved and then will go to g.inp. But yours isnt a retransmission line, nor have you had a DLM reset. Im betting though if anything that it is most likely something to do with your router being off. Your DLM ILQ will have been 'Black' for the period you were down, but surely there should be something in place because 100's of people go away for several days. Im as baffled as you are :-\
-
It's possible turning off a modem on a line for a while/overnight/24hrs, fools the DLM into thinking lines error free, thus no need for any interleaving?
It's just happened to me.
-
I would guess that the DLM was about to make that change anyway and your on and off just happened to be at the right time.
-
turning off a modem on a line for a while/overnight/24hrs, fools the DLM into thinking lines error free,
DLM makes note of and monitors when the modem is on and off line. Depending on the days uptime then it should classify the line as Grey or Black which should mean the DLM takes no action.
I'm waiting to see if Les-70's line makes any changes tomorrow.
-
I'm still awaiting G.INP being re-enabled on my line :)
-
The DLM has not relented in 3 days and just one ES over that time. I guess I won't know if it is stuck for a few weeks. :( Today I did a resync as the DLM had resynced at a time when my line had a high SNRM due to other disturbers presumably being switched off - they are back on now. After the resync I gained as expected some upstream power but the interleaving has remained identical to that prior to my resync.
I am still none the wiser but according to a neighbor the ECI DSLAM was down for a few hours while I was away. There were power outages at its location due to major re-cabling work. The neighbor never looks at any stats (maybe a good way to avoid irritation!) so I don't know if he has had any DLM action.
-
I was hoping it may make some sort of move today :(
-
I am pleased :) that fast path has returned after 14 full days for upstream to go fast and 2 more days for downstream to go fast. I don't believe it can be the holiday power off and it was not an error or resync count. It may have been to do with cabinet being powered off for more than 3 hours (and perhaps any battery backup failing) while I was away but if so why was it on fast path when I first powered up.
I will leave it untouched for a while but I need a power off soon to move the HG612 to a better position.
-
Is it true that you need to leave it turned off for half an hour? Just as much for FTTC, I presume ?
-
Glad it finally sorted.
I do know that the default profile for G.INP lines has changed in some way, (see the G.INP thread with Ian Lawrences info) and now resets will cause interleaving to be applied by default, I was under the impression that it would take a couple of days, but it seems to have taken much longer :(
-
Are you a gamer, les-70?
-
Definitely not a gamer but I first noticed the return to fast path by noticing web pages loader quicker and then looking at my stats.
Is it true that you need to leave it turned off for half an hour? Just as much for FTTC, I presume ?
The line is FTTC and I always turn off for more than half an hour should I turn it off.
I do know that the default profile for G.INP lines has changed in some way, (see the G.INP thread with Ian Lawrences info) and now resets will cause interleaving to be applied by default, I was under the impression that it would take a couple of days, but it seems to have taken much longer :(
It is an ECI CAB, do you have any idea what happens to DLM settings when the DSLAM has a long enough power cut drain the DSLAM backup battery? You would have thought it would just carry on where it left off rather need to reset lines.
-
Sorry forgot you were on an eci, for some reason I was thinking Huawei this morning.
You're correct that power to the dslam shouldn't affect the profiles as those should be held elsewhere and sent to the dslam. The element managers in the exchange stores ongoing data about your line and the dlm system itself via the oss determines the profile. This then should send it to the dslam.
Pure speculation here but wondering.. With you being away, your ILQ status would definitely be black. I wonder how long history is stored surely it should be more than two weeks somewhere even if there was also an issue with the element manager losing data. I really don't know why yours should have been interleaved.
-
Can a web user actually notice a difference in responsiveness due to latency? I wouldn't have thought that's the kind of application where you could perceive such a small time difference of a few tens of milliseconds. But then if you can, you can.
-
Can a web user actually notice a difference in responsiveness due to latency?
A lot of modern web pages make multiple calls to different URLs to load pictures and other data, so a few tens of milliseconds added to each call can add up to a noticeable delay.
-
@Roseway - of course yes you're right, lots of requests. Is the interleave on VDSL2 much wider than on old-fashioned ADSL? How fast is les-70's pipe?
I would have thought modern web browsers let you issue the second and subsequent HTTP requests in parallel? Originally web browsers were only supposed to issue two requests max in parallel, iirc, but I thought that that had been ignored for a long time now. The dependency could be something like two deep though, html references css, references image, or css references more css through an @import or whatever, it's a long time since I looked at this stuff.
I'm just a bit surprised. There's a lot of good stuff on yahoo's website about page load times and if I remember correctly multiple DNS lookups were performance killers.
-
If I were designing the web now, first time, there would just be a single zip file delivered containing a whole web page and also all dependent components using multipart mime, like an email. Later fetches for a changed page would leave out the static components that had already been delivered, to let the client request them if it had cleared its cache or something.
I can't remember, is SPDY a bit like this?
-
Lag, delay and latency is sometimes weird.
For example when the plusnet thingy or MSIL problem is occurring, then I do notice. Pages can be agonising slow to load, yet a speed test will show 20mbps and you'd think that should be quick enough to load a page. I don't usually perform speedtests and it's the slow loading of pages that usually lead me to doing them.
Re gaming latency. The argument is that a couple of milliseconds is faster than the blink of an eye and faster than most human reactions.
The counter argument is that if all things were equal for distance and connection speed bar the fact that you had low level interleaving are..... If your reactions were quicker and you pulled the trigger 5ms before your opponent, you'd still be the one who got shot in the game.
---
Should say those arent my arguments, but are typical of the long running debate which has been ongoing since BTw introduced interleaving about 10yrs ago.
-
Can a web user actually notice a difference in responsiveness due to latency? I wouldn't have thought that's the kind of application where you could perceive such a small time difference of a few tens of milliseconds. But then if you can, you can.
answer is yes.
The difference caused by base latency tend to be actually higher than the base latency difference due to how things work.
e.g. lets say a web page needs 20 dns lookups (more common than you think).
lets say each lookup needs latency to dns server + say 30% overhead, that might mean say 13ms on a fast path connection so 260ms waiting for lookups, or 25ms on a light interleaved connection meaning 500ms waiting, or say 50ms on a heavily interleaved connections so 1000ms waiting, hope you get the idea. Thats also only the tip of it, as there is latency to establish connections to the web server as well.
Finally due to how tcp buffering works, latency also affects throughput and how quick that throughput ramps up.
Browse a website hosted in asia and you should see a very noticeble difference all down to the latency.
Sites hosted in eastern europe might give an idea of the affect of interleaving more realistically.
-
Thing is, I thought a lot of web page load time things were all about bad web server config and bad webpages that are caching-unfriendly, with no correct cache control headers, no etags, date stamps or even no-cache directives all help to slow things down. Lots of DNS lookups are another example. Even though pipes have got wider, some of these crapness factors have not changed since the days of dial-up. The modern trend of having dynamic, generated webpages for no earthly good reason doesn't help either. Web servers up to be generating pages than storing them then serving up the results are static pages unless they actually need to be changed and recalculated it's possible to do this by putting proxy caches in front in front of the origin server or by using caching modules inside programming environments.
So many websites are painfully slow simply because sysadmins are bought cheap and server software stacks are badly configure or outdated. I've seen a number of shockers recently where using the back button within the site is completely painful for no reason at all.
Since DSL links have got 10 times faster, for the haves at least, then latency due to interleave should have gone right down. But no wait, perhaps my logic is wrong, perhaps the length of time of an interleave period should have to remain the same so that it covers the time length of a noise burst and then some, regardless of what the data rate is?
-
@Chrysalis - I realise now that the multiplication problem is the key. About the number of DNS lookups, I thought that say eight or so ought to occur in parallel so that means three lots of latency for 20 lookups.
-
possibly 'some' may be done in parallel depending on the browser and how page is laid out. But never all in parallel as the extra hostnames arent even known by the browser until the page is processed.
Also now days many websites deliberately avoid keepalive so you get the overheads of establishing connections, e.g. a web page with lots of images may deliberately split those images over multiple hostnames, which again penalizes higher latency.
http 2.0 improves a lot of this stuff but is years away yet from mass adoption.
also some browsers adopt things like dns prefetching (lookups done for all links in background), and speculative connecting (doing all http connections in background for links on page). Both practices are frowned upon by server admin's as it creates extra server load, in addition they can be considered anti privacy. But these are thing browsers are doing to try and speed up responsiveness.
Also for about 6 months in 2014 firefox were doing 2 dns lookups per hostname to get round an issue they had, this is now fixed tho after the bug report was flooded by angry server admin's :) was made even worse by the fact the 2nd dns lookup was never cached.
-
There's a name for this technique of splitting a set of images across multiple domain names as mentioned on the Yahoo website, but I forget. I think the idea is to get another allowance of so many HTTP connections per hostname. Yahoo recommend this trick as a good design technique.
-
There's a name for this technique of splitting a set of images across multiple domain names as mentioned on the Yahoo website, but I forget. I think the idea is to get another allowance of so many HTTP connections per hostname. Yahoo recommend this trick as a good design technique.
it's called pipelining. The reason it's done is because browsers by default can only have two simultaneous connections per hostname, so while those two connections are downloading large files (i.e images) they're blocking the rest of the page content from being downloaded. By offloading images onto separate hostnames, the initial two connections are free to continue downloading html, css and script files while the images are being downloaded, and having multiple hostnames means image heavy pages can download more than two images at once.
-
yeah google recommend the same but I actually disagree with both of them.
That recommendation was started in the era when browsers didnt do keepalive, keepalive is faster than bombarding servers with dozens of connections.
However of course many web servers do disable keepalive, so when keepalive is off it can help.
-
yeah google recommend the same but I actually disagree with both of them.
That recommendation was started in the era when browsers didnt do keepalive, keepalive is faster than bombarding servers with dozens of connections.
However of course many web servers do disable keepalive, so when keepalive is off it can help.
keepalive just prevents the connection being closed, it doesn't address the two connections per hostname issue or the fact that downloading images blocks other content.
-
keepalive allows for continuous stream of requests to be made without the overhead of any new dns lookups or establishing connections.
-
Keepalive avoids slow-start.
I was under the impression that some web browsers now completely ignore the low limits on the number of HTTP connections?