dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
11370

JenSuisUn
Premium Member
join:2006-02-23
Chatham, ON

1 edit

JenSuisUn

Premium Member

[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
notfred
join:2012-09-15

notfred

Member

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

JenSuisUn

Premium Member

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

DataRiker
Premium Member
join:2002-05-19
00000

DataRiker

Premium Member

Discovered the issue but no specifics???
Expand your moderator at work
bohn
join:2006-05-30
Scarborough, ON

bohn to DataRiker

Member

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?

Cho Baka
MVM
join:2000-11-23
there

Cho Baka to JenSuisUn

MVM

to JenSuisUn
Sooner would be apprecaited, if possible.
lowping
join:2013-08-04

lowping to bohn

Member

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 ?
bjlockie
join:2007-12-16
Ontario
Technicolor TC4350
Asus RT-AC56
Grandstream HandyTone 702/704

bjlockie

Member

said by lowping:

Did you even read the title ?

I thought everyone knew that Bell DSL uses the underlying Cable provided by Rogers.
bjlockie

bjlockie to DataRiker

Member

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.

torobull123
join:2009-06-20

1 edit

torobull123 to JenSuisUn

Member

to JenSuisUn
Teksavvy congestion? Backbone congestion/problems?
dra6o0n
join:2011-08-15
Mississauga, ON

dra6o0n to bjlockie

Member

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.
lowping
join:2013-08-04

1 edit

lowping to bjlockie

Member

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 ?

Gwai Lo Dan
join:2007-01-24
Mississauga, ON

Gwai Lo Dan to JenSuisUn

Member

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?
Expand your moderator at work
globus999
join:2008-05-15

globus999 to JenSuisUn

Member

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

globus999 to lowping

Member

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

TSI Andre to globus999

Premium Member

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.
lowping
join:2013-08-04

lowping to globus999

Member

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 ?
InvalidError
join:2008-02-03

1 recommendation

InvalidError to globus999

Member

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.
globus999
join:2008-05-15

globus999

Member

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

globus999 to TSI Andre

Member

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

TSI Andre

Premium Member

:/

I'm working on getting/providing more details.

Thanks for your patience.
InvalidError
join:2008-02-03

InvalidError to globus999

Member

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.
globus999
join:2008-05-15

globus999

Member

said by InvalidError:

outside peak hours

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.
said by InvalidError:

You may call it conspiracy if you wish

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.
InvalidError
join:2008-02-03

InvalidError

Member

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.
i_pk_pjers_i
join:2007-04-20
none

1 edit

i_pk_pjers_i to JenSuisUn

Member

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...
globus999
join:2008-05-15

1 edit

globus999 to InvalidError

Member

to InvalidError

said by InvalidError See Profile
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 See Profile
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.

SimplePanda
BSD
Premium Member
join:2003-09-22
Montreal, QC

SimplePanda to JenSuisUn

Premium Member

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.