JenSuisUn Premium Member join:2006-02-23 Chatham, ON 1 edit |
[DSL] DSL Slow Speeds Update (ON/QC)Hello All, Since the past few days we have seen an greater amount of people complaining of slower speeds & higher latency during evenings (7-11PM) We are currently asking the public to help us gather some information in order to pinpoint where this is occurring. We would rather get the information while you are experiencing the issue.
We ask that you post your information in the »/fo ··· avdirect forum using the following :
SUBJECT : DSL SLOW SPEEDS INVESTIGATION
We will be asking for the following test results.
Provide you account information (naturally)
- Results from »teksavvy.speedtest.net - tracert google.ca & ping -n 50 google.ca or you can use MTR to google.ca for 50 tries.
Connect with Login/Password : test@test / test -note down your 10.x.x.x IP gateway is IP ending with 1 (10.x.x.1) -ping gateway --> ping -n 50 10.x.x.1
Once we have noted the results we will be submitting this for further investigation.Through further investigation based on the results some of you have provided, we discovered the issue and are working with Bell to resolve it. The currently ETA is end of month. Once updates become available, we will post them. Regards, Martin |
|
|
Can you give a pointer as to who is affected? Is it all Bell DSL lines, specific regions, specific technologies (MLPPP?) etc? |
|
JenSuisUn Premium Member join:2006-02-23 Chatham, ON |
There are no specifics per se, but there is an obvious evening issues. The good news is it's now been properly reported to the appropriate channels & hopefully all will be fixed by the end of the month.
Martin |
|
|
Discovered the issue but no specifics??? |
|
your moderator at work
hidden :
|
bohn join:2006-05-30 Scarborough, ON |
to DataRiker
Re: [DSL] DSL Slow Speeds Update (ON/QC)Probably Rogers adding those extra TSN channels with no bandwidth whatsoever did it. Gee, did they ever think that extra channels might take extra bandwidth? |
|
|
to JenSuisUn
Sooner would be apprecaited, if possible. |
|
|
|
to bohn
said by bohn:Probably Rogers adding those extra TSN channels with no bandwidth whatsoever did it. Gee, did they ever think that extra channels might take extra bandwidth? Did you even read the title ? |
|
Technicolor TC4350 Asus RT-AC56 Grandstream HandyTone 702/704
|
said by lowping:Did you even read the title ? I thought everyone knew that Bell DSL uses the underlying Cable provided by Rogers. |
|
bjlockie |
to DataRiker
said by DataRiker:Discovered the issue but no specifics??? Bell doesn't want anyone to know why. I think TekSavvy will be transparent about stuff they manage but not about their provider stuff. |
|
1 edit |
to JenSuisUn
Teksavvy congestion? Backbone congestion/problems? |
|
dra6o0n join:2011-08-15 Mississauga, ON |
to bjlockie
said by bjlockie:said by DataRiker:Discovered the issue but no specifics??? Bell doesn't want anyone to know why. I think TekSavvy will be transparent about stuff they manage but not about their provider stuff. BELL: Oh my, they discovered this! We'll just give them an excuse and warn them to not be transparent until the end of the month, then we'll turn it off. |
|
1 edit |
to bjlockie
The speculation machine is strong here.
This sounds like a capacity issue. Would Teksavvy admit that they might have forgoten to add some ? |
|
|
to JenSuisUn
I'm finding Youtube to be terrible. It partially loads then stops with no more buffering. I then reload the page and hope for better. Is this related at all? |
|
your moderator at work
hidden : Off topic hidden : Off topic
|
|
to JenSuisUn
Re: [DSL] DSL Slow Speeds Update (ON/QC)said by JenSuisUn:The currently ETA is end of month. Seriously? WTF!? In a business where delays are measured in ms they tell us that the ETA is roughly 10 days!!!??? WTF!? |
|
globus999 |
to lowping
Douby it. Why would capacity become an issue so suddenly? If it would be a capacity issue, it would have gotten progressively worst over weeks/months. This is sudden. This is something else. |
|
TSI Andre Premium Member join:2008-06-03 Chatham, ON |
to globus999
Swearing doesn't make it go faster. We realize this sucks but unfortunately the process of fixing this is x days which we can't expedite. |
|
|
to globus999
said by globus999:Douby it. Why would capacity become an issue so suddenly? If it would be a capacity issue, it would have gotten progressively worst over weeks/months. This is sudden. This is something else. What else could could it be ? Do you know of anything else causing speed issue between 7-11pm ? Why other ISP don't have this issue ? And the delays taking to "fix" it, doesn't it take time to add capacity ? |
|
1 recommendation |
to globus999
said by globus999:If it would be a capacity issue, it would have gotten progressively worst over weeks/months. This is sudden. When network links hit saturation, the performance penalty can be quite sudden and drastic: if a link was at 999Mbps and someone decides to floor their 50Mbps DSL through that link, you are now dropping ~5% of all traffic through that link until enough clients throttle back to get the link back under 1000Mbps. Throughout that process, you also need to cope with all the re-sends and other clients who might add to the load. Hitting saturation causes quite a bit of waste multiplication when individual endpoints can consume a significant chunk of its capacity. Bell really needs to upgrade its GAS interconnect equipment to something that can provide 10GbE... practically anything newer than 10 years old support that. |
|
|
said by InvalidError:When network links hit saturation, the performance penalty can be quite sudden and drastic And this is, of course, correct. However, you are missing the point. In real life hitting saturation is not a 100% and on/off situation. You must look at the problem over time. Let's say that the link was at 999 as you exemplified and somebody floors the 50 then you get all these effects. However, and this is the important part, this person won't do this every single day betwee 7 and 11 PM like clockwork. It will be random; some days it would start at 5 PM and end at 9:37PM or 3AM and some days this won't happen at all. As you add more users, the pattern of saturation becomes more and more *extended*, not fixed between 7 and 11. Why would people saturate lined *only* between 7 and 11 PM. This makes no sense at all. This is what I would have expected should this be a "normal" saturation pattern. Things would have gotten progressively wrong on an intermittent pattern until reaching the current situation. This is not the case. Literally, overnight, we get saturation. And the saturation is pretty much fixed between 7 and 11. There was no previous pattern. The saturation period is fixed. This tells me two things: 1 - If it is saturation, a great deal of people were let loose in one single transaction on one single choke point 2 - There is something else going on because of the repetitiveness of the throttling/whatever you prefer to call it. No. This is not a normal saturation situation. It is complex and unusual and somebody somewhere is doing extensive CYA. I really *really* doubt we will ever know what happened. |
|
globus999 |
to TSI Andre
said by TSI Andre:Swearing doesn't make it go faster. We realize this sucks but unfortunately the process of fixing this is x days which we can't expedite. How do you know what WTF means? How do you know that if it even is swearing, it is directed at TSI? How do you know that it is not directed at Bull? And lastly, if it is swearing, how do you know it solves nothing? You would be surprised as to how many things get fixed by swearing in... for example... our "illustrious" Parliament? Oh, and while we are at it, why all the mistery surrounding the cause of the problem? Who is covering their ass? If it would be a technical problem "only" we would know by now. Nope. This was human error. Somebody screwed-up royally and TSI/Bull are in "damage control" mode. But then again, if this is not the case please feel free to contradict me by providing the relevant information. |
|
TSI Andre Premium Member join:2008-06-03 Chatham, ON |
:/
I'm working on getting/providing more details.
Thanks for your patience. |
|
|
to globus999
said by globus999:Why would people saturate lined *only* between 7 and 11 PM. Frequency and severity: you will rarely get saturation and significant performance degradation outside peak hours because most capacity spikes will be too short and far apart to cause any obvious externally observable issues. It does not start snowballing until spikes are severe, frequent and long enough to cause and maintain a capacity demand backlog. Once you pass that threshold, performance does not recover until demand eases back down. Many routers and switches support features like WRED which start dropping packets before links hit 100% to prevent links from getting in that sort of scenario where performance may suddenly collapse. Network equipment without "Random Early Detection" may cause client synchronization and make congestion even worse. You may call it conspiracy if you wish but all major network equipment manufacturers have whitepapers about this and the features their equipment has to help mitigate it. |
|
|
Yes, but there is more to the story. The term "peak hours" is fuzzy. It does not have hard limits like this phenomenon. This is something else. said by InvalidError:most capacity spikes will be too short and far apart to cause any obvious externally observable issues. ... Until they grow to a point at which they are not. It is a gradual process until the threshold is reached and this process is indeed observable. said by InvalidError:Once you pass that threshold, performance does not recover until demand eases back down. ... Correct, but the the concept of "demand eases" is again, not hard coded in terms of time-of-day... which this current phenomenon seems to be. Furthermore, thresholds can be reached on longer periods of time only to subside without sustaining saturation. It is all a question of bandwidth utilization. The more granular is the dependency on BW utilization, the more gradual the saturacion process will be. Again, saturation is not an ON/OFF switch. There are signs as we approach this point. These signs are missing in this case. Of course there is a conspiracy, a conspiracy of silence. This much is obvious otherwise we would already have all the tech info. Not to provide this info is completely out of character for Tek. Something is going on. This is not a regular saturation. |
|
|
said by globus999:Again, saturation is not an ON/OFF switch. There are signs as we approach this point. These signs are missing in this case. Saturation is there, queues are overflowing and packets are getting dropped or it is not, queues remain generally empty and packets are going through with sub-millisecond delays as usual. The transition between the two can be brutal. said by globus999:Not to provide this info is completely out of character for Tek. It is not out of character at all: when issues are happening within Teksavvy's own equipment, they can do whatever they want with what they learn in that process. When the issues involved third-party vendors, they do not know anything beyond whatever the vendor told them. Bell told TSI they found an issue with their gear, that it will take up to two weeks to fix and Tek likely does not know much else beyond that or whatever else they have been told is under NDA. |
|
1 edit |
to JenSuisUn
DSL is kind of slow for me today. I live in Ontario and my download speed is like 10 when it should be 15 during ZTC not 10. Youtube is really slow after like 6pm today, both on and off VPN even though my latency is fine, I'm not too concerned though I'm sure things will improve.
I hope... |
|
1 edit |
to InvalidError
said by InvalidError Saturation is there, queues are overflowing and packets are getting dropped or it is not, queues remain generally empty and packets are going through with sub-millisecond delays as usual. The transition between the two can be brutal. Yes, the transition is rapid but it is not constant.There are spikes before the entire line is saturated. Over time and as BW use approaches constant saturation you can see an increment in spike frequency until full saturation is reached. These spikes are hitting max saturation point, but they subside. That's the point. That's the pattern... which is not visible here. said by InvalidError Tek likely does not know much else beyond that or whatever else they have been told is under NDA. Which is precisely my point. NDAs are a tad drastic for simple "tech" problems. Somebody is doing heavy CYA. |
|
SimplePandaBSD Premium Member join:2003-09-22 Montreal, QC |
to JenSuisUn
I don't mind that TekSavvy is waiting on maintenance from Bell - if it's on Bell's end it's on Bell's end.
What bothers me is the feeling that TekSavvy seems like they're maybe intentionally obfuscating / dodging us as far as providing an explanation as to what the problem is.
I've come to expect really high levels of transparency from TekSavvy as that's how they've always acted in the past. |
|