dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
7527
share rss forum feed

bjlockie

join:2007-12-16
Ottawa, DSL
Reviews:
·TekSavvy DSL
reply to robinjames

Re: [DSL] 50/10 VDSL2 upgrade arrived. :)

said by robinjames:

SIGH.

I wish I had the previous thread about the speed issues before I ordered 50/10... I have my Sagemcom in bridge mode to a pfsense box, and I have a /28 subnet. Will have fun tonight trying to get the subnet routed on the fricken Sagemcom...... f%$#$%#%ck.

I expect the modem situation to be cleared up in a few weeks.
Ideally new firmware will fix the Sagemcom or another modem will be supported.


Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
reply to SimplePanda
I'm busy gathering stats from both the Cellpipe and Sagemcom. I'll post soon. Results might surprise you: Cellpipe beats the Sagemcom in both bridged and routed mode (yes, it the Cellpipe does 50 routed)
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org

vdsl_n00b

join:2013-03-26
Some fantastic info here guys. ihave been lurking here for a while and i just recently thought about upgrading to 50/10 from my basic 6meg... i had no idea with this whole mess with the modems.


HiVolt
Premium
join:2000-12-28
Toronto, ON
kudos:21
Reviews:
·TekSavvy DSL
·TekSavvy Cable
reply to Guspaz
said by Guspaz:

I'm busy gathering stats from both the Cellpipe and Sagemcom. I'll post soon. Results might surprise you: Cellpipe beats the Sagemcom in both bridged and routed mode (yes, it the Cellpipe does 50 routed)

Odd, I dont remember seeing any difference when i tested it in routed mode, albeit it was briefly... Both bridged & routed seemed to max out around 41-42mbps for me...

I wonder if there are hardware revisions that make a difference?
--
F**K THE NHL. Go Blue Jays 2013!!!

kovy7

join:2009-03-26
kudos:8
reply to SimplePanda
I don't see how the Sagemcom would do worst in routed then Cellpipe... the Sagemcom even works @ 75mbps.


Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23

3 edits

1 recommendation

reply to SimplePanda
Fun fact: if you connect to the Sagemcom and try to browse the web, you will be sent to the Sympatico activation page. That and all the documentation talks about Bell, and contact Bell for support, and the requirement is a Bell subscription. No, this won't confuse people at all...

NOTE: This is on a stinger.

Cellpipe Bridged (Netgear WNDR3700v2)
39.47/10.00
38.49/10.04
39.51/9.98
39.57/10.14
39.60/10.08

Cellpipe Bridged (Windows 8 PPPoE client)
39.64/9.38
39.79/9.04
40.00/9.62
39.35/9.26
39.46/9.38

Cellpipe Routed (Windows 8 LAN)
50.71/9.79
50.76/9.79
50.51/9.71
50.68/9.71
50.46/9.66

Sagemcom Bridged (Netgear WNDR3700v2)
33.23/9.07
33.62/9.13
34.28/9.46
34.01/9.34
33.72/9.50

Sagemcom Bridged (Windows 8 PPPoE client)
33.59/9.95
33.00/9.86
33.08/9.86
33.22/9.93
33.09/9.97

Sagemcom Routed (Windows 8 LAN)
50.11/9.13
50.30/9.63
48.14/9.59
50.56/9.40
50.64/9.70

Sagemcom DMZ (Netgear WNDR3700v2 as router)
50.38/9.99
50.42/9.96
50.47/9.97
50.55/10.00
50.60/9.98

Sagemcom Info

Firmware Version
FAST2864_v6740S

Rescue Version
FAST2864_v7740S

Hardware Version
2864-000000-002

Hidden authors
Nafaa ZAYEN & Wael MAAOUI

Hidden copyright notice
Copyright (c) 2010 SAGEMCOM. All Rights Reserved. Residential Gateway Software Division www.sagem.com This file is part of the SAGEM Communications Software and may not be distributed, sold, reproduced or copied in any way without explicit approval of SAGEM Communications. This copyright notice should not be removed in ANY WAY.

Cellpipe Line Stats (from modem)

Info
VDSL2 Firmware Version: 9.3.2.6IK105012
VDSL Estimated Loop Length: 238 ft
G.Hs Estimated Near End Loop Length: 144 ft
G.Hs Estimated Far End Loop Length: 511 ft

