Actually that is not Neils surname, ;) but I do hope your comments help to highlight to Neil and Gary just how frustrated and annoyed these problems make some of us.

Just for the record. Neil has got Telecom issues sorted for me quickly in the past via back channels and while covering his own arse as much as he could, made is more than clear that he gets more than pissed off as well at poor performance by front line staff and poorly designed systems and often looks to us as users for empowerment to shake things up internally when needed.

This isn't shaping, The TCP stack has been tweaked to higher than default 64k and as such with the latency his single TCP stream performance is limited to 64k. I'm not actually sure there is a issue

The TCP stack is an agreement on how to process the packets on the endpoints. The only thing the _IP_ network in the middle should care about is the IP Address (ports aren't at the IP level). It's not a TCP network, it's an IP network.

Therefore, if both endpoints support the widely supported large window extension, then they should be able to achieve higher throughputs.

If they can't, that means that someone in the middle is doing something special to the traffic - which TCL states they don't do.

Add on to that the fact that another NZ ISP has a completely different experience indicates that the difference is likely to be on TCL's network, or on their immediate upstream provider, both of which are TCL's responsibility to manage.

By modifying or otherwise delaying the TCP packets as they pass through the network, TCL is shaping the traffic, regardless of what they call it.

I'd be interested to see if UDP packets are rate limited the same way.

Talkiet: With all due respect, I was basically complimenting TCL on the attention they are giving to this issue. I think you have over-reacted to my comment.

RegardsNeil G

You did climb into a boiling pot with some fairly annoyed users who are just getting tired with the crap being dished up.

I think Telecom and Telstra need a bit of a wake up call that none of these little issues in isolation are an issue at all.

The problem is, as you'll know if you've been following the thread now in my signature, that we are being impacted by a constant stream of this crap.

Neil you're based in Christchurch, so you know what constant aftershocks are like.

Constant poor service, fobbing off and problem denial becomes as wearing at being woken at 3am by yet another aftershock.

I can't speak for the OP, but I'm living with both and I'm tired of it. I can't do anything about the earth, but I can sure help push the case to get telco support back in New Zealand for our employment and get an imporvement in communications!

Talkiet: To keep in perspective though, you're complaining about a residential broadband service with no performance SLAs only being able to achieve 3-4mbps on a single thread, when with multiple threads you can still max out the connection?

I agree that it's a little odd, but it's hardly the worst example of a broadband 'fault' I have ever seen.

To clarify, yes, I agree there's something a little odd here, but performance is by no means actually bad - and there is (presumably) no performance SLAs associated with this product... TCL are going WAY above and beyond in the level of troubleshooting they are giving this IMO.

Cheers - N

Telstra Clear repeatedly states that they don't shape the connection in any way shape or form. ?Given that they charge per byte, they have no reason to.

So, this means that their service doesn't match their published statements, and as such they must either fix the service or refund the fee.

This sort of "bug" is exactly what got Telecom into hot water with the regulator.?

This isn't shaping, The TCP stack has been tweaked to higher than default 64k and as such with the latency his single TCP stream performance is limited to 64k. I'm not actually sure there is a issue

Have you read all the posts here? What about the one where I posted about how I took my workstation out to my friend's place, with all the same settings, and the connection blazed along at 10mbit/sec? The only difference between that result and the one I usually get is that result was achieved on an XNet DSL connection, whereas I'm limited to poor old TelstraClear Cable. Supposed to get 15mbit, get 3mbit. And you call no problem? I'm glad TelstraClear have taken the matter more seriously than you appear to have.

This is an issue that Telstra Australia will and do take ownership of.

I have had issues with transit outside of Telstra's network in the past and had direct assistance from Melbourne where my problem was passed "down" to Level 3 staff to sort out.

If it does turn out to be a transit problem then we only need to figure roughly where it's happening and there's any amount of help in that space, though some providers do make Telstra New Zealand look quick.

jnawk: That post has been informative for me - should TelstraClear fail to resolve the matter, I'll be looking elsewhere, and now I've narrowed the list by one provider. Thanks for that, Mr. Telecom.

Apparently I can't say sh*t here. Sorry.

With all due respect, I was basically complimenting TCL on the attention they are giving to this issue. I think you have over-reacted to my comment.

RegardsNeil G

Fair enough. Would Telecom have given the same issue the same attention? If so, I retract my foaming-at-the-mouth rant and offer a sincere apology.

The 100% honest answer is that I don't know... I'm relatively sure that ANY level 1 helpdesk from any ISP would be flummoxed by this clearly complicated or subtle issue. I have worked on issues before where unexpected performance (that was still well in excess of what would be considered reasonable BB performance) was observed - just because it was unexpected... Often unexpected performance is an early indicator of a problem, even if at an absolute level it's still fine for 99.99% of people.

Talkiet: To keep in perspective though, you're complaining about a residential broadband service with no performance SLAs only being able to achieve 3-4mbps on a single thread, when with multiple threads you can still max out the connection?

I agree that it's a little odd, but it's hardly the worst example of a broadband 'fault' I have ever seen.

To clarify, yes, I agree there's something a little odd here, but performance is by no means actually bad - and there is (presumably) no performance SLAs associated with this product... TCL are going WAY above and beyond in the level of troubleshooting they are giving this IMO.

Cheers - N

Telstra Clear repeatedly states that they don't shape the connection in any way shape or form. ?Given that they charge per byte, they have no reason to.

So, this means that their service doesn't match their published statements, and as such they must either fix the service or refund the fee.

This sort of "bug" is exactly what got Telecom into hot water with the regulator.?

This isn't shaping, The TCP stack has been tweaked to higher than default 64k and as such with the latency his single TCP stream performance is limited to 64k. I'm not actually sure there is a issue

Have you read all the posts here? What about the one where I posted about how I took my workstation out to my friend's place, with all the same settings, and the connection blazed along at 10mbit/sec? The only difference between that result and the one I usually get is that result was achieved on an XNet DSL connection, whereas I'm limited to poor old TelstraClear Cable. Supposed to get 15mbit, get 3mbit. And you call no problem? I'm glad TelstraClear have taken the matter more seriously than you appear to have.

Congrats you managed to find one host you control that can use window scaling, Window scaling is a bit of a black art, Some support it and other dont and sometimes things in the middle of the path mess it up, The fact that you speed didn't drop below the RWIN 64k with 150ms latency max tells me your connection is working just fine. You say multiple streams can max your connection. Your Xnet traces show that the path is different compared to Telstra within the hosting providers own network

So as you can see the hop from the IX which is 206.223.143.xxx Telstra jumps to a Hurricane Electric node (216.218.213.250) whilst Xnet jump to a Packet Exchange node (67.199.135.234) From there its within http://WebNX.com network and even then it's taking a different path.

Your jumping to dangerous conclusions that it's Telstra at fault here when the path within the hosting providers network is different! Window Scaling is nice but it's not guaranteed that it will work. Have you even spoken to your hosting provider?

Most problems are the result of previous solutions...

All comment's I make are my own personal opinion and do not in any way, shape or form reflect the views of current or former employers unless specifically stated

I just wanted to clarify, I think TCL's doing a good job tracking down the problem.

I do, however, consider it an important fault that needs to be resolved.

I have noticed it before, and always thought that TCL shaped their traffic. Now that I realize that they don't, I wish I'd raised a ruckus about this back when I first saw the problem, way back in 2009.

Beccara: Congrats you managed to find one host you control that can use window scaling, Window scaling is a bit of a black art, Some support it and other dont and sometimes things in the middle of the path mess it up, The fact that you speed didn't drop below the RWIN 64k with 150ms latency max tells me your connection is working just fine. You say multiple streams can max your connection. Your Xnet traces show that the path is different compared to Telstra within the hosting providers own network

So as you can see the hop from the IX which is 206.223.143.xxx Telstra jumps to a Hurricane Electric node (216.218.213.250) whilst Xnet jump to a Packet Exchange node (67.199.135.234) From there its within?http://WebNX.com?network and even then it's taking a different path.

Your jumping to?dangerous?conclusions that it's Telstra at fault here when the path within the hosting providers network is different! Window Scaling is nice but it's not guaranteed that it will work. Have you even spoken to your hosting provider?

So, it sounds like it might be a problem with TC's upstream provider, who you identify as HE. I recall either in this thread or the Cable-modem-off-but-still-traffic thread that DonGould pointed out it is the ISP's responsibility to manage the upstream provider.

At this stage, I might introduce a box in Germany, to which performance is also lame on TC but fine on XNet. But let's see what TC have to say for theirselves first - they did ask for Friday as deadline after all.

jpollock: I just wanted to clarify, I think TCL's doing a good job tracking down the problem.

I do, however, consider it an important fault that needs to be resolved.

I have noticed it before, and always thought that TCL shaped their traffic. Now that I realize that they don't, I wish I'd raised a ruckus about this back when I first saw the problem, way back in 2009.

+1, +1 and +1.

I "noticed" it a long time ago, but given none of the remote servers were ones I had any control over (and hence no idea of loading), I always assumed the remote end was the problem.

Beccara: Congrats you managed to find one host you control that can use window scaling, Window scaling is a bit of a black art, Some support it and other dont and sometimes things in the middle of the path mess it up, The fact that you speed didn't drop below the RWIN 64k with 150ms latency max tells me your connection is working just fine. You say multiple streams can max your connection. Your Xnet traces show that the path is different compared to Telstra within the hosting providers own network

So as you can see the hop from the IX which is 206.223.143.xxx Telstra jumps to a Hurricane Electric node (216.218.213.250) whilst Xnet jump to a Packet Exchange node (67.199.135.234) From there its within?http://WebNX.com?network and even then it's taking a different path.

Your jumping to?dangerous?conclusions that it's Telstra at fault here when the path within the hosting providers network is different! Window Scaling is nice but it's not guaranteed that it will work. Have you even spoken to your hosting provider?

So, it sounds like it might be a problem with TC's upstream provider, who you identify as HE. I recall either in this thread or the Cable-modem-off-but-still-traffic thread that DonGould pointed out it is the ISP's responsibility to manage the upstream provider.

At this stage, I might introduce a box in Germany, to which performance is also lame on TC but fine on XNet. But let's see what TC have to say for theirselves first - they did ask for Friday as deadline after all.

Or something to do with your host, 173.231.0.66 is on TC and 173.231.0.18 is XNet which within your hosting provider

Most problems are the result of previous solutions...

All comment's I make are my own personal opinion and do not in any way, shape or form reflect the views of current or former employers unless specifically stated

jpollock: I just wanted to clarify, I think TCL's doing a good job tracking down the problem.

I do, however, consider it an important fault that needs to be resolved.

I have noticed it before, and always thought that TCL shaped their traffic. Now that I realize that they don't, I wish I'd raised a ruckus about this back when I first saw the problem, way back in 2009.

+1, +1 and +1.

I "noticed" it a long time ago, but given none of the remote servers were ones I had any control over (and hence no idea of loading), I always assumed the remote end was the problem.

Could you ask TCL to supply you a link of a file hosted somewhere near the edge of their network? That way you can see what sort of performance you can get across the network that they themselves have control over.

If it turns out that a configuration choice of an external provider is limiting your per thread throughput, there's realistically very little that could be done about it (edit: done by TCL anyway)... That's the way the Internet works.

Could you ask TCL to supply you a link of a file hosted somewhere near the edge of their network? That way you can see what sort of performance you can get across the network that they themselves have control over.

If it turns out that a configuration choice of an external provider is limiting your per thread throughput, there's realistically very little that could be done about it... That's the way the Internet works.

Cheers - N

The problem is that if the latency dropped to 35ms, the throughput would go up to 14Mbps, so it's really only obvious when you leave the network.