| reply to Webslingerac
Re: Time for a stop sell on McNicoll POI? 4:15pm
on 18/0.5
 |
|
| 
Still pretty good at 6:47 p.m. EST.
We'll see what happens around 9:30 p.m. EST, when congestion is typically bad. |
|
 SimGuy
join:2002-01-06
Toronto, ON | reply to Webslingerac
Yay - Salem POI :X
28/1 Cable.
 |
|
1 edit | reply to Webslingerac
9:30 p.m. EST
Yeah, Marc this isn't good. Honestly, if you were a 28/1 customer, I don't think you'd be happy with this either. 
If you believe this is node congestion, please ask Rogers to do something. Thank you |
|
koreybReplace the CRTC NOW
join:2005-01-08
East York, ON Reviews:
 ·TekSavvy Cable
 ·voip.ms
| said by Webslingerac: [att=1]
9:30 p.m. EST
Yeah, Marc this isn't good. Honestly, if you were a 28/1 customer, I don't think you'd be happy with this either.
If you believe this is node congestion, please ask Rogers to do something. Thank you
IF you have a D3 modem, TSI can ask, but node congestion will effect both rogers and TSI customers, but it's doubtful they will do anything with it at 15mb for any speed level, for node congestion as it involves a bit of major network splitting. I would almost try a factory reset on your modem, to try and get different channels. |
|
2 edits | Well, granted, it's about an hour later, but I seem to be getting far better results from the St. Catherines speedtest server right now than Teksavvy's.
I'll try downloading a large game from Steam and see what happens. But really, it's better for me to test at 9:30 p.m.
And by the way, I did reset my modem.
I'm getting about 3.0-3.1 MB/s, which isn't bad, but it's not 9:30 p.m. anymore. It's 11:00 p.m.
I suppose if I'm inconvenienced for 1.5 hrs every night that's not too bad, I guess, but with more and more subscribers from Rogers and Teksavvy, I can't see this situation improving. |
|
| reply to Webslingerac
6:30pm on 18/.5
|
|
4 edits | said by A A:6:30pm on 18/.5
Yeah, the problem doesn't start happening until around 9:30 p.m.
6:30 is always fine; testing at 6:30 is meaningless.
Try testing between 9:30p.m. and 10:30 p.m.
This is like clockwork here every night after 9:15 p.m. (until about 11 p.m. - 12 a.m. when the congestion slowly dissipates):
Teksavvy:
Nexicom:
Beanfield:
I'm not sure where the problem is occurring, but this is congestion. And I just started downloading files from other servers, and I'm seeing poor download speeds as well right now. So with 28/1 service (SB6120 D3 modem), I'm getting pretty frustrated.
If Teksavvy doesn't want to go to bat over this, then, as much as I hate doing it, I'll start looking elsewhere. My neighbour (Rogers customer) claims he isn't having problems (but I haven't invited myself in to double check at 9:30 p.m. either).
Marc says there's a ton of extra capacity on McNicoll, but something is clearly wrong here after 9:15 p.m. until about 11 p.m. at least on weekdays.
I have no doubts that my problem (an hour or two of inconvenience) each night is minor compared to other people's connection issues, but it's beginning to get frustrating. |
|
| hey man, i am right there with you -- after 1.5 years of paying full price for half speeds, then finally getting the upgrade in October, to be whacked like this again, only 4 months later is pretty frustrating -- especially with all the other (non speed related)issues Teksavvy is experiencing lately this isn't good for me -- this is supposed to be 28/1
Cable Signal Details
Forward Path:
Channel Frequency Power SNR BER Modulation
1 663.0 MHz -0.6 dBmV 38.2 dB 0.000 % 256 QAM
2 615.0 MHz -0.9 dBmV 38.2 dB 0.000 % 256 QAM
3 621.0 MHz -0.6 dBmV 38.2 dB 0.000 % 256 QAM
4 633.0 MHz -0.2 dBmV 38.2 dB 0.000 % 256 QAM
5 639.0 MHz -0.1 dBmV 38.2 dB 0.000 % 256 QAM
6 645.0 MHz -0.1 dBmV 38.2 dB 0.000 % 256 QAM
7 651.0 MHz -0.4 dBmV 38.2 dB 0.000 % 256 QAM
8 657.0 MHz -0.6 dBmV 37.9 dB 0.001 % 256 QAM
Return Path:
Channel ID Frequency Power Modulation
7 22.1 MHz 46.0 dBmV 16 QAM
3 31.3 MHz 46.0 dBmV 16 QAM
4 25.3 MHz 46.0 dBmV 16 QAM
8 38.6 MHz 46.5 dBmV 16 QAM
|
|
| At 9:46 p.m. on a Sunday
Teksavvy:
Nexicom:
Beanfield:
 |