Downstream
Downstream line rate: 61368 kbps
Bearer Downstream payload rate: 53944 kbps
Downstream attainable line rate: 72036 kbps
Downstream attainable payload rate: 59060 kbps
Downstream Training Margin: 10.3 dB
Downstream delay: 0.8 ms
FE Tx total power: 14.2 dbm

Upstream
Upstream line rate: 13108 kbps
Bearer Upstream payload rate: 11320 kbps
Upstream delay: 0.0 ms
Tx total power: -22.8 dbm

Cellpipe Line Stats (from Bell)

Downstream
Speed (Kbs): 53944
Relative Capacity Occupation (%): 94
Noise Margin (0 - 31 dB): 8
Signal Power (0 - 20 dBm): 14
Attenuation (0 - 60 dB): 6
Block Count: 1381
Attainable Sync Rate: 57304

Upstream
Speed (Kbs): 11320
Relative Capacity Occupation (%): 72
Noise Margin (0 - 31 dB): 8
Signal Power (0 - 20 dBm): -22
Attenuation (0 - 60 dB): 6
Block Count: 1401
Attainable Sync Rate: 15640

Sagemcom Line Stats (from Bell, 7 meg upstream profile)

Downstream
Operational Status Speed (Kbs): 53936
Relative Capacity Occupation (%): 86
Noise Margin (0 - 31 dB): 10
Signal Power (0 - 20 dBm): 14
Attenuation (0 - 60 dB): 7
Block Count: 65906528
Attainable Sync Rate: 62684

Upstream
Operational Status Speed (Kbs): 8120
Relative Capacity Occupation (%): 71
Noise Margin (0 - 31 dB): 9
Signal Power (0 - 20 dBm): -22
Attenuation (0 - 60 dB): 6
Block Count: 54783788
Attainable Sync Rate: 11424

Sagemcom Line Stats (from Bell, 10 meg upstream profile)

Downstream
Operational Status Speed (Kbs): 53936
Relative Capacity Occupation (%): 86
Noise Margin (0 - 31 dB): 10
Signal Power (0 - 20 dBm): 14
Attenuation (0 - 60 dB): 7
Block Count: 25
Attainable Sync Rate: 62584

Upstream
Operational Status Speed (Kbs): 11320
Relative Capacity Occupation (%): 87
Noise Margin (0 - 31 dB): 7
Signal Power (0 - 20 dBm): -22
Attenuation (0 - 60 dB): 6
Block Count: 466
Attainable Sync Rate: 13000

Note
The two sets of line stats are because at some point overnight, Bell dropped my profile from 10 down to 7 meg upstream while I was using the Sagemcom, and I got the line stats while it was on that reduced profile. They did this because the attainable upstream was borderline for the 10 meg sync (only 100 kilobit higher than the 10 meg sync speed). This was suspicious, as the Cellpipe had an attainable speed 50% higher, so I asked Bell to set the profile back to 10 meg and pull the line stats again, which is the second set of line stats you see. In this case you see the upstream attainable has gone up by two megabit, giving me a healthy margin on the upstream this time around.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org


Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
reply to SimplePanda
As you can imagine, I've chosen to use the Sagemcom DMZ mode. I disabled just about everything on the Sagemcom except DHCP, gave my Netgear a reserved DHCP entry of 192.168.2.2, and then set the Sagemcom to use 192.168.2.2 as a DMZ host. This causes the Sagemcom to forward all inbound traffic to the Netgear (essentially, NAT forward all ports/protocols).

The Netgear is then configured as a DHCP client on its WAN port, much like you would with cable internet. It can then do anything it could do before; port forwarding configurations on the Netgear work, UPnP on the Netgear work (my torrent client is connectable)... I'm not seeing any side effects. I'm getting the advantage of the full speed, but keeping all of my routing/config on the Netgear.

Is it ideal? No, I'd rather have my Netgear act as the PPPoE client. But until that issue gets resolved, this would seem to be the next best thing (it's the least disruptive to my network setup).

EDIT: I realize that there could be side-effects due to the strangeness that will go on with source port rewriting, but I don't think I do anything complex enough to matter for that. Even my GRE-based PPTP VPN to the office works.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org


FiberToTheX
Premium
join:2013-03-14
Reviews:
·Start Communicat..
reply to SimplePanda
50/10 is impressive. However the upload is limited in that aspect. I think symmetrical connections such as Beanfield's 100/100 FTTH is more impressive and cheaper too.

