FYI: Telecom changes the ADSL playing field again...
This just came up in the NZ ADSL list: http://www.telecom.co.nz/content/0,3900,204368-201502,00.html Many of you (who work for ISPs) are probably already aware of this, but here's a quick summary: 1. Telecom moving the rate-limiting to the DSLAM and implementing new backend QoS. 2. Telecom apparently (pointed out by an NZ ADSL user) introducing a further 30ms of latency to ADSL connections (presumably due to new QoS). 3. JetStream Games realm and Remote.Office connections will now be limited to connection plan speed (due to the limiting being done at the DSLAM). Yes, this will impact the usage of the jetstreamgames.co.nz and ftp.paradise.net.nz(?) game/linux/bsd mirrors. Note: this is just a mixture of my interpretation and info garnered from NZ ADSL. I/we could be completely wrong :) Later'ish Craig
Craig Humphrey wrote:
This just came up in the NZ ADSL list: http://www.telecom.co.nz/content/0,3900,204368-201502,00.html
Many of you (who work for ISPs) are probably already aware of this, but here's a quick summary:
1. Telecom moving the rate-limiting to the DSLAM and implementing new backend QoS. 2. Telecom apparently (pointed out by an NZ ADSL user) introducing a further 30ms of latency to ADSL connections (presumably due to new QoS). 3. JetStream Games realm and Remote.Office connections will now be limited to connection plan speed (due to the limiting being done at the DSLAM). Yes, this will impact the usage of the jetstreamgames.co.nz and ftp.paradise.net.nz(?) game/linux/bsd mirrors.
Note: this is just a mixture of my interpretation and info garnered from NZ ADSL. I/we could be completely wrong :)
Well, points 1 and 3 were known already, with the exception of the Remote.Office connections. What's so badly b0rk3d about DSLAM rate-limiting and the new QoS implementation that causes latency to jump like that? Anyone know? -- Juha
Juha Saarinen wrote:
What's so badly b0rk3d about DSLAM rate-limiting and the new QoS implementation that causes latency to jump like that? Anyone know?
It's a design feature so you don't want to do VOIP? Or migrate from a "proper" (read, expensive) E1 circuit. Compare this with their Ethernet products as Craig Humphrey asked about a few weeks ago.
On Thu, 21 Oct 2004, Craig Humphrey wrote:
1. Telecom moving the rate-limiting to the DSLAM and implementing new backend QoS.
This makes a lot of sense, though, technically. Why connect the user at 8Mbits/sec down and churn out a boatload of RF bollocks from the copper, when they're only buying a 256Kbits/sec "broadband" connection? May as well make it 256Kbits/sec right at the start. This will probably enhance overall network stability somewhat. It does lead automatically to point 3, however...
3. JetStream Games realm and Remote.Office connections will now be limited to connection plan speed (due to the limiting being done at the DSLAM). Yes, this will impact the usage of the jetstreamgames.co.nz and ftp.paradise.net.nz(?) game/linux/bsd mirrors.
Doesn't this kinda defeat the whole point of having a seperate realm for JSG, then? That full-speed business was the only thing that made it interesting. If your connectivity to it is the same as your connectivity to any other normally-peered (Hi TelstraClear!) New Zealand game server, why bother maintaining it as a seperate realm you need to re-login to access? It was worth the bother to re-login when it got you decent speeds, but without them it's just a pain in the ass. You may as well just lift the access lists and put allow access to these machines from the general internet. Or is that what's happening anyway? I remember hearing something recently about JSG going away. JSR -- John S Russell | Big Geek | Doing geek stuff.
----- Original Message -----
From: "J S Russell"
This makes a lot of sense, though, technically. Why connect the user at 8Mbits/sec down and churn out a boatload of RF bollocks from the copper, when they're only buying a 256Kbits/sec "broadband" connection? May as well make it 256Kbits/sec right at the start. This will probably enhance overall network stability somewhat. It does lead automatically to point 3, however...
Telstra Clear already do this with their tempest service, if you purchase a 256k connection, check your router status and you'll see you are connected a 288k. They at least give 32k leaway. I've also noticed most ISP's globally do this, so it's nothing abnormal, just the jetstream realm will be missed. Barry
Telstra Clear already do this with their tempest service, if you purchase a 256k connection, check your router status and you'll see you are connected a 288k. They at least give 32k leaway.
Just checked a clients tempest connection and the Nokia router reports: Downstream Upstream Current Rate : 8000 Kbps 800 Kbps Maximum Rate : 9523 Kbps 941 Kbps And the latency is somewhat better than what we used to get from the jetstream link: traceroute to xtra.co.nz (202.27.184.102), 30 hops max, 38 byte packets 1 a.a.a.a (a.a.a.a) 0.926 ms 0.864 ms 0.922 ms 2 b.b.b.b (b.b.b.b) 8.465 ms 8.123 ms 12.425 ms 3 cs2-e4-7-acld.auckland.clix.net.nz (203.97.9.98) 8.771 ms 9.305 ms 9.286 ms 4 g1-0-927.u11.tspn.telstraclear.net (218.101.61.6) 11.422 ms 10.660 ms 10.282 ms 5 xtra.ape.net.nz (192.203.154.60) 14.338 ms 10.610 ms 10.278 ms 6 v512.XTRAK2-B1.xtra.co.nz (202.27.176.226) 11.048 ms 10.160 ms 10.023 ms -- Stephen
Just checked a clients tempest connection and the Nokia router reports: Downstream Upstream Current Rate : 8000 Kbps 800 Kbps Maximum Rate : 9523 Kbps 941 Kbps
And the latency is somewhat better than what we used to get from the jetstream link: traceroute to xtra.co.nz (202.27.184.102), 30 hops max, 38 byte packets 1 a.a.a.a (a.a.a.a) 0.926 ms 0.864 ms 0.922 ms 2 b.b.b.b (b.b.b.b) 8.465 ms 8.123 ms 12.425 ms 3 cs2-e4-7-acld.auckland.clix.net.nz (203.97.9.98) 8.771 ms 9.305 ms 9.286 ms 4 g1-0-927.u11.tspn.telstraclear.net (218.101.61.6) 11.422 ms 10.660 ms 10.282 ms 5 xtra.ape.net.nz (192.203.154.60) 14.338 ms 10.610 ms 10.278 ms 6 v512.XTRAK2-B1.xtra.co.nz (202.27.176.226) 11.048 ms 10.160 ms 10.023 ms
Looks like Clear does not turn on Interleaving on. No troublr with at all really as (if I can remember right) Clear won't install a DSL connection if you are too far away from the exchange (more than a km, so the interleaving error correction is not needed) Thanks Craig
On 21/10/2004, at 10:23 AM, Barry Murphy wrote:
Telstra Clear already do this with their tempest service, if you purchase a 256k connection, check your router status and you'll see you are connected a 288k. They at least give 32k leaway.
I suppose that's so the router's peer is the device that controls the queuing? Being the slowest device, it "owns" the queue, as the Linux Advanced Routing HOWTO states it. -- Cameron Kerr cameron(a)humbledown.org; http://humbledown.org
J S Russell wrote:
Doesn't this kinda defeat the whole point of having a seperate realm for JSG, then? That full-speed business was the only thing that made it interesting. If your connectivity to it is the same as your connectivity to any other normally-peered (Hi TelstraClear!) New Zealand game server, why bother maintaining it as a seperate realm you need to re-login to access? It was worth the bother to re-login when it got you decent speeds, but without them it's just a pain in the ass. You may as well just lift the access lists and put allow access to these machines from the general internet. Or is that what's happening anyway? I remember hearing something recently about JSG going away.
Well it won't count to your usage cap. Your 10Gb Usage cap. Including NATIONAL Traffic National traffic thats delivered over the public peering exchanges. Thats ~free anyway. </rant>
participants (9)
-
Andy Linton -
Barry Murphy -
Cameron Kerr -
Craig Humphrey -
Craig Whitmore -
J S Russell -
Juha Saarinen -
Richard Patterson -
Stephen Ridley