Can't send attachments - V poor upload problem - Page 4

Ashover · 31-08-2004, 09:21

You've got more stamina than me, I'm kicking NTL into touch, phone, tv and broadband.

The last straw for me was a telephone billing issue which, coming on top of waiting over a week for a call back from tech services (which hasn't materialised) and still having these crap upstream speeds, has finally finished me off.
NTL can obviously afford to lose the ÃƒÆ’Ã†â€™ÃƒÂ¢Ã¢â€šÂ¬Ã…Â¡ÃƒÆ’Ã¢â‚¬Å¡Ãƒâ€šÃ‚Â£100 a month that I pay them so things must be good.

DeadKenny · 31-08-2004, 10:51

Quote:

On the morning of Thursday August 26th between midnight and 5am:

Network resegmentation and load balancing work may result in a loss of service for a few hours in Woking, Mansfield, Warwick and the surrounding areas.

Bingo! That's most likely why my connection's gone and screwed!

Take a look at this thread...

http://www.cableforum.co.uk/board/sh...ad.php?t=16757

Guess what? On the morning of the 26th I had a modem reboot, new IP address and I noticed the UBR IP address had totally changed (it's now a 10.x.x.x address), and ever since I'm getting *major* packet loss! (all on the upstream, thus causing stalled/failed web requests and bad upstream traffic when uploading, this includes making my web server run at a crawl, though 256kbps was never speedy anyway)

I've been told this may be down to my 58 upstream power level (at that level it would be readjusting power and that causes the packet loss), but I've been living with a power level of between 56 to 58 for a year now with no problem. The problem only started when NTL "fixed" things

.

So now it could be down to me to chase up NTL, get engineers out, wait in for them, etc, to sort it

.

P.S. Can you guys do a quick test?

Do a traceroute to www.ntlworld.com and find the UBR IP address on the list. It will be the first or second hop (depending whether you've got a router or not), and probably a 10.x.x.x address. Then do a ping to that address to check on packet loss ('ping -t' for a continuous ping on Windows and CTRL+C to stop it, and it will tell you how much packet loss if any).

I'm interested to see if anyone getting upload problems is getting packet loss too (as it would probably explain it, and is what I'm getting).

Also are you getting problems with web pages where you sometimes have to refresh to get the page to load?

In addition to that if you can check your upstream power level too that would be great (browse to http://192.168.100.1 on most modems).

Web-Junkie · 31-08-2004, 15:04

@Ashover: I don't give in that easy, if I did then NTL win! They can then sit back and afford to lose customers without doing a damn thing about the problems. I intend to make sure I'm not going to get messed about with lame excuses and ensure someone knows it!!

@DeadKenny:

Traceroute through deafult proxy:

Code:

Tracing route to www.ntlworld.com [62.253.162.30]
over a maximum of 30 hops:
1 253 ms 246 ms 240 ms 10.175.71.254 <-- I assume this is the UBR?
2 129 ms 114 ms 115 ms nott-t2cam1-b-v108.inet.ntl.com [80.4.46.145]
3 230 ms 165 ms 153 ms nott-t2core-b-ge-wan74.inet.ntl.com [80.1.79.201]
4 247 ms 210 ms 163 ms nth-bb-b-so-200-0.inet.ntl.com [62.253.185.37]
5 165 ms 194 ms 191 ms nth-bb-a-ae0-0.inet.ntl.com [62.253.185.117]
6 261 ms 196 ms 142 ms gfd-bb-b-so-400-0.inet.ntl.com [62.253.185.98]
7 255 ms 244 ms 208 ms win-bb-a-so-500-0.inet.ntl.com [213.105.172.129]
8 196 ms 224 ms 258 ms win-dc-a-v902.inet.ntl.com [62.253.187.222]
9 260 ms 101 ms	13 ms www.ntlworld.com [62.253.162.30]
Trace complete.

Using 'ping -t 10.175.71.254' seems OK though:

Code:

Reply from 10.175.71.254: bytes=32 time=218ms TTL=255
Reply from 10.175.71.254: bytes=32 time=110ms TTL=255
Reply from 10.175.71.254: bytes=32 time=182ms TTL=255
Reply from 10.175.71.254: bytes=32 time=248ms TTL=255
Reply from 10.175.71.254: bytes=32 time=173ms TTL=255
Reply from 10.175.71.254: bytes=32 time=184ms TTL=255
Reply from 10.175.71.254: bytes=32 time=238ms TTL=255
Reply from 10.175.71.254: bytes=32 time=193ms TTL=255
Reply from 10.175.71.254: bytes=32 time=228ms TTL=255
Reply from 10.175.71.254: bytes=32 time=217ms TTL=255
Reply from 10.175.71.254: bytes=32 time=110ms TTL=255
Reply from 10.175.71.254: bytes=32 time=210ms TTL=255
Reply from 10.175.71.254: bytes=32 time=233ms TTL=255
Reply from 10.175.71.254: bytes=32 time=203ms TTL=255
Reply from 10.175.71.254: bytes=32 time=225ms TTL=255
Reply from 10.175.71.254: bytes=32 time=224ms TTL=255
Reply from 10.175.71.254: bytes=32 time=247ms TTL=255
Reply from 10.175.71.254: bytes=32 time=44ms TTL=255
Reply from 10.175.71.254: bytes=32 time=128ms TTL=255
Reply from 10.175.71.254: bytes=32 time=209ms TTL=255
Reply from 10.175.71.254: bytes=32 time=166ms TTL=255
Reply from 10.175.71.254: bytes=32 time=191ms TTL=255
Reply from 10.175.71.254: bytes=32 time=226ms TTL=255
Ping statistics for 10.175.71.254:
	Packets: Sent = 23, Received = 23, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 44ms, Maximum = 248ms, Average = 191ms

Upstream from Surfboard 4100:

Code:

Channel ID: 4
Frequency: 36821684 Hz Ranged
Ranging Service ID: 82
Symbol Rate: 2.560 Msym/s
Power Level: 57 dBmV

and a 'netstat -s -p tcp'

Code:

TCP Statistics for IPv4
Active Opens = 2309
Passive Opens = 1085
Failed Connection Attempts = 0
Reset Connections = 194
Current Connections = 10
Segments Received = 369460
Segments Sent = 255882
Segments Retransmitted = 235

Not sure if this info helps but I do know I have to use the refresh button on web pages more than I used to. Trying to preview this message has also resulted in several time outs causing 'The page cannot be displayed' error! I'm having to copy the entire message before previewing in case the page craps out!!

If this were Southpark it would be "NTL!! OMG they've killed broadband!!"

DeadKenny · 31-08-2004, 17:03

Hmm, sounds like it's similar to my problem, though you're not getting packet loss. In your case it looks like a slow connection to the UBR with high ping times (and in my case the connection just fails). Your upstream is close to the limit like mine, though netstat isn't reporting failed connection attempts, but some retransmits.

Web-Junkie · 31-08-2004, 18:01

I pinged all 9 hops on the trace route and no packet loss.

You obviously have an additional problem on top of the existing problem to compound it.

I still can't upload to Yahoo briefcase, send attachments via my NTL e-mail and ftp uploads still time out! So it's not purely a packet loss issue, you're just one of the 'lucky' ones to be gifted with 'extra' problems at no additional cost courtesy of NTL!

DeadKenny · 31-08-2004, 18:30

I'm thinking maybe if the signal is 'over' the limit then you get the packet loss. Maybe when it's near you don't but perhaps could see some performance problems? i.e. not enough to drop packets but certainly to cause serious delays which I guess could make things time-out.

Or it's two separate issues.

I don't know, I find these upstream hassles so frustrating. I went through a year of hell with them before but that was with the connection dropping and the modem rebooting endlessly.

I've said it before that it would be much better if NTL did the same as BT and refuse to install if the line quality is too poor. I think the problem with NTL is they just hook you up and assume because it's cable it will work first time. When I got mine installed no one bothered to check the signal at all. It was, drill the hole, plug the cable in, clear off to next job. The result in loads of call outs wasting my time (and money) and theirs.

I even get the impression that the network just can't handle broadband and digital TV. It wasn't designed for that when it was put in and dodgy signal levels weren't an issue with analogue cable TV I guess (and they usually were dodgy in my experience).

Web-Junkie · 01-09-2004, 13:26

Well, the engineer should come tomorrow so I can show him first hand the problem and then see what he says. Then again, I could be on the phone asking why he didn't turn up.

Upstream signal level is still 57 dBmV, downstream is 2 dBmV today.

DeadKenny · 01-09-2004, 13:30

Quote:

Originally Posted by Web-Junkie

Then again, I could be on the phone asking why he didn't turn up.

I've been there before

Worse was one where they turned on the wrong day and had the balls to accuse me of not being in and promptly cancelled the call out!! (meaning I had to re-arrange and them saying it would be another week before they could come out

).

steve_smith · 01-09-2004, 15:21

Quote:

Originally Posted by Web-Junkie

I pinged all 9 hops on the trace route and no packet loss.

<snip>

Quote:

Originally Posted by Web-Junkie

I still can't upload to Yahoo briefcase, send attachments via my NTL e-mail and ftp uploads still time out! So it's not purely a packet loss issue, you're just one of the 'lucky' ones to be gifted with 'extra' problems at no additional cost courtesy of NTL!

If there is no apparent packet loss (or very little packet loss) when doing ping tests, you might find you have a similar problem to me in that small packets (eg. those of default ping size) get through with much less packet loss than larger packets.

Try opening up a command prompt window (if you're using Windows) and do this:

ping -L 2000 -N 20 www.bbc.co.uk

(ie. ping www.bbc.co.uk with 2000 bytes 20 times)

If I do that test, I get 50% packet loss.

If I ping the same site with the default size of 32 bytes, I get little or no loss.

Steve.

Web-Junkie · 01-09-2004, 15:56

OK Steve:

This is with no Adblocker or Firewall running, but going through the default Notts proxy server (which to me is very slow and causes slow browsing and time outs).

Code:

Pinging www.bbc.net.uk [212.58.224.126] with 2000 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Reply from 212.58.224.126: bytes=2000 time=281ms TTL=247
Request timed out.
Reply from 212.58.224.126: bytes=2000 time=214ms TTL=247
Reply from 212.58.224.126: bytes=2000 time=194ms TTL=247
Reply from 212.58.224.126: bytes=2000 time=130ms TTL=247
Reply from 212.58.224.126: bytes=2000 time=153ms TTL=247
Reply from 212.58.224.126: bytes=2000 time=166ms TTL=247
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 212.58.224.126: bytes=2000 time=137ms TTL=247
Reply from 212.58.224.126: bytes=2000 time=48ms TTL=247
Reply from 212.58.224.126: bytes=2000 time=107ms TTL=247
Request timed out.
Reply from 212.58.224.126: bytes=2000 time=175ms TTL=247
Ping statistics for 212.58.224.126:
	Packets: Sent = 20, Received = 10, Lost = 10 (50% loss),
Approximate round trip times in milli-seconds:
	Minimum = 48ms, Maximum = 281ms, Average = 160ms

May seem a silly question but I thought 1500 was the biggest packet size that ethernet uses? That's what WinXP's MTU is set to, so I did the same test with a packet size of 1500:

Code:

Pinging www.bbc.net.uk [212.58.224.82] with 1500 bytes of data:
Reply from 212.58.224.82: bytes=1500 time=176ms TTL=247
Request timed out.
Reply from 212.58.224.82: bytes=1500 time=107ms TTL=247
Reply from 212.58.224.82: bytes=1500 time=163ms TTL=247
Reply from 212.58.224.82: bytes=1500 time=154ms TTL=247
Request timed out.
Request timed out.
Reply from 212.58.224.82: bytes=1500 time=59ms TTL=247
Reply from 212.58.224.82: bytes=1500 time=179ms TTL=247
Reply from 212.58.224.82: bytes=1500 time=25ms TTL=247
Reply from 212.58.224.82: bytes=1500 time=24ms TTL=247
Reply from 212.58.224.82: bytes=1500 time=106ms TTL=247
Reply from 212.58.224.82: bytes=1500 time=111ms TTL=247
Reply from 212.58.224.82: bytes=1500 time=56ms TTL=247
Reply from 212.58.224.82: bytes=1500 time=39ms TTL=247
Reply from 212.58.224.82: bytes=1500 time=29ms TTL=247
Reply from 212.58.224.82: bytes=1500 time=99ms TTL=247
Reply from 212.58.224.82: bytes=1500 time=130ms TTL=247
Request timed out.
Request timed out.
Ping statistics for 212.58.224.82:
	Packets: Sent = 20, Received = 15, Lost = 5 (25% loss),
Approximate round trip times in milli-seconds:
	Minimum = 24ms, Maximum = 179ms, Average = 97ms

Looks like pinging with lower values until one works 100% and use that as the MTU value?

steve_smith · 01-09-2004, 16:19

Quote:

Originally Posted by Web-Junkie

This is with no Adblocker or Firewall running, but going through the default Notts proxy server (which to me is very slow and causes slow browsing and time outs).

I think (and will be corrected if I'm wrong!) that only web traffic goes through the proxy server. So your ping tests are making a direct connection between your computer and the server at the other end (without any proxying going on).

Quote:

Originally Posted by Web-Junkie

Looks like pinging with lower values until one works 100% and use that as the MTU value?

I thought that and did try lowering my MTU value to 300 bytes. Didn't seem to help very much :-(

My brother has an NTL broadband connection in his flat (he lives in London, same modem and connection speed as mine). I took my laptop and doing that same test with 2000 bytes to www.bbc.co.uk resulted in zero packet loss. My laptop is running XP Professional. So the fact is that in your area and my area, there is something wrong with the network that is causing this behaviour. It seems to me that the more data you send at once, the more chance there is that it won't get delivered.

Don't know whether any network experts out there can come up with a diagnosis or any ideas based on this information, or just tell me that I'm barking up the wrong tree altogether.

Steve.

Web-Junkie · 01-09-2004, 17:25

We shouldn't have to be altering MTU values anyway! Would Mr and Mrs Smith who bought broadband for their daughter be expected to know how to set MTU values, reconfigure network settings, how to diagnose packet loss or slow ping times to their UBR just to convince NTL their own network is at fault?

It does seem certain areas are affected and others not. I have a friend in Mansfield, the next town to me, who runs WinXP and he can send 2 attachments of 700kb each to me using NTL's mail but I can't Forward the same mail back to him with the same attachments, the mail server just chokes! Maybe they rotate the problems around different areas to hide the problem?

Ashover · 01-09-2004, 17:33

OK, I'll wait and see what the engineer (if he appears) says tomorrow.

I have a friend who lives near Sutton junction and she has absoloutely no problems sending me email attachments, so the problem seems to be very localised.

Web-Junkie · 01-09-2004, 20:59

Will keep you posted, but you now not to hold your breath where NTL are concerned

DeadKenny · 02-09-2004, 00:15

I just tried the same test...

Code:

Pinging www.bbc.net.uk [212.58.224.125] with 2000 bytes of data:

Request timed out.
Reply from 212.58.224.125: bytes=2000 time=30ms TTL=247
Reply from 212.58.224.125: bytes=2000 time=28ms TTL=247
Reply from 212.58.224.125: bytes=2000 time=26ms TTL=247
Reply from 212.58.224.125: bytes=2000 time=26ms TTL=247
Reply from 212.58.224.125: bytes=2000 time=29ms TTL=247
Reply from 212.58.224.125: bytes=2000 time=28ms TTL=247
Request timed out.
Reply from 212.58.224.125: bytes=2000 time=31ms TTL=247
Reply from 212.58.224.125: bytes=2000 time=24ms TTL=247
Reply from 212.58.224.125: bytes=2000 time=29ms TTL=247
Request timed out.
Reply from 212.58.224.125: bytes=2000 time=25ms TTL=247
Reply from 212.58.224.125: bytes=2000 time=28ms TTL=247
Reply from 212.58.224.125: bytes=2000 time=25ms TTL=247
Request timed out.
Reply from 212.58.224.125: bytes=2000 time=29ms TTL=247
Reply from 212.58.224.125: bytes=2000 time=25ms TTL=247
Reply from 212.58.224.125: bytes=2000 time=26ms TTL=247
Reply from 212.58.224.125: bytes=2000 time=26ms TTL=247

Ping statistics for 212.58.224.125:
    Packets: Sent = 20, Received = 16, Lost = 4 (20% loss),
Approximate round trip times in milli-seconds:
    Minimum = 24ms, Maximum = 31ms, Average = 27ms

Better times, but still loads of packet loss

and to the UBR...

Code:

Pinging 10.136.63.254 with 2000 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Reply from 10.136.63.254: bytes=2000 time=23ms TTL=254
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 10.136.63.254: bytes=2000 time=27ms TTL=254
Request timed out.
Reply from 10.136.63.254: bytes=2000 time=26ms TTL=254
Request timed out.
Reply from 10.136.63.254: bytes=2000 time=26ms TTL=254
Request timed out.
Reply from 10.136.63.254: bytes=2000 time=26ms TTL=254
Reply from 10.136.63.254: bytes=2000 time=30ms TTL=254
Request timed out.

Ping statistics for 10.136.63.254:
    Packets: Sent = 20, Received = 6, Lost = 14 (70% loss),
Approximate round trip times in milli-seconds:
    Minimum = 23ms, Maximum = 30ms, Average = 26ms

or at default packet size...

Code:

Pinging 10.136.63.254 with 32 bytes of data:

Reply from 10.136.63.254: bytes=32 time=8ms TTL=254
Request timed out.
Reply from 10.136.63.254: bytes=32 time=7ms TTL=254
Reply from 10.136.63.254: bytes=32 time=7ms TTL=254
Reply from 10.136.63.254: bytes=32 time=6ms TTL=254
Request timed out.
Request timed out.
Reply from 10.136.63.254: bytes=32 time=7ms TTL=254
Request timed out.
Reply from 10.136.63.254: bytes=32 time=8ms TTL=254
Reply from 10.136.63.254: bytes=32 time=7ms TTL=254
Request timed out.
Reply from 10.136.63.254: bytes=32 time=8ms TTL=254
Request timed out.
Request timed out.
Reply from 10.136.63.254: bytes=32 time=20ms TTL=254
Reply from 10.136.63.254: bytes=32 time=8ms TTL=254
Reply from 10.136.63.254: bytes=32 time=7ms TTL=254
Reply from 10.136.63.254: bytes=32 time=15ms TTL=254
Reply from 10.136.63.254: bytes=32 time=8ms TTL=254

Ping statistics for 10.136.63.254:
    Packets: Sent = 20, Received = 13, Lost = 7 (35% loss),
Approximate round trip times in milli-seconds:
    Minimum = 6ms, Maximum = 20ms, Average = 8ms