|
1 edit | Actually started sucking a couple of hours earlier today (on a Sunday).
mcnicoll3.cable.teksavvy.com (69.165.168.146) is dropping packets (occasionally).
|---------------------------------------------------------------------------------- --------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 10.126.167.1 - 0 | 102 | 102 | 7 | 11 | 22 | 13 |
| 24.156.149.57 - 0 | 102 | 102 | 9 | 15 | 40 | 11 |
| mcnicoll3.cable.teksavvy.com - 2 | 98 | 97 | 9 | 14 | 91 | 10 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
Getting packet loss here:
Pinging yahoo.ca [98.139.102.145] with 32 bytes of
Reply from 98.139.102.145: bytes=32 time=43ms TTL=5
Reply from 98.139.102.145: bytes=32 time=43ms TTL=5
Reply from 98.139.102.145: bytes=32 time=41ms TTL=5
Reply from 98.139.102.145: bytes=32 time=42ms TTL=5
Reply from 98.139.102.145: bytes=32 time=44ms TTL=5
Reply from 98.139.102.145: bytes=32 time=47ms TTL=5
Reply from 98.139.102.145: bytes=32 time=41ms TTL=5
Reply from 98.139.102.145: bytes=32 time=49ms TTL=5
Reply from 98.139.102.145: bytes=32 time=40ms TTL=5
Reply from 98.139.102.145: bytes=32 time=42ms TTL=5
Reply from 98.139.102.145: bytes=32 time=42ms TTL=5
Reply from 98.139.102.145: bytes=32 time=44ms TTL=5
Reply from 98.139.102.145: bytes=32 time=42ms TTL=5
Reply from 98.139.102.145: bytes=32 time=41ms TTL=5
Reply from 98.139.102.145: bytes=32 time=45ms TTL=5
Reply from 98.139.102.145: bytes=32 time=44ms TTL=5
Reply from 98.139.102.145: bytes=32 time=65ms TTL=5
Reply from 98.139.102.145: bytes=32 time=43ms TTL=5
Reply from 98.139.102.145: bytes=32 time=49ms TTL=5
Request timed out.
Reply from 98.139.102.145: bytes=32 time=42ms TTL=5
Request timed out.
Reply from 98.139.102.145: bytes=32 time=41ms TTL=5
Reply from 98.139.102.145: bytes=32 time=41ms TTL=5
Reply from 98.139.102.145: bytes=32 time=42ms TTL=5
Reply from 98.139.102.145: bytes=32 time=41ms TTL=5
Reply from 98.139.102.145: bytes=32 time=42ms TTL=5
Reply from 98.139.102.145: bytes=32 time=40ms TTL=5
Reply from 98.139.102.145: bytes=32 time=40ms TTL=5
Reply from 98.139.102.145: bytes=32 time=46ms TTL=5
Reply from 98.139.102.145: bytes=32 time=43ms TTL=5
Reply from 98.139.102.145: bytes=32 time=41ms TTL=5
Reply from 98.139.102.145: bytes=32 time=41ms TTL=5
Reply from 98.139.102.145: bytes=32 time=41ms TTL=5
Request timed out.
Reply from 98.139.102.145: bytes=32 time=44ms TTL=5
Reply from 98.139.102.145: bytes=32 time=47ms TTL=5
Reply from 98.139.102.145: bytes=32 time=44ms TTL=5
Reply from 98.139.102.145: bytes=32 time=44ms TTL=5
Reply from 98.139.102.145: bytes=32 time=40ms TTL=5
Reply from 98.139.102.145: bytes=32 time=43ms TTL=5
Request timed out.
Reply from 98.139.102.145: bytes=32 time=43ms TTL=5
Reply from 98.139.102.145: bytes=32 time=42ms TTL=5
Reply from 98.139.102.145: bytes=32 time=42ms TTL=5
Reply from 98.139.102.145: bytes=32 time=41ms TTL=5
Reply from 98.139.102.145: bytes=32 time=48ms TTL=5
Reply from 98.139.102.145: bytes=32 time=42ms TTL=5
Reply from 98.139.102.145: bytes=32 time=43ms TTL=5
Reply from 98.139.102.145: bytes=32 time=41ms TTL=5
Ping statistics for 98.139.102.145:
Packets: Sent = 50, Received = 46, Lost = 4 (8%
Approximate round trip times in milli-seconds:
Minimum = 40ms, Maximum = 65ms, Average = 43ms
|
|
|
|
| Getting some packet loss from 24.156.149.57 as well as from mcnicoll3 tonight:
|---------------------------------------------------------------------------------- --------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|
| 10.126.167.1 - 0 | 55 | 55 | 10 | 13 | 18 | 14 |
| 24.156.149.57 - 2 | 52 | 51 | 12 | 16 | 36 | 21 |
| mcnicoll3.cable.teksavvy.com - 2 | 51 | 50 | 11 | 18 | 118 | 13 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider |
|
| I'm a geek - but not a network geek - so the discourse here is over my head.
Is it fair to say that TSI has problems on McNicoll (and possibly Comstock?), and that a consumer move to Start communications might be a faster option to fix the problem?
I'm not throwing stones, I just want reliable service. |
|
1 edit | said by byebye_cable :
Is it fair to say that TSI has problems on McNicoll (and possibly Comstock?)
They may.
However, the problem might also be node congestion, in which case, the problem is Rogers.
quote:
and that a consumer move to Start communications might be a faster option to fix the problem?
Not if the problem is node congestion (if you have a neighbour on Rogers, is he/she also having problems? If so, moving to Start won't help)
Marc claims there's plenty of capacity on McNicoll. Regardless, I'm certainly experiencing congestion after 9 p.m. My neighbour (on Rogers) says he isn't having problems, so I'm not sure.
In the end, I'm not receiving the speeds I'm paying for after 9p.m. |
|
Reviews:
 ·TekSavvy DSL
| reply to Webslingerac
At 9:52pm, on 18/0.5 connection
|
|
| Yeah, not much fun on McNicoll POI between 9 p.m. and 11 p.m. lately (28/1)
Teksavvy:
Nexicom:
Beanfield:
|
|
| reply to Webslingerac
SlowSavvy |
|
|
1 edit | said by captainpc:I am on the same POI.. look at my speed during peak hours..
If you're on the same POI, don't test from Oakville. Try closer servers from Toronto.
Not sure why you're posting shopped images. Click "share this result" after testing, select "forum", and click "copy". Then just paste when you reply. |
|
| 
on 28/1 scarlett poi.. diconnections during the day also.. |
|
| said by Robleh:on 28/1 scarlett poi.. diconnections during the day also..
That's unfortunate. Yeah, the problem for me occurs during very specific times (usually between 9:30 p.m. and 11 p.m.--but lately, the problem starts earlier around 9 p.m.). After 11 p.m. the congestion improves--and after midnight the congestion seems to go away. But we're on different POIs. |
|