Congrats on the 50/10 upgrade. Mind If I ask where in Toronto you are located ?


SimplePanda
Go Habs Go
Premium
join:2003-09-22
Toronto, ON
Reviews:
·Rogers Hi-Speed
said by FiberToTheX:

50/10 is impressive. However the upload is limited in that aspect. I think symmetrical connections such as Beanfield's 100/100 FTTH is more impressive and cheaper too.

Congrats on the 50/10 upgrade. Mind If I ask where in Toronto you are located ?

High Park.

smartel

join:2008-05-31
Brossard, QC

1 recommendation

reply to Guspaz
Is there any hope to get IPv6 working with a setup like that? Is there any trace of IPv6 config options in the Sagemcom configuration pages?


SimplePanda
Go Habs Go
Premium
join:2003-09-22
Toronto, ON
Reviews:
·Rogers Hi-Speed

1 recommendation

said by smartel:

Is there any hope to get IPv6 working with a setup like that? Is there any trace of IPv6 config options in the Sagemcom configuration pages?

Nope, though you can do 6in4 tunnelling to he.net probably.

kovy7

join:2009-03-26
kudos:8
reply to SimplePanda
So Cellpipe does do 50mbps no problem, that's what I taught. Only bridge mode problem like the Sagemcom.


SimplePanda
Go Habs Go
Premium
join:2003-09-22
Toronto, ON
Reviews:
·Rogers Hi-Speed

1 edit
reply to Guspaz
Did a little experimenting to extend what Guspaz did.

I'm finding the best results that I'm happy with like this:

1. On Sagemcom, give it a LAN IP, say 192.168.0.1.
2. Disable DHCP on Sagemecom. For this you'll probably need to configure your computer IP's manually to finish configuring it so set your computer to like 192.168.0.100 with 255.255.255.0 subnet.
3. Disable UPnP on Sagemcom.
4. Set the DMZ on the Sagemcom to 192.168.0.2
5. On your router, set your WAN IP to static and configure your WAN address as 192.168.0.2, gateway 192.168.0.1, DNS 192.168.0.1, netmask 255.255.255.0.
6. Configure your router LAN as you like (I use 172.16.x.x).
7. Switch your computer back to DHCP if you had to in step #2.

This prevents routers with bad DHCP handling from renewing their address on the WAN side and clearing their UPnP/NAT-PMP entries (Tomato USB is bad for this in my experience, flushing all UPnP whenever a DHCP renew happens).

At this point Skype and Google Talk work fine so NAT-traversal is happening correctly.

Using »nattest.net.in.tum.de to analyze the NAT operation shows no relevant / debilitating difference between the native NAT on my router and the DMZ passthrough from the Sagemcom.

Performance in this configuration:




Looks like this solution will suffice until bridging firmware arrives.

jmagder

join:2011-02-09
Markham, ON
reply to Guspaz
Guspaz, thank you for such a thorough posting! The DMZ setup seems ideal, no different than what I have right now with cable from the perspective of the router. If possible keep us posted on the upstream profile. I wonder if they changed it because of all your modem fiddling. The upstream is the deal breaker for me.


SimplePanda
Go Habs Go
Premium
join:2003-09-22
Toronto, ON
Reviews:
·Rogers Hi-Speed
reply to kovy7
said by kovy7:

So Cellpipe does do 50mbps no problem, that's what I taught. Only bridge mode problem like the Sagemcom.

This may also depend on firmware. Someone else was saying it wouldn't. I know Guspaz is on a stinger and Bell replaced my 7330 CellPipe when I upgraded to 50/10 so there might be something there.


Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23

1 recommendation

reply to SimplePanda
smartel: IPv6 should work fine with bridged mode (my Netgear even has IPv6 support for PPPoE), but I'm not sure if the Sagemcom supports IPv6 itself, so probably not. To be honest, I'm not a fan of IPv6, and I'd take a 50% speed boost over IPv6 any day. As SimplePanda pointed out, you can do 6to4: my Netgear also has an option for doing that, which should work fine through the double NAT.

kovy: Yep, the Cellpipe does 50 meg routed, on the stinger firmware at least. Also of note is that the Cellpipe seems to produce significantly worse downstream attainable rates than the Sagemcom, but at the same time the Cellpipe produces significantly better upstream attainable rates than the Sagemcom.

