 c2rothPremium
join:2006-04-26
Kitchener, ON
kudos:2 | reply to TSI Marc
Re: Changes in Bell AGAS network I am the only one thinking now that CNOC totally missed this point when the CRTC released this decision? Or just that nobody has acted on it... |
|
 GuspazGuspazPremium,MVM
join:2001-11-05
Montreal, QC
kudos:20 | reply to squircle
Wups, missed that. |
|
brad
join:2007-09-06
Etobicoke, ON | reply to InvalidError
said by InvalidError:Even if incumbents could prove that they use mostly 1GbE, this is so outdated they would deserve a kick in the pants for not refreshing their equipment sooner. Except none of the incumbents would be so its a moot point. |
|
 TSI MarcPremium,VIP
join:2006-06-23
Chatham, ON
kudos:14 | reply to TSI Marc
Ok, I just received word from Bell about those 4 links. It turns out they are being proactive and that there is nothing going on with the existing links. Which makes sense since I could see it...
So as it stands now, the links are increasingly balancing out, we keep tweaking to try to make sure the capacity is best used but some links are still running a bit hot while others are not at all. Once everything balances out fully we should should be good for a while.
--
Marc - CEO/TekSavvy |
|
 zacronPremium
join:2008-11-26
canada | COuld you please flesh this out a little more?
Thanks,
Zacron
--
"Recognize, Realize, and Repent" |
|
 rjbrakePremium
join:2010-06-19
Petawawa, ON | reply to Guspaz
"and had to constantly appologize for the stream freezing to buffer."
First World Problems |
|
| reply to zacron
said by zacron:COuld you please flesh this out a little more? In the past, this used to mean they kill sessions on overloaded links and hope they will come back on one of their more over-used links.
Even earlier than that, I think it used to be pushing the "Big Red Button" and wiping all sessions on either a whole link or a whole ERX. |
|
GuspazGuspazPremium,MVM
join:2001-11-05
Montreal, QC
kudos:20 | reply to TSI Marc
I never understood that. Why not simply stop accepting new logins on the overloaded links? If a customer randomly gets assigned to it by the round-robin, it fails, their PPPoE client retries seamlessly to the client, and they connect elsewhere.
Over time, the load balances out.
By this mechanism, a wholesale ISP can pretty effectively keep any link from getting overloaded, even stuck with round-robin; if any link goes above a certain threshold, stop accepting new connections on it.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org |
|
brad
join:2007-09-06
Etobicoke, ON | reply to rjbrake
said by rjbrake:"and had to constantly appologize for the stream freezing to buffer."
First World Problems
Saying that doesn't make it any more acceptable. |
|
UK_Dave
join:2011-01-27
Powassan, ON
kudos:2 Reviews:
 ·TekSavvy DSL
·Bell Sympatico
| reply to TSI Marc
So now I'm confused - it doesn't take much at the best of times.
Are you saying there is a defined problem, and it's affecting DSL capacity, and it's going to be fixed? Or is it a "I thought there was a problem to fix but actually there isn't"?
An unworkable internet all evening, seven days a week, is starting to take it's toll. And I mean unusuable - 800ms to 1000+ms pings - means no gaming, no browsing, no web-based email, no videos even at lowest resolution
Is there a date I can wait for? A project about to go live? |
|
brad
join:2007-09-06
Etobicoke, ON | reply to Guspaz
said by Guspaz:I never understood that. Why not simply stop accepting new logins on the overloaded links? If a customer randomly gets assigned to it by the round-robin, it fails, their PPPoE client retries seamlessly to the client, and they connect elsewhere.
Over time, the load balances out.
By this mechanism, a wholesale ISP can pretty effectively keep any link from getting overloaded, even stuck with round-robin; if any link goes above a certain threshold, stop accepting new connections on it.
and how is that supposed to work exactly? Easier said then done. |
|
 TSI GabePremium,VIP
