bad internet for nearly 6 weeks now :(

Hi All,
I have had a terrible time with my internet connection lately
Started losing internet about 6 - 8 weeks ago, poor speeds, connection going up/down so phoned Zen, did the usual test socket stuff but my connection was still pretty poor. Zen C/S talked me into buying a new router which I did and I still have a [censored] connection (can't even watch an online presentation this morning).
I have to say some of Zen's CS have been spot on and helpful others (like the guy I spoke to this morning) not so helpful
when I ask what is the problem I've got a new router, bought a booster and the new router is in the test socket yet I can't watch a 5 min presentation online I get "erm I dont know, try using a cable not wifi"
Have lived here for 3 years using wifi no problem, nothing whatsoever has changed in this house (except the heating going on 2 weeks ago) and yet my connection is becoming unusable
Why can't I get any help from Zen???

If Zen can't see a problem and you're using wifi, then it's likely to be local conditions causing the issue. That's something Zen can't help with.

If your router and devices support the 5GHz wireless band try that, if not, try changing the 2.4GHz wireless channel to a less crowded one. There's a great app for Android called wifi analyser which will help you determine the the best/least crowded channel to use, but bear in mind that you should only use 1, 6 or 11 due to the way channels overlap. I suggest troubleshooting the connection without the wifi booster at first.

Did you buy and install any new electrical devices 6-8 weeks ago? What about your neighbours? If you're on good terms maybe you can ask!

Edited by deleted (Wed 22-Oct-14 10:55:18)

In reply to a post by kadison44:

If Zen can't see a problem and you're using wifi, then it's likely to be local conditions causing the issue. That's something Zen can't help with.

If your router and devices support the 5GHz wireless band try that, if not, try changing the 2.4GHz wireless channel to a less crowded one. There's a great app for Android called wifi analyser which will help you determine the the best/least crowded channel to use, but bear in mind that you should only use 1, 6 or 11 due to the way channels overlap. I suggest troubleshooting the connection without the wifi booster at first.

Did you buy and install any new electrical devices 6-8 weeks ago? What about your neighbours? If you're on good terms maybe you can ask!

Hi,
Thanks for the reply
I have since spoken to a Team Leader after making a complaint as Chris didn't call me back this morning when he said he would. They are looking into it for me thankfully
Yes we have a new Netgear router which has 5GHz and we are on that band but I dont know the password to change the channel on the router so I'll wait for my husband to come home at lunch time and try that

I am on good terms with my neighbours so I will ask them as we haven't changed anything.

Thank you for your help kadison, much appreciated

The password is usually on the underside of the router itself, unless it's been changed.

If you're already on 5GHz that should avoid most interference so it may not be worth changing the channel.

Of course I am assuming the connection works fine when you use a cable to connect your computer/laptop?

Edited by deleted (Wed 22-Oct-14 11:07:30)

'Bought a booster'

What exactly have you bought? Wi-Fi boosters come in many flavours and the most common ones sold actually increase the coverage but half the speed.

First step should be logging into your netgear router to determine the connection speed and follow that by running a speed test when using Ethernet.

Netgear Router Statistics example http://www.coolwebhome.co.uk/stats/routers.html#netgear
http://www.thinkbroadband.com/speedtest.html post the link to the results page after, as the shape of the graphs can be important.

If the heating boiler is putting out RF that is affecting ADSL then the router statistics should show that.

In reply to a post by kadison44:

The password is usually on the underside of the router itself, unless it's been changed.

If you're already on 5GHz that should avoid most interference so it may not be worth changing the channel.

Of course I am assuming the connection works fine when you use a cable to connect your computer/laptop?

Hubby changed the password but forgot to tell me what to!

Yes I connected the laptop to the netgear this morning first set of speedtests were bad, so rebooted the router and now the speeds (coming into the house) are fine well as good as we will get living out in the sticks miles away from the exchange

In reply to a post by MrSaffron:

'Bought a booster'

What exactly have you bought? Wi-Fi boosters come in many flavours and the most common ones sold actually increase the coverage but half the speed.

First step should be logging into your netgear router to determine the connection speed and follow that by running a speed test when using Ethernet.

Netgear Router Statistics example http://www.coolwebhome.co.uk/stats/routers.html#netgear
http://www.thinkbroadband.com/speedtest.html post the link to the results page after, as the shape of the graphs can be important.

If the heating boiler is putting out RF that is affecting ADSL then the router statistics should show that.

Hi Andrew long time no speak!! Hope you are well

The booster we bought was a Netgear WN2000RPT. I connected the laptop direct to the router this morning (via ethernet), did 2 speed tests both were appalling so I rebooted the router and got a decent'ish speed (for us here being so far from exchange).

I doubt our boiler would be sending out RF signals it's about 30 years old, very basic oil burner just turns on and off that's about it

Zen recommended getting a power over ethernet adapter so I just bought a TP link and am going to see if that helps. I suspect it is something interferring with the wifi signal here but am hoping the TP Link is going to help that [shrugs]

Am going to change the channel now too (now I know the password!!)

Thanks very much for your help/advice, if the problem isn't sorted I'll be back

Any boiler that burns fuel will have a sparker in it and these can change over time to the point where RF noise emits that affects broadband see http://www.thinkbroadband.com/videos/broadband-inter... for video on how to spot RF noisy stuff.

The reboot sounds like what has happened is you had some noise and the broadband reconnected at a slow speed and the modem will remain at that lower speed setting until you give the router a swift kick via the power switch.

In reply to a post by Helan:

Am going to change the channel now too (now I know the password!!)

From what you've now said it does look like an issue with the line and changing the wifi channel is unlikely to help.

MrSaffron is right, it's probably something causing interference on the ADSL frequencies rather than wireless freqencies. Check that boiler or anything else with a (possibly faulty) transformer.

if it is boiler related:

As Mr. Saffron says, some old oil 'boilers' have a continuous (noisy) spark, when they are running, they also have a rotating disk (noisy motor) to throw the oil, (to mix it with the air).
as they run, it could cause the broadband to drop out and reconnect, and at a lower speed, however, line management will also notice this and may increase the target SNR,
hence even without the boiler running, it then connects at a relatively low speed,
find some line stats if you can, my guess is (without boiler running) an SNR of 15db or so, and this dropping to about zero as it starts.
again as Mr. Saffron suggests, survey with an am radio.

ps, you should be able to remove the electrical noise from a boiler, without replacing the whole thing.

In reply to a post by MrSaffron:

Any boiler that burns fuel will have a sparker in it and these can change over time to the point where RF noise emits that affects broadband see http://www.thinkbroadband.com/videos/broadband-inter... for video on how to spot RF noisy stuff.

Ah I didn't realise that thanks Andrew, although we can't get DAB radio here (only 1 channel) and the FM radio is okay for some channels (if it can find them) or just full of static
I just tested the radio at 600 AM turning boiler on and off but it didn't change the static it was bad before and just the same after although when the boiler fired up I did hear a click on the radio but only slightly.

The reboot sounds like what has happened is you had some noise and the broadband reconnected at a slow speed and the modem will remain at that lower speed setting until you give the router a swift kick via the power switch.

Zen told me yday they throttle the line when there are problems to monitor it but its not just the speeds that are the problem one minute I can load a webpage and literally the next minute I I can't it wont load at all on wifi

I have now plugged the TP link into the power socket and put the ethernet cable into the PC which has helped enormously but my iPad and phone still have a weak signal.

In reply to a post by kadison44:

In reply to a post by Helan:

Am going to change the channel now too (now I know the password!!)

From what you've now said it does look like an issue with the line and changing the wifi channel is unlikely to help.

MrSaffron is right, it's probably something causing interference on the ADSL frequencies rather than wireless freqencies. Check that boiler or anything else with a (possibly faulty) transformer.

I did check the boiler but it didn't change the static only for a nano second when it fired up but then went back to normal static (if that makes sense)

In reply to a post by ggremlin:

if it is boiler related:

As Mr. Saffron says, some old oil 'boilers' have a continuous (noisy) spark, when they are running, they also have a rotating disk (noisy motor) to throw the oil, (to mix it with the air).
as they run, it could cause the broadband to drop out and reconnect, and at a lower speed, however, line management will also notice this and may increase the target SNR,
hence even without the boiler running, it then connects at a relatively low speed,
find some line stats if you can, my guess is (without boiler running) an SNR of 15db or so, and this dropping to about zero as it starts.
again as Mr. Saffron suggests, survey with an am radio.

ps, you should be able to remove the electrical noise from a boiler, without replacing the whole thing.

I think these are the line stats - tell me if I need to post something else

System Up Time 25:33:32
Port Status TxPkts RxPkts Collisions Tx B/s Rx B/s Up Time
WAN PPPoE 1889947 2169915 0 3152 21350 24:57:26
LAN1 100M/Full 323548 118506 0 1694 333 25:32:05
LAN2 Link down
LAN3 Link down
LAN4 Link down
WLAN b/g/n 145M 2298404 2110777 0 21906 4436 24:25:16
WLAN a/n/ac 867M 19795 286 0 37 0 24:25:09


ADSL Link Downstream Upstream
Link Rate 6176 Kbps 448 Kbps
Line Attenuation 39.0 dB 24.0 dB
Noise Margin 9.3 dB 27.0 dB

Thank you all for your help very much appreciated. I lost internet yday afternoon completely and was on/off the phone to Zen until 6pm.

I just can't fathom out why this has just suddenly (last 6 weeks or so) started when the line/wifi/signal was fine for 3 years but I guess that's the problem with wifi (too many things can cause interferrance)

At least I can work now after plugging into the ethernet and so far the PC has been fine for loading pages and remote access so I won't lose any more money from not being able to work.

Would just like to get back to a decent wifi on the ipad as I enjoy streaming music and films but its not really possible now unfortunately

So if its just weak signal on ipad and iphone it is nothing to do with Zen and the broadband connection, but congestion/interference in the Wi-Fi spectrum at 2.4 GHz.

Solutions: Add a wireless access point that is dual-band or replace the existing router on the line with a better dual-band wireless device.

Hi Andrew thanks for the reply

In reply to a post by MrSaffron:

So if its just weak signal on ipad and iphone it is nothing to do with Zen and the broadband connection, but congestion/interference in the Wi-Fi spectrum at 2.4 GHz.

Yes I now know it's not Zen's problem/fault it's here, this house something messing about/interferring with the signal

Solutions: Add a wireless access point that is dual-band or replace the existing router on the line with a better dual-band wireless device.

I do have a dual band router, its a 5GHz netgear D62100 about 3 days old! I have the booster (as mentioned above) and I have the TP link now too so I'm guessing to find/sort out the wifi problem will be like looking for a needle in a haystack? [shrugs]

Generally 5GHz will have less range than 2.4G but should give higher speeds and is unlikely to be affected by what may be affecting the 2.4G kit

Time to do things like wireless network scans to see what are best channels to use, and also try naming the 5GHz channels with a different name, then its obvious when you connect to them.

well I spoke too soon yday. Even though PC is hard wired this morning every other page "server not found"
soooo frustrating!

Check the router stats and from a DOS command prompt run

ping -t www.thinkbroadband.com

Do you get a constant stream of replies or are some timing out. Press CTRL C and ping will finish and give you some statistics.

What exchange are you connected to

In reply to a post by MrSaffron:

Check the router stats and from a DOS command prompt run

ping -t www.thinkbroadband.com

Do you get a constant stream of replies or are some timing out. Press CTRL C and ping will finish and give you some statistics.

Pinging www.thinkbroadband.com [80.249.99.130] with 32 bytes of data:
Request timed out.
Reply from 80.249.99.130: bytes=32 time=3220ms TTL=56
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 80.249.99.130: bytes=32 time=1534ms TTL=56
Reply from 80.249.99.130: bytes=32 time=1636ms TTL=56
Reply from 80.249.99.130: bytes=32 time=1623ms TTL=56
Reply from 80.249.99.130: bytes=32 time=1986ms TTL=56
Reply from 80.249.99.130: bytes=32 time=3205ms TTL=56
Request timed out.
Reply from 80.249.99.130: bytes=32 time=3588ms TTL=56
Request timed out.
Request timed out.
Reply from 80.249.99.130: bytes=32 time=3493ms TTL=56
Request timed out.

CTRL C just closed the dos prompt

It is a serious struggle just to load this page to reply to your post

In reply to a post by flippery:

What exchange are you connected to

Flax Bourton or Backwell not sure how do I find that out?

Ok try ping -t 62.3.86.42

This is I think your Zen gateway and if the packet loss is showing up there then it may be a DSL issue, or backhaul issue.

If it was me I'd also give the router a good old reboot

In reply to a post by MrSaffron:

Ok try ping -t 62.3.86.42

This is I think your Zen gateway and if the packet loss is showing up there then it may be a DSL issue, or backhaul issue.

If it was me I'd also give the router a good old reboot

I'm now on the laptop plugged directly into the router

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\helan>ping -t 62.3.86.42

Pinging 62.3.86.42 with 32 bytes of data:
Reply from 62.3.86.42: bytes=32 time=182ms TTL=254
Reply from 62.3.86.42: bytes=32 time=123ms TTL=254
Reply from 62.3.86.42: bytes=32 time=160ms TTL=254
Reply from 62.3.86.42: bytes=32 time=131ms TTL=254
Reply from 62.3.86.42: bytes=32 time=158ms TTL=254
Reply from 62.3.86.42: bytes=32 time=132ms TTL=254
Reply from 62.3.86.42: bytes=32 time=51ms TTL=254
Reply from 62.3.86.42: bytes=32 time=232ms TTL=254
Reply from 62.3.86.42: bytes=32 time=171ms TTL=254
Reply from 62.3.86.42: bytes=32 time=186ms TTL=254
Reply from 62.3.86.42: bytes=32 time=52ms TTL=254
Reply from 62.3.86.42: bytes=32 time=53ms TTL=254
Reply from 62.3.86.42: bytes=32 time=104ms TTL=254
Reply from 62.3.86.42: bytes=32 time=104ms TTL=254
Reply from 62.3.86.42: bytes=32 time=147ms TTL=254
Reply from 62.3.86.42: bytes=32 time=119ms TTL=254
Reply from 62.3.86.42: bytes=32 time=59ms TTL=254
Reply from 62.3.86.42: bytes=32 time=52ms TTL=254
Reply from 62.3.86.42: bytes=32 time=102ms TTL=254
Reply from 62.3.86.42: bytes=32 time=52ms TTL=254
Reply from 62.3.86.42: bytes=32 time=199ms TTL=254
Reply from 62.3.86.42: bytes=32 time=195ms TTL=254
Reply from 62.3.86.42: bytes=32 time=101ms TTL=254
Reply from 62.3.86.42: bytes=32 time=190ms TTL=254
Reply from 62.3.86.42: bytes=32 time=139ms TTL=254
Reply from 62.3.86.42: bytes=32 time=123ms TTL=254
Reply from 62.3.86.42: bytes=32 time=183ms TTL=254
Reply from 62.3.86.42: bytes=32 time=64ms TTL=254
Reply from 62.3.86.42: bytes=32 time=260ms TTL=254
Reply from 62.3.86.42: bytes=32 time=120ms TTL=254
Reply from 62.3.86.42: bytes=32 time=73ms TTL=254
Reply from 62.3.86.42: bytes=32 time=227ms TTL=254
Reply from 62.3.86.42: bytes=32 time=85ms TTL=254
Reply from 62.3.86.42: bytes=32 time=182ms TTL=254
Reply from 62.3.86.42: bytes=32 time=150ms TTL=254
Reply from 62.3.86.42: bytes=32 time=52ms TTL=254
Reply from 62.3.86.42: bytes=32 time=95ms TTL=254
Reply from 62.3.86.42: bytes=32 time=211ms TTL=254
Reply from 62.3.86.42: bytes=32 time=196ms TTL=254
Reply from 62.3.86.42: bytes=32 time=129ms TTL=254
Reply from 62.3.86.42: bytes=32 time=103ms TTL=254
Reply from 62.3.86.42: bytes=32 time=80ms TTL=254
Reply from 62.3.86.42: bytes=32 time=135ms TTL=254
Reply from 62.3.86.42: bytes=32 time=58ms TTL=254
Reply from 62.3.86.42: bytes=32 time=127ms TTL=254
Reply from 62.3.86.42: bytes=32 time=52ms TTL=254
Reply from 62.3.86.42: bytes=32 time=117ms TTL=254
Reply from 62.3.86.42: bytes=32 time=211ms TTL=254
Reply from 62.3.86.42: bytes=32 time=52ms TTL=254
Reply from 62.3.86.42: bytes=32 time=177ms TTL=254
Reply from 62.3.86.42: bytes=32 time=153ms TTL=254
Reply from 62.3.86.42: bytes=32 time=188ms TTL=254
Reply from 62.3.86.42: bytes=32 time=253ms TTL=254
Reply from 62.3.86.42: bytes=32 time=204ms TTL=254
Reply from 62.3.86.42: bytes=32 time=111ms TTL=254
Reply from 62.3.86.42: bytes=32 time=140ms TTL=254
Reply from 62.3.86.42: bytes=32 time=51ms TTL=254
Reply from 62.3.86.42: bytes=32 time=214ms TTL=254
Reply from 62.3.86.42: bytes=32 time=99ms TTL=254
Reply from 62.3.86.42: bytes=32 time=128ms TTL=254
Reply from 62.3.86.42: bytes=32 time=156ms TTL=254
Reply from 62.3.86.42: bytes=32 time=122ms TTL=254
Reply from 62.3.86.42: bytes=32 time=251ms TTL=254
Reply from 62.3.86.42: bytes=32 time=101ms TTL=254
Reply from 62.3.86.42: bytes=32 time=144ms TTL=254
Reply from 62.3.86.42: bytes=32 time=53ms TTL=254
Reply from 62.3.86.42: bytes=32 time=52ms TTL=254
Reply from 62.3.86.42: bytes=32 time=52ms TTL=254
Reply from 62.3.86.42: bytes=32 time=150ms TTL=254
Reply from 62.3.86.42: bytes=32 time=272ms TTL=254
Reply from 62.3.86.42: bytes=32 time=51ms TTL=254
Reply from 62.3.86.42: bytes=32 time=51ms TTL=254
Reply from 62.3.86.42: bytes=32 time=122ms TTL=254
Reply from 62.3.86.42: bytes=32 time=223ms TTL=254
Reply from 62.3.86.42: bytes=32 time=51ms TTL=254
Reply from 62.3.86.42: bytes=32 time=51ms TTL=254
Reply from 62.3.86.42: bytes=32 time=226ms TTL=254
Reply from 62.3.86.42: bytes=32 time=53ms TTL=254
Reply from 62.3.86.42: bytes=32 time=151ms TTL=254
Reply from 62.3.86.42: bytes=32 time=163ms TTL=254
Reply from 62.3.86.42: bytes=32 time=54ms TTL=254
Reply from 62.3.86.42: bytes=32 time=80ms TTL=254
Reply from 62.3.86.42: bytes=32 time=62ms TTL=254
Reply from 62.3.86.42: bytes=32 time=52ms TTL=254
Reply from 62.3.86.42: bytes=32 time=57ms TTL=254
Reply from 62.3.86.42: bytes=32 time=77ms TTL=254
Reply from 62.3.86.42: bytes=32 time=201ms TTL=254
Reply from 62.3.86.42: bytes=32 time=80ms TTL=254
Reply from 62.3.86.42: bytes=32 time=55ms TTL=254
Reply from 62.3.86.42: bytes=32 time=55ms TTL=254
Reply from 62.3.86.42: bytes=32 time=63ms TTL=254
Reply from 62.3.86.42: bytes=32 time=149ms TTL=254
Reply from 62.3.86.42: bytes=32 time=88ms TTL=254
Reply from 62.3.86.42: bytes=32 time=157ms TTL=254
Reply from 62.3.86.42: bytes=32 time=170ms TTL=254
Reply from 62.3.86.42: bytes=32 time=52ms TTL=254
Reply from 62.3.86.42: bytes=32 time=139ms TTL=254
Reply from 62.3.86.42: bytes=32 time=250ms TTL=254
Reply from 62.3.86.42: bytes=32 time=57ms TTL=254
Reply from 62.3.86.42: bytes=32 time=51ms TTL=254
Reply from 62.3.86.42: bytes=32 time=102ms TTL=254
Reply from 62.3.86.42: bytes=32 time=170ms TTL=254
Reply from 62.3.86.42: bytes=32 time=199ms TTL=254
Reply from 62.3.86.42: bytes=32 time=178ms TTL=254
Reply from 62.3.86.42: bytes=32 time=191ms TTL=254
Reply from 62.3.86.42: bytes=32 time=52ms TTL=254
Reply from 62.3.86.42: bytes=32 time=95ms TTL=254
Reply from 62.3.86.42: bytes=32 time=52ms TTL=254
Reply from 62.3.86.42: bytes=32 time=93ms TTL=254
Reply from 62.3.86.42: bytes=32 time=217ms TTL=254
Reply from 62.3.86.42: bytes=32 time=162ms TTL=254
Reply from 62.3.86.42: bytes=32 time=188ms TTL=254
Reply from 62.3.86.42: bytes=32 time=51ms TTL=254
Reply from 62.3.86.42: bytes=32 time=83ms TTL=254

Ping statistics for 62.3.86.42:
Packets: Sent = 114, Received = 114, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 51ms, Maximum = 272ms, Average = 125ms
Control-C
^C
C:\Users\helan>

now on laptop after a reboot
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\helan>ping -t 62.3.86.42

Pinging 62.3.86.42 with 32 bytes of data:
Reply from 62.3.86.42: bytes=32 time=138ms TTL=254
Reply from 62.3.86.42: bytes=32 time=240ms TTL=254
Reply from 62.3.86.42: bytes=32 time=180ms TTL=254
Reply from 62.3.86.42: bytes=32 time=94ms TTL=254
Reply from 62.3.86.42: bytes=32 time=147ms TTL=254
Reply from 62.3.86.42: bytes=32 time=233ms TTL=254
Reply from 62.3.86.42: bytes=32 time=176ms TTL=254
Reply from 62.3.86.42: bytes=32 time=201ms TTL=254
Reply from 62.3.86.42: bytes=32 time=136ms TTL=254
Reply from 62.3.86.42: bytes=32 time=254ms TTL=254
Reply from 62.3.86.42: bytes=32 time=212ms TTL=254
Reply from 62.3.86.42: bytes=32 time=101ms TTL=254
Reply from 62.3.86.42: bytes=32 time=118ms TTL=254
Reply from 62.3.86.42: bytes=32 time=206ms TTL=254
Reply from 62.3.86.42: bytes=32 time=202ms TTL=254
Reply from 62.3.86.42: bytes=32 time=196ms TTL=254
Reply from 62.3.86.42: bytes=32 time=173ms TTL=254
Reply from 62.3.86.42: bytes=32 time=156ms TTL=254
Reply from 62.3.86.42: bytes=32 time=83ms TTL=254

Ping statistics for 62.3.86.42:
Packets: Sent = 19, Received = 19, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 83ms, Maximum = 254ms, Average = 170ms
Control-C
^C
C:\Users\helan>

Okay, I just spoken to Zen who made me do a quiet line test and they did some tests. Their end showed no problems and I didn't hear any crackling on my phone line doing the test but the Zen guy said when talking to me he could hear lots of static cracks and pops. His recommendation was to pull the phone line out for an hour and see how the internet/connection is.

The phone has been out for nearly an hour and I did a speed test on here
http://www.thinkbroadband.com/speedtest/results.html...

There was/is a warning about congestion but not sure if that means at the exchange or at this house (we have 8 things on the network - iphones/ipads/printer/2 pc's etc)

After a router reboot it seems to be back to normal now although my laptop has just come up saying "windows has detected an IP address conflict". Could that be the problem? Although the laptop is rarely on but maybe it's something else conflicting? The printer or something similar?

How do I rectify that problem? Not sure how to assign IP addresses to things. It might be getting a bit technical for me now LOL

And you are sure no one was downloading or uploading a lot of data at that time ?

In reply to a post by MrSaffron:

And you are sure no one was downloading or uploading a lot of data at that time ?

positive there was only me here at that time, well pat was here but fast asleep

In which case is a sign of exchange or backhaul congestion.

If was a dsl issue would expect the packet loss to be pretty constant.

If the exchange is just a bt wholesale one rather than one with zen backhaul them congestion is something that people hace been seeing on various providers and gets fixed after a few weeks

For IP.
Just switch off all machines including router.
Restart router and leave few minutes.
switch on machine one at a time and confirm internet connection, before switching on next

Or for one machine only
https://www.cs.cmu.edu/~help/networking/IP_renew.html

Edited by flippery (Sat 25-Oct-14 20:37:04)

Post deleted by David_W

In reply to a post by MrSaffron:

Ok try ping -t 62.3.86.42

This is I think your Zen gateway and if the packet loss is showing up there then it may be a DSL issue, or backhaul issue.

Zen allocate gateways dynamically. If 62.3.86.42 (ge2-2-124.subs.dsl6.wh-man.zen.net.uk) is the last hop but one on a current traceroute into Helan's WAN IP address, I believe the gateway address from the user's perspective is 62.3.83.21 (losubs.subs.dsl6.wh-man.zen.net.uk), though that is something of an educated guess.

The easiest way to establish the current gateway IP address from a Zen connection is to traceroute to an address anywhere on the Internet - the gateway will be the IP address of the first step. (I acknowledge and ignore the existence of hops that are hidden from the user by tunneling protocols such as L2TP - there is nothing the user can do with any knowledge they have about these hops in any event). Other options for discovering the current gateway IP address from the Zen subscriber's perspective are scrutinising the router's routing table or PPP logs.

It should make little difference whatever you ping on Zen's core network, though measuring the latency of the first IP hop is the best when attempting to diagnose DSL or backhaul issues.


A Zen user can find out whether they are using Zen or BT Wholesale backhaul from the customer portal. Go to "My Services" and choose "View Line Data", then look for the line that begins "Your current line technology is". Anything mentioning "IP Stream" or "WBMC" is BT Wholesale backhaul. Anything mentioning "LLU" or "GEA" is Zen backhaul.

In reply to a post by MrSaffron:

In which case is a sign of exchange or backhaul congestion.

If was a dsl issue would expect the packet loss to be pretty constant.

If the exchange is just a bt wholesale one rather than one with zen backhaul them congestion is something that people hace been seeing on various providers and gets fixed after a few weeks

I dont quite get what you're saying Andrew sorry. Are you saying it's a BT problem/too many ppl on the exchange/congestion at the exchange? If that's the case does it mean I'm stuck like this?

It is so intermiettent literally one minute I can be watching a video on youtube, the next minute it's buffering and then loses the server completely same with reading webpages etc

In reply to a post by flippery:

For IP.
Just switch off all machines including router.
Restart router and leave few minutes.
switch on machine one at a time and confirm internet connection, before switching on next

Or for one machine only
https://www.cs.cmu.edu/~help/networking/IP_renew.html

Thank you, I managed to give all devices their own IP's yday

In reply to a post by David_W:

Zen allocate gateways dynamically. If 62.3.86.42 (ge2-2-124.subs.dsl6.wh-man.zen.net.uk) is the last hop but one on a current traceroute into Helan's WAN IP address, I believe the gateway address from the user's perspective is 62.3.83.21 (losubs.subs.dsl6.wh-man.zen.net.uk), though that is something of an educated guess.

The easiest way to establish the current gateway IP address from a Zen connection is to traceroute to an address anywhere on the Internet - the gateway will be the IP address of the first step. (I acknowledge and ignore the existence of hops that are hidden from the user by tunneling protocols such as L2TP - there is nothing the user can do with any knowledge they have about these hops in any event). Other options for discovering the current gateway IP address from the Zen subscriber's perspective are scrutinising the router's routing table or PPP logs.

It should make little difference whatever you ping on Zen's core network, though measuring the latency of the first IP hop is the best when attempting to diagnose DSL or backhaul issues.


A Zen user can find out whether they are using Zen or BT Wholesale backhaul from the customer portal. Go to "My Services" and choose "View Line Data", then look for the line that begins "Your current line technology is". Anything mentioning "IP Stream" or "WBMC" is BT Wholesale backhaul. Anything mentioning "LLU" or "GEA" is Zen backhaul.

Thank you, I found it "Your current line technology is IP Stream Max ADSL."

Not sure what that means though

a trace to zen gives me

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\Helan>tracert www.zen.co.uk

Tracing route to zen.co.uk [212.23.0.100]
over a maximum of 30 hops:

1 4 ms 3 ms 3 ms 192.168.0.1
2 55 ms 56 ms 55 ms losubs.subs.dsl6.wh-man.zen.net.uk [62.3.83.21]

3 59 ms 55 ms 55 ms no-dns-yet-62-3-86-45.zen.co.uk [62.3.86.45]
4 55 ms 55 ms 55 ms ge-2-0-0-0.cr1.wh-man.zen.net.uk [62.3.80.49]
5 58 ms 57 ms 55 ms ae0-0.dr1.sp-roch.zen.net.uk [62.3.80.90]
6 57 ms 59 ms 57 ms ge-1-2-105.access.ar1.sp-roch.zen.net.uk [62.3.8
1.150]
7 56 ms 57 ms 59 ms ge-0-0-15-100.fwhosting1a.sp-roch.corp.zen.net.u
k [88.98.128.202]
8 57 ms 61 ms 57 ms core-212-23-0-100.zen.net.uk [212.23.0.100]

Trace complete.

C:\Users\Helan>

p.s. before I even had a chance to post this and my exchange details I lost connection to the server (timed out)

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\Helan>tracert www.zen.co.uk
Unable to resolve target system name www.zen.co.uk.

Rebooted router

C:\Users\Helan>tracert www.zen.co.uk

Tracing route to zen.co.uk [212.23.0.100]
over a maximum of 30 hops:

1 3 ms 3 ms 3 ms 192.168.0.1
2 80 ms 55 ms 57 ms losubs.subs.dsl1.wh-man.zen.net.uk [62.3.87.145]

3 84 ms 56 ms 56 ms ge-2-1-0-160.cr1.wh-man.zen.co.uk [62.3.87.161]

4 57 ms 56 ms 59 ms ae0-0.dr1.sp-roch.zen.net.uk [62.3.80.90]
5 59 ms 59 ms 59 ms ge-1-1-104.access.ar1.sp-roch.zen.net.uk [62.3.8
1.146]
6 57 ms 56 ms 56 ms ge-0-0-15-100.fwhosting1a.sp-roch.corp.zen.net.u
k [88.98.128.202]
7 59 ms 61 ms 57 ms core-212-23-0-100.zen.net.uk [212.23.0.100]

Trace complete.

C:\Users\Helan>

My exchange is Flax Bourton http://www.kitz.co.uk/adsl/adslchecker.php

This really really frustrating the internet is becoming unusable at the moment

"IP Stream Max ADSL" means BT Wholesale ADSL over their older 20CN network. MrSaffron is in a better position than I am to know about the current extent of link saturation problems on this older system.

SamKnows, which isn't always that up to date, suggests that there's no BT Wholesale 21CN WBC at your exchange - if there was, Zen would have moved you to that system. The only LLU operator appears to be TalkTalk, though I would suggest doing all you can with Zen before giving up and moving to TalkTalk or a TalkTalk reseller. TalkTalk's retail service has a decidedly mixed reputation, though a TalkTalk Business reseller might be a good option if BT Wholesale proves unworkable.

If this is a problem with the BT Wholesale network affecting your exchange, hopefully there will be a solution to that problem in due course.


So far as the traceroutes to an Internet location go, your current Zen gateway will be the second hop - the first is your local router. If you want to monitor the connection between you and Zen, the best you can do is to ping -t that second hop IP address.


By way of comparison, this is what I get on my Zen connection (80/20 FTTC on Zen backhaul - the line technology is "GEA FTTC"):

C:\Users\David>ping -t 62.3.87.147

Pinging 62.3.87.147 with 32 bytes of data:
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=18ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=18ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254

Ping statistics for 62.3.87.147:
Packets: Sent = 38, Received = 38, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 18ms, Average = 14ms
Control-C
^C

You can see that the "time" figure doesn't jump around all over the place, suggesting a link that is working well and not suffering from excessive congestion.

If you haven't done so already, why not set up a thinkbroadband Bandwidth Quality Monitor and consider posting the link to the results in this thread. This system gives a graphical illustration of the performance of your connection by pinging it every second. You can see the results of monitoring my Zen connection using the link in my signature.

In reply to a post by David_W:

"IP Stream Max ADSL" means BT Wholesale ADSL over their older 20CN network. MrSaffron is in a better position than I am to know about the current extent of link saturation problems on this older system.

SamKnows, which isn't always that up to date, suggests that there's no BT Wholesale 21CN WBC at your exchange - if there was, Zen would have moved you to that system. The only LLU operator appears to be TalkTalk, though I would suggest doing all you can with Zen before giving up and moving to TalkTalk or a TalkTalk reseller. TalkTalk's retail service has a decidedly mixed reputation, though a TalkTalk Business reseller might be a good option if BT Wholesale proves unworkable.

If this is a problem with the BT Wholesale network affecting your exchange, hopefully there will be a solution to that problem in due course.

I get the impression from Zen that the problem is me/my house/electrical problem inside but they are now monitoring my router (doing a direct ping test) for 24 hours to see if they can see what I see this end

So far as the traceroutes to an Internet location go, your current Zen gateway will be the second hop - the first is your local router. If you want to monitor the connection between you and Zen, the best you can do is to ping -t that second hop IP address.

Thank you, I will do

By way of comparison, this is what I get on my Zen connection (80/20 FTTC on Zen backhaul - the line technology is "GEA FTTC"):

C:\Users\David>ping -t 62.3.87.147

Pinging 62.3.87.147 with 32 bytes of data:
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=18ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=18ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254
Reply from 62.3.87.147: bytes=32 time=15ms TTL=254
Reply from 62.3.87.147: bytes=32 time=14ms TTL=254

Ping statistics for 62.3.87.147:
Packets: Sent = 38, Received = 38, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 18ms, Average = 14ms
Control-C
^C
You can see that the "time" figure doesn't jump around all over the place, suggesting a link that is working well and not suffering from excessive congestion.

That reminds me of my days in London! Oh how I miss being so close to the exchange and having such great speeds/stable connection

I just set up a 2 min monitoring on my 2nd hop and got

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\Helan>ping -t 62.3.87.145

Pinging 62.3.87.145 with 32 bytes of data:
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=64ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=61ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=68ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=81ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=181ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=63ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=139ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=71ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=141ms TTL=252
Reply from 62.3.87.145: bytes=32 time=104ms TTL=252
Reply from 62.3.87.145: bytes=32 time=72ms TTL=252
Reply from 62.3.87.145: bytes=32 time=99ms TTL=252
Reply from 62.3.87.145: bytes=32 time=111ms TTL=252
Reply from 62.3.87.145: bytes=32 time=143ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=69ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=90ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=83ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=65ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=60ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=60ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=60ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=60ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=83ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=63ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=60ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=60ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=60ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=67ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=77ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=60ms TTL=252
Reply from 62.3.87.145: bytes=32 time=60ms TTL=252
Reply from 62.3.87.145: bytes=32 time=65ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=63ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=82ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=56ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=59ms TTL=252
Reply from 62.3.87.145: bytes=32 time=58ms TTL=252
Reply from 62.3.87.145: bytes=32 time=57ms TTL=252
Reply from 62.3.87.145: bytes=32 time=61ms TTL=252

Ping statistics for 62.3.87.145:
Packets: Sent = 181, Received = 181, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 56ms, Maximum = 181ms, Average = 61ms
Control-C
^C
C:\Users\Helan>

Seems to jump enormously between 56ms and 181ms

If you haven't done so already, why not set up a thinkbroadband Bandwidth Quality Monitor and consider posting the link to the results in this thread. This system gives a graphical illustration of the performance of your connection by pinging it every second. You can see the results of monitoring my Zen connection using the link in my signature.

I hadn't set one up previously but I just have, hope the link works
http://www.thinkbroadband.com/ping/share/6fa8d948171...

Last series is much better

Ipstream max is the old system and can see more congestion.

If the router stats are holding reasonable figures then yes congestion can be like this, ie hit and miss

Generally line problems see the modem resyncing that means no connection at all for 30 seconds or more and obvious indication in router logs.

In reply to a post by MrSaffron:

Last series is much better

Ipstream max is the old system and can see more congestion.

Not really what I wanted to hear but guessed as much thanks Andrew

In reply to a post by MrSaffron:

If the router stats are holding reasonable figures then yes congestion can be like this, ie hit and miss

Seems to have been up and (dare I say) stable for 23 hours now

Generally line problems see the modem resyncing that means no connection at all for 30 seconds or more and obvious indication in router logs.

I haven't seen any of that at all so I'm beginning to think it is congestion

Zen have a version of our speed test on their network that support may or may not have got you to run. This rules out congestion on the wider internet, but I believe what you are seeing is in the BT Wholesale segment.

In reply to a post by MrSaffron:

Zen have a version of our speed test on their network that support may or may not have got you to run. This rules out congestion on the wider internet, but I believe what you are seeing is in the BT Wholesale segment.

I didn't know that as Zen hadn't mentioned it but it looks very similar to your speed test
I got the same results and my line *touches wood quickly* seems to be stable for the time being.

One question I have though, if it is congestion at the exchange would my neighbours (we live in a close of 15 houses) not be seeing the same? Some are on TalkTalk, some on PlusNet?

I did speak to some of them over the weekend (Plusnet/talktalk) and they aren't having any problems at all.

TalkTalk is probably LLU so would be unlikely to.

PlusNet customers may or may not.

The congestion may be in the chunk that is linking Zen to the BT Wholesale network too, and experience suggests that if you ask lots of people they cannot spot congestion until the point when nothing works, since they assume buffering of videos and pages taking time to load is normal.

In reply to a post by MrSaffron:

TalkTalk is probably LLU so would be unlikely to.

PlusNet customers may or may not.

The congestion may be in the chunk that is linking Zen to the BT Wholesale network too, and experience suggests that if you ask lots of people they cannot spot congestion until the point when nothing works, since they assume buffering of videos and pages taking time to load is normal.

That makes complete sense Andrew, none of them are tech savvy either so I guess thats very true!

I spoke too soon earlier, trying to remote access into work and connection has dropped out x2 but not at peak times (well one was at 8.26am and the other 9.04am)

32 mins on phone to Zen and now they are telling me to take router out of the faceplate in the kitchen and put it back in the office extension