SimplePanda: I'm sure there are some obscure scenarios where the DMZ NAT setup would cause issues, since it still is double NAT. If two source machines try to send to the same remote host, and both pick the same source port (very unlikely, but possible), will the internal router rewrite the ports? If so, this might cause issues with things that rely on source port numbers like Hamachi (or other NAT traversal). In fact, NAT traversal stuff might in general not work with this setup. However, I don't use any NAT traversal stuff except UPnP (which does work fine), so my needs are pretty basic. I forward SSH to my server, remote desktop to my desktop, I let uTorrent open ports for itself with UPnP, and I use a PPTP (GRE) VPN for work, and all of that is working fine in this setup. It's not ideal, but it seems workable until the Sagemcom firmware gets fixed. On another note, one downside of disabling DHCP on the Sagemcom is that there is no way to pass the dynamically assigned DNS IPs through the double NAT without it. As in, the Sagemcom retrieves the TSI DNS IPs via PPPoE, and then the Sagemcom provides those DNS IPs to the Netgear via DHCP. Your setup uses the Sagemcom as a DNS proxy, while mine has the Netgear talk directly to TSI's DNS servers.

jmagder: There is one key difference in this setup, with a cable modem your internal router sees your WAN IP on its WAN interface. In the DMZ NAT scenario, your internal router sees something like 192.168.2.2 on the WAN interface, and there is a potential that some NAT traversal things that rely on predictable source port numbers may not work. But I don't use any such thing, so this seems workable for now.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org


SimplePanda
Go Habs Go
Premium
join:2003-09-22
Toronto, ON
Reviews:
·Rogers Hi-Speed
said by Guspaz:

SimplePanda: I'm sure there are some obscure scenarios where the DMZ NAT setup would cause issues, since it still is double NAT. If two source machines try to send to the same remote host, and both pick the same source port (very unlikely, but possible), will the internal router rewrite the ports? If so, this might cause issues with things that rely on source port numbers like Hamachi (or other NAT traversal). In fact, NAT traversal stuff might in general not work with this setup. However, I don't use any NAT traversal stuff except UPnP (which does work fine), so my needs are pretty basic. I forward SSH to my server, remote desktop to my desktop, I let uTorrent open ports for itself with UPnP, and I use a PPTP (GRE) VPN for work, and all of that is working fine in this setup. It's not ideal, but it seems workable until the Sagemcom firmware gets fixed. On another note, one downside of disabling DHCP on the Sagemcom is that there is no way to pass the dynamically assigned DNS IPs through the double NAT without it. As in, the Sagemcom retrieves the TSI DNS IPs via PPPoE, and then the Sagemcom provides those DNS IPs to the Netgear via DHCP. Your setup uses the Sagemcom as a DNS proxy, while mine has the Netgear talk directly to TSI's DNS servers.

As the port level NAT'ing for your internal LAN will happen on your Netgear router your, the Netgear will handle port collisions and rewriting. This would potentially be an issue even without a double NAT.

re: DNS forwarding my Sagemcom never assigns the TSI DNS's via DHCP - it always assigns itself as the proxy. I don't see a setting anywhere to adjust this. Strange. Either way, the only side effect of doing it this way is that you have to layers of caching so if you're moving servers on the WAN and re-assignign their IP addresses in the DNS you might have to wait for / reset two different devices to to fresh responses. Rarely an issue for me though. The Sagemcom -seems- to honour DNS TTL at least.


Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
reply to SimplePanda
True, it'd be the same problem even without double NAT for the source ports anyhow.

I thought it was giving me the TSI DNS IPs through DHCP, but I'm not sure. I'll try to remember to check when I get home. I don't trust the DNS caches in these home routers, I've had bad luck with them in the past. 99% of my activity is coming from my desktop, which has its own DNS cache, so I don't see the value in another layer of caching on my LAN between my desktop and TSI.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org


robinjames
Premium
join:2008-04-20
Ottawa, ON
Guspaz, do you know if you can place static routes on the sagemcom ? I haven't had a chance to look yet..


Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
reply to SimplePanda
I don't think so, but I'll try to take a look tonight. I didn't look too closely at the config pages I wasn't interested in since I wasn't planning to use the thing as a router beyond a dumb "fire everything!" forwarder.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org


robinjames
Premium
join:2008-04-20
Ottawa, ON
cool, I'll try to poke around tonight as well. I may just end up buying a zyxel (i'm on a 7330 remote) to restore bridge mode, since we will be able to return the rentals soon