join:2007-01-03
Chatham, ON
kudos:2 | reply to UK_Dave
800ms-1000ms? That's not normal at all. You've got something else altogether going on. |
|
TSI GabePremium,VIP
join:2007-01-03
Chatham, ON
kudos:2 | reply to Guspaz
said by Guspaz:I never understood that. Why not simply stop accepting new logins on the overloaded links? If a customer randomly gets assigned to it by the round-robin, it fails, their PPPoE client retries seamlessly to the client, and they connect elsewhere.
Over time, the load balances out.
By this mechanism, a wholesale ISP can pretty effectively keep any link from getting overloaded, even stuck with round-robin; if any link goes above a certain threshold, stop accepting new connections on it.
I looked into this, it doesn't work, PPPoE doesn't implement any error code mechanism that says "try again", returning invalid username or password makes a lot of clients freak out and not replying at all causes even more problems.
We've got something coming up very soon that will fix all of this, at this point though I'm not sure I'm allowed to talk about it.
--
TSI Gabe - TekSavvy Solutions Inc.
Authorized TSI employee ( »TekSavvy FAQ »Official support in the forum )
|
|
UK_Dave
join:2011-01-27
Powassan, ON
kudos:2 Reviews:
·TekSavvy DSL
·Bell Sympatico
| reply to TSI Gabe
Check the multiple tests and postings on my account.
It's been that way for months.
It's not wiring or hardware. I've replaced the whole damn lot. Including the demarc and internal wiring.
Normal daytime/overnight - I get 35ms to 40ms pings - so I know it's congestion related.
The only question is who is congested, and who has ownership of this problem to get it fixed. I have the ticket number you raised with Bell, but after a "slow speed pattern match" response, nothing has been done despite there supposedly being a marker on my file for someone to be following it up.
As the folks on TSI IRC know - I've actually changed my hours of work to fit in around the unusable connection.
EDIT: In my head, I'm giving it till around spring. At that point, I'm going to have to cancel if it's not in hand. |
|
| reply to InvalidError
this is a teksavvy capacity issue has nothing to do with bell. when i worked at bell we had a capacity issue....they ran out of ips....why did that happen....some manager looked at the ammount of calls related to login errors...to this day they still insist on the bi b1 bl so they deciced to send out modems that could login and retain the user id and password,..worked wonders until those clients snagged every ip bell had,...chris spent over a month running a script that hit al those modems and changed it to connect on demand...this is a capacity issue and teksavvy is snot being honest about it.
if the slowdowns ae just youtube related then they need to come up with a response to that,,,,.if it si everything slow in specific arears then its a capacity issue |
|
 nitzguyPremium
join:2002-07-11
Sudbury, ON
·TekSavvy DSL
| reply to TSI Gabe
said by TSI Gabe:said by Guspaz:I never understood that. Why not simply stop accepting new logins on the overloaded links? If a customer randomly gets assigned to it by the round-robin, it fails, their PPPoE client retries seamlessly to the client, and they connect elsewhere.
Over time, the load balances out.
By this mechanism, a wholesale ISP can pretty effectively keep any link from getting overloaded, even stuck with round-robin; if any link goes above a certain threshold, stop accepting new connections on it.
I looked into this, it doesn't work, PPPoE doesn't implement any error code mechanism that says "try again", returning invalid username or password makes a lot of clients freak out and not replying at all causes even more problems. We've got something coming up very soon that will fix all of this, at this point though I'm not sure I'm allowed to talk about it. Mentioning something....means you've already talked about it  . Just pointing things out.
There used to be issues on this on the cable side way back in the D1 days....where there might be 4 downstream channels for a certain area but for some reason all the modems locked onto 1 channel overloading it leaving the other channels relatively unused...
But I know its not the same with DSL, but there has to be a way to balance...somehow....somehow!!!  |
|
brad
join:2007-09-06
Etobicoke, ON | reply to noemails
said by noemails :this is a teksavvy capacity issue has nothing to do with bell.
Actually it has everything to do with Bell. The connections are spread across the 30 odd links that TSI has and its the poor load balancing from Bell that results in some links being under utilized and others being over utilized. If Bell offered 10Gb AGAS ports as they should have been 2-3 years ago this wouldn't be an issue. |
|
|
|
GuspazGuspazPremium,MVM
join:2001-11-05
Montreal, QC
kudos:20 | reply to brad
said by brad:and how is that supposed to work exactly? Easier said then done. Much the same way WE did it on the client end in our MLPPP software. The problem that Gabe points out would make things difficult, however. From a protocol level, there are things you could do to abort the connection without sending a invalid username/password error; simply present the user with a set of parameters that it will find unacceptable during the negotiation. But TSI doesn't use software-based endpoints, so that wouldn't work. All that you're left with the the don't-reply-at-all method, which has issues in that the timeout is rather long and that could seriously degrade the customer experience.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org |
|
brad
join:2007-09-06
Etobicoke, ON | said by Guspaz:said by brad:and how is that supposed to work exactly? Easier said then done. Much the same way WE did it on the client end in our MLPPP software. The problem that Gabe points out would make things difficult, however. From a protocol level, there are things you could do to abort the connection without sending a invalid username/password error; simply present the user with a set of parameters that it will find unacceptable during the negotiation. But TSI doesn't use software-based endpoints, so that wouldn't work. All that you're left with the the don't-reply-at-all method, which has issues in that the timeout is rather long and that could seriously degrade the customer experience. It's not just that. You need to know if those 30 odd links are overloaded and to do so in real-time. AFAIK those links are not directly terminated on the routers. That just adds another level of complexity to the situation when it comes to trying to come up with this magic mechanism. In the end this still would not guarantee that the links could not be overloaded or that the load balancing would still be optimal. |
|
GuspazGuspazPremium,MVM
join:2001-11-05
Montreal, QC
kudos:20 | said by brad:It's not just that. You need to know if those 30 odd links are overloaded and to do so in real-time. AFAIK those links are not directly terminated on the routers. That just adds another level of complexity to the situation when it comes to trying to come up with this magic mechanism. In the end this still would not guarantee that the links could not be overloaded or that the load balancing would still be optimal. TekSavvy already measures the throughput of their AHSSPI links, presumably via SNMP. You don't need real-time measurements to decide if you should enable/disable the behaviour on a particular link, polling every 5 minutes as SNMP graphic software typically does is sufficient.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org |
|