SimplePanda
Go Habs Go
Premium
join:2003-09-22
Toronto, ON
Reviews:
·Rogers Hi-Speed

1 edit
reply to robinjames
said by robinjames:

Guspaz, do you know if you can place static routes on the sagemcom ? I haven't had a chance to look yet..

Alas, you cannot, nor can you disable the NAT functionality, which was actually my first thought: get a /30 from TekSavvy and disable the NAT and set the LAN as the /30, with the Sagemcom LAN as one of the IP's and my actual router as the other IP. This would effectively have the Sagemcom working as plain router with my internal LAN router doing NAT/UPnP.

Seems it won't work though. Mind, I haven't actually -tried- it, as the configuration options make me think that setting a public /30 as the LAN network will still incur actual NAT'ing on the 2864, thus negating the point.


SimplePanda
Go Habs Go
Premium
join:2003-09-22
Toronto, ON
Reviews:
·Rogers Hi-Speed

2 edits

1 recommendation

reply to smartel
said by smartel:

Is there any hope to get IPv6 working with a setup like that? Is there any trace of IPv6 config options in the Sagemcom configuration pages?

PING6(56=40+8+8 bytes) 2001:470:xx:yyy:9991:53f8:5eef:caee --> 2607:f8b0:4003:c01::5e
16 bytes from 2607:f8b0:4003:c01::5e, icmp_seq=0 hlim=55 time=35.864 ms
16 bytes from 2607:f8b0:4003:c01::5e, icmp_seq=1 hlim=55 time=38.312 ms
16 bytes from 2607:f8b0:4003:c01::5e, icmp_seq=2 hlim=55 time=38.155 ms
16 bytes from 2607:f8b0:4003:c01::5e, icmp_seq=3 hlim=55 time=35.732 ms

Another to google.ca (pretty decent latency):

16 bytes from 2607:f8b0:400b:801::101f, icmp_seq=0 hlim=58 time=8.205 ms
16 bytes from 2607:f8b0:400b:801::101f, icmp_seq=1 hlim=58 time=8.419 ms
16 bytes from 2607:f8b0:400b:801::101f, icmp_seq=2 hlim=58 time=10.447 ms
16 bytes from 2607:f8b0:400b:801::101f, icmp_seq=3 hlim=58 time=7.568 ms

6in4 tunnelling to TunnelBroker.net works without issue through the Sagemcom with the tunnel origin point as the DMZ. It still looks like TekSavvy's native IPv6 mostly dumps traffic onto he.net (which runs tunnelbroker.net) for transit, so I find that using 6in4 to their Toronto endpoint gives pretty equivalent performance for most applications. Not ideal compared to native but as I actually need IPv6 for work it's a workable replacement.

Looks like this solution will function well until a real bridging mode can be unlocked (and or cable 150/10 ATPIA is enabled in High Park, assuming it works well).


maybenot

@sunwave.com.br
reply to robinjames
said by robinjames:

cool, I'll try to poke around tonight as well. I may just end up buying a zyxel (i'm on a 7330 remote) to restore bridge mode, since we will be able to return the rentals soon

Checkout what Marc posted here: »Re: MODEM - Options Apparently bell's idea of BYOM means bring your own sagemcom purchased from bell. Hopefully they're working getting rid of that reqirement but you might want to wait on buying that zyxel.


SimplePanda
Go Habs Go
Premium
join:2003-09-22
Toronto, ON
Reviews:
·Rogers Hi-Speed
said by maybenot :

said by robinjames:

cool, I'll try to poke around tonight as well. I may just end up buying a zyxel (i'm on a 7330 remote) to restore bridge mode, since we will be able to return the rentals soon

Checkout what Marc posted here: »Re: MODEM - Options Apparently bell's idea of BYOM means bring your own sagemcom purchased from bell. Hopefully they're working getting rid of that reqirement but you might want to wait on buying that zyxel.

Not sure this is the case. I think the Marc suggested somewhere else (maybe later in that thread) that he thought Bell maybe wants your modem serial number for firmware update reasons rather than lock-out reasons.

There is apparently an "unbranded" 2864 firmware en route in the coming months for wholesale customers and I guess the thought is that Bell wants the serial numbers for 3rd party modems so that if you -are- using a 2864 they can push you the "remove Bell branding and unlock features" firmware updates rather than the regular Bell firmware updates.

Time will tell I guess.


Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
reply to SimplePanda
Currently the understanding is that Bell will force you to buy or rent a Sagemcom and give them the serial number, but they do nothing to prevent you from using any other modem you want. They just make you have the Sagemcom. You can just put the box on the shelf.

CNOC's latest filing to the CRTC (as well as several other filings from others) all argue that there is zero justification to place any limits or requirements on the selection or registration of VDSL2 modems. Telus has no such requirement, nor did ADSL/ADSL2+, and there is nothing special about VDSL2 that could justify it.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org


SimplePanda
Go Habs Go
Premium
join:2003-09-22
Toronto, ON
Reviews:
·Rogers Hi-Speed
said by Guspaz:

Currently the understanding is that Bell will force you to buy or rent a Sagemcom and give them the serial number, but they do nothing to prevent you from using any other modem you want. They just make you have the Sagemcom. You can just put the box on the shelf.

CNOC's latest filing to the CRTC (as well as several other filings from others) all argue that there is zero justification to place any limits or requirements on the selection or registration of VDSL2 modems. Telus has no such requirement, nor did ADSL/ADSL2+, and there is nothing special about VDSL2 that could justify it.

Ahh, interesting. Bell never ceases to amaze in their attempts to make sure it's difficult to go to a wholesaler.


FiberToTheX
Premium
join:2013-03-14
Reviews:
·Start Communicat..

1 edit
reply to SimplePanda
said by SimplePanda:

said by FiberToTheX:

50/10 is impressive. However the upload is limited in that aspect. I think symmetrical connections such as Beanfield's 100/100 FTTH is more impressive and cheaper too.

Congrats on the 50/10 upgrade. Mind If I ask where in Toronto you are located ?

High Park.

Condo or Apartment ?. I'm trying to see where exactly the coverage for VDSL is in Toronto and to see if the Residential Internet Map (fast) can be updated to reflect increased VDSL coverage in Toronto.

What kind of prices for renting/owning an apartment/condo is typically the average in that area. I've lived near high-park a while back and I'm curious to see how much of it has changed.

Could you also run a Pingtest. I'm curious about the jitter and packet loss encountered (if any). I've heard some say it works with Pingtest and others say it doesn't. Perhaps also some multi-tasking test such as Streaming and Gaming concurrently to see how well it handles with multiple network bandwidth usage concurrently.


SimplePanda
Go Habs Go
Premium
join:2003-09-22
Toronto, ON
Reviews:
·Rogers Hi-Speed

1 edit
said by FiberToTheX:

said by SimplePanda:

said by FiberToTheX:

50/10 is impressive. However the upload is limited in that aspect. I think symmetrical connections such as Beanfield's 100/100 FTTH is more impressive and cheaper too.

Congrats on the 50/10 upgrade. Mind If I ask where in Toronto you are located ?

High Park.

Condo or Apartment ?. I'm trying to see where exactly the coverage for VDSL is in Toronto and to see if the Residential Internet Map (fast) can be updated to reflect increased VDSL coverage in Toronto.

What kind of prices for renting/owning an apartment/condo is typically the average in that area. I've lived near high-park a while back and I'm curious to see how much of it has changed.

Could you also run a Pingtest. I'm curious about the jitter and packet loss encountered (if any). I've heard some say it works with Pingtest and others say it doesn't. Perhaps also some multi-tasking test such as Streaming and Gaming concurrently to see how well it handles with multiple network bandwidth usage concurrently.

House in The Junction, which is north of the High Park / south of St. Clair. Couldn't say what average rent is but the house next to me was bought a year ago for $800,000 and is now on the market (after renovations) for $1.2M. It's a multi-dwelling house (3) so that's high for a single family home but $800k is closer to average for around here. That said, this isn't a 'wealthy' neighborhood by Toronto standards... is just what living in city limits near the subway costs.

PingTests work with VDSL2 and 50/10. Issue these days is the recent deprecation / security lockdown of Java. I think people are just running PingTest again for the first time on their new lines and it isn't working, which they're assuming is the VDSL2 line when it's the Java issue.

I just ran this though:




Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
reply to SimplePanda
My ping to TekSavvy's speedtest server from Montreal varies from 9ms to 11ms typically. I think my first-hop latency is 7-8ms? Somebody in Toronto would be lower because they don't have to travel from Montreal to Toronto.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org