PDA

View Full Version : Intermittent Slowspeed/Packetloss


Splitarra
18-03-2010, 17:59
Apologies for the length of this post but this has been ongoing for 6 months now so theres quite a bit to cover.

Back in September when VM reduced the price of their 50mb package i upgraded my 20mb line to the new 50mb speed and have since then never had a fully working service. I reported the problems i was having (slowspeed and packetloss although pingtimes during the slowspeed packet loss were 15ms as if the line was idle) fairly soon after installing the line and have been in constant contact with VM since then and still havent had any luck finding a fix so im posting here to see how many people are having the same issue i am (ive seen several similar issues but nothing the same) and to see if anybody can offer any suggestion as to what i can do next.

When i was on 20mb i never had any problems with the line other than the odd outage that affected the whole area so i dont count those. Ever since moving to 50mb i get completely random periods lasting from a few minutes to several hours where my download speeds on newsgroups will drop to around 5mbps and 30-40% packetloss that stops any webpages from loading. if i cancel the download the packetloss goes away and i can brows the web with no problems. running a speed test from the internal virgin media speedtest site would most likely give a download speed of 50mb but again i wont be able to view any web pages due to packetloss. downloading some ubuntu images from the virgin ubuntu download directory ( i usually start 3 downloads to make sure the line is maxed) causes no other webpages to load ( sometimes i cant start the 3 downloads) and probably will cause the downloads to corrupt and the downloads complete well under the 690mb in size they should be.

I initially raised this to vm over the phone where they said my power levels were too high, i had 8-9db on the downstream at the time, the first engineer came out and said they couldnt find anything wrong.
I called back and vm sent out another engineer who this time replaced the modem and added a 6 and 10 db attenuator as this new modem was reporting power levels of 16-18db. this made no difference and the engineer at the time was lucky enough to see the problem happening while he was there so he passed this onto the priciple engineer for the area who came out for another visit.
She came out but again couldnt find anything wrong and said she would check some of their monitoring systems the next day to see if she could see any problems on the line.
she couldnt see anything wrong on the monitoring systems so came out again and this time made some changes in the cabinet to try to reduce the powerlevels so i wouldnt need the attenuators but couldnt reduce them enough to stop me from needing them. During this time i tried with an without the attenuators and having them on or off made no difference to the performance of the line.
The next step that vm did was to do a repull of the cable from the cabinet into my house, a week before this was due to be completed the line went hard down and an engineer came out and found a problem with the cable and did the repull early but this still didnt fix the problem.

I then escalated this past the principle engineer and was talking to the engineering manager for the area.
vm then found some issues with the fibre being dirty and requiring cleaning near the headend, this happened a couple of times but still no improvement in the line. next they found a fault with the headend itself and had to replace one of the cards there. again, still no improvement. during this time one of the network engineers in the area had also had a look at the line and was unable to see any problems when testing from the box in the street.
i also had some sort of filtering/monitoring device attached to the back of the modem at this time as well which was hoped would see where the problem was comming from but didnt help.

after this there was a period where i just left it as i'd gotten tired of constantly chasing this and getting nowhere but eventually i emailed Neil Berkett to intervene and he passed it to one of his high level complaints team.
from here vm found another issue with the fibre at the headend which had no effect, the power levels dropped marginally but not much.
I sent through a number of ping tests, trace routes and pathpings showing the packetloss i was getting and another engineer was sent to my house, this time it was one of the network engineers who had been looking at this line previously. he couldnt find any issue with the line again and it wasnt actually running badly when he was there which didnt help. he did find that the new modem i had was reporting bad power readings so he arranged for that to be swapped again. which was done a few days later.

the new modem didnt help still and the power levels were still a little high so vm did some work reducing those without me needing to use the attenuators and now my power levels hover between 0 and -1. the fluctuated up to 2 a few times while vm were running more tests on the line. i was still having problems with the speed and packetloss tho.

I then asked vm to downgrade my line to 20mb as i hadnt had any issues on that which they did although grudgingly. the line ran a lot better on 20mb, speeds still dropped sometimes but nowhere near as much as when it was on 50mb although the line was hard to test during the day due to the usage caps on 20mb. this was still on the 50mb modem running on docsis 3. i wanted vm to then reactivate my old modem so that i could test that and with docsis1 but they wouldnt do that.

then i had vm trying to fob me off stating that web pages would load slow when im maxing out the line however i went back to them with the fact that a, the webpages weren't loading slow, they weren't loading at all and b, im only downloading at 5mb when i get the packetloss. so they retracted those claims. they also tried to tell me it was slow when i was testing it on 20mb because i had hit the download cap which was also rubbish because a, it was at 8am and there was no cap at 8 am and b, when the lines capped ping times go through the roof but i dont get packetloss, when i have the problem ping times are low as if the line is idle (15ms) but theres high packetloss.

Ive spoken to the network engineer while the line was running slowly and he logged onto the ubr and ran some ping tests back to my modem which all came back with no loss and also some pings externally which all came back with no issues too. they have no reported congestion issues on this ubr and say they have no one else in the area with the same problem i am having.
Testing i have done my side to eliminate my equipment is testing from 2 seperate pcs, both directly into the modem and via the virgin supplied router. one pc is running xp, the other windows 7. i have tested with 100mb ethernet and 1gb ethernet over cat5e and cat6 cables.

Something i have noticed while troubleshooting this is if i reboot the modem then theres a very good chance the line will run poorly just after it reconnects although generally only for a short time around 5 mins.

This is currently being looked at by vm's INMC team to check the routing but im really not sure what i can do next if they also say nothing is wrong.

If anyone can provide some suggestions of where to take this next id be very grateful or if anyone else can confirm that they're also having the same issues. if its any use this is in the CR2 area.

Ive got lots and lots of pictures and logs of pings, traceroutes and path pings ill include a couple to look at. i think thats everything but if you have any questions let me know.

router logs

First Time Last Time Priority Description
Mon Feb 8 19:25:47 2010 Mon Feb 8 19:25:47 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:26:05 2010 Mon Feb 8 19:26:05 2010 Critical (3) Unicast Ranging Received Abort Response - initializing MAC;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:26:11 2010 Mon Feb 8 19:26:12 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:26:37 2010 Mon Feb 8 19:26:37 2010 Critical (3) Unicast Ranging Received Abort Response - initializing MAC;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:26:43 2010 Mon Feb 8 19:26:43 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:26:51 2010 Mon Feb 8 19:26:53 2010 Critical (3) SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:27:07 2010 Mon Feb 8 19:27:07 2010 Critical (3) Unicast Ranging Received Abort Response - initializing MAC;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:27:12 2010 Mon Feb 8 19:27:18 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:27:36 2010 Mon Feb 8 19:27:36 2010 Critical (3) Unicast Ranging Received Abort Response - initializing MAC;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:27:42 2010 Mon Feb 8 19:27:43 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:28:01 2010 Mon Feb 8 19:28:01 2010 Critical (3) Unicast Ranging Received Abort Response - initializing MAC;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:28:08 2010 Mon Feb 8 19:28:08 2010 Warning (5) MDD message timeout;CM-MAC=-;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:28:44 2010 Mon Feb 8 19:28:44 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Tue Feb 9 15:46:25 2010 Tue Feb 9 15:46:25 2010 Critical (3) SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Tue Feb 9 15:46:55 2010 Tue Feb 9 15:46:55 2010 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Wed Feb 10 10:20:28 2010 Wed Feb 10 10:20:28 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Fri Feb 12 07:46:41 2010 Fri Feb 12 07:46:41 2010 Critical (3) Unicast Ranging Received Abort Response - initializing MAC;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Fri Feb 12 07:49:11 2010 Fri Feb 12 07:49:11 2010 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 15 07:18:04 2010 Mon Feb 15 07:18:04 2010 Error (4) DHCP RENEW sent - No response for IPv;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 15 11:28:02 2010 Mon Feb 15 11:44:59 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 15 17:02:54 2010 Mon Feb 15 17:02:54 2010 Error (4) DHCP RENEW sent - No response for IPv;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Time Not Established Fri Feb 19 10:11:42 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Sun Feb 21 07:06:05 2010 Mon Feb 22 05:28:53 2010 Error (4) DHCP RENEW sent - No response for IPv;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 22 05:29:36 2010 Mon Feb 22 05:29:36 2010 Notice (6) DHCP Renew - lease parameters time server-62.30.112.121;tftp file-P1ade0bb1ce9c91ad.cm modifie;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 22 15:23:19 2010 Mon Feb 22 17:01:12 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 22 20:50:11 2010 Mon Feb 22 20:50:11 2010 Critical (3) SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 22 21:07:18 2010 Mon Feb 22 21:07:18 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 22 21:08:20 2010 Mon Feb 22 21:08:20 2010 Critical (3) SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 22 21:08:43 2010 Mon Feb 22 21:08:43 2010 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Time Not Established Sat Feb 27 18:22:43 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Sat Feb 27 21:19:55 2010 Mon Mar 1 01:58:22 2010 Error (4) DHCP RENEW sent - No response for IPv;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Mar 1 01:59:14 2010 Mon Mar 1 01:59:14 2010 Notice (6) DHCP Renew - lease parameters tftp file-Pcaa1a92007a50b13.cm modifie;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Tue Mar 2 19:54:40 2010 Tue Mar 2 19:54:40 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Thu Mar 4 11:59:21 2010 Fri Mar 5 10:20:31 2010 Error (4) DHCP RENEW sent - No response for IPv;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Fri Mar 5 10:21:13 2010 Fri Mar 5 10:21:13 2010 Notice (6) DHCP Renew - lease parameters time server-62.30.112.121;tftp file-Pcaa1a92007a50b13.cm modifie;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Tue Mar 9 16:32:20 2010 Wed Mar 10 20:23:39 2010 Error (4) DHCP RENEW sent - No response for IPv;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Wed Mar 10 20:24:29 2010 Wed Mar 10 20:24:29 2010 Notice (6) DHCP Renew - lease parameters tftp file-Pcaa1a92007a50b13.cm modifie;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Sun Mar 14 08:55:57 2010 Mon Mar 15 07:58:23 2010 Error (4) DHCP RENEW sent - No response for IPv;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;
Mon Mar 15 07:59:06 2010 Mon Mar 15 07:59:06 2010 Notice (6) DHCP Renew - lease parameters time server-62.30.112.122;tftp file-Pcaa1a92007a50b13.cm modifie;CM-MAC=-;CMTS-MAC=-;CM-QOS=1.1;CM-VER=3.0;

Sephiroth
18-03-2010, 22:57
Your story tells everyone just what can go wrong from your end therough to the head end.

Re-pull, dirty laser, head end card .....

The packet loss (of discardable pings) is an upstream issue which could be congestion at your first hop, IMO. This could be, in turn, a load balancing issue or a malfunction (which I'd expect their event management tools to pick up).

In the absence of your modem event log, we can't make any event correlation with the codeword errors.

You anecdotally say that your ping times are OK. Yet at the first VM hop (with non-tragic ping time), there appears to have been 44% ping packet loss. I find that strange and would like to see that cross-checked with pathping www.bbc.co.uk.

Look forward to your reply with pathping & event log.

Splitarra
19-03-2010, 09:33
Thanks for the response.

Sorry i did include the modem logs, its in the spoiler bit at the bottom, i called them router logs, thats what happens when you spend all day with adsl routers :)

i too thought at one point it could be due to a congestion or upstream issue, although on both my end and on the virgin network the upload wasnt congested. The virgin side of things was confirmed by one of the network engineers in the area who was looking at the network while it was running slow who said the ubr wasnt congested, and was running around 60% capacity iirc.

Hopefully ill get some update from their INMC team soonish to confirm the situation with the remainder of the vm network.

I have a couple of pathpings to google but none to the bbc currently, i can run some downloads today and see if i can get a bbc one. i have to run it over rdp as im not at home which im sure you can imagine does make it fairly difficult to run remotely with all the packetloss i get making rdp hang and drop completely.

in regards to packets dropped on the vm routers their network engineer was saying that their routers will drop ping responses as they're setup to prioritise traffic passing through the routers as opposed to traffic aimed at their routers like pings but i only get the odd rare drop when the line is running ok even when downloading at the full 50mbps

one note about the codeword errors, at first these were around 100-200 on uncorrected and 80ish for corrected, its only since the line was regraded down to 20mb then back up to 50mb that those errors have risen.

pathping to google
Tracing route to www.l.google.com [66.102.9.104]

over a maximum of 30 hops:

0 fileserver [192.168.0.104]

1 10.89.180.1

2 * osr01croy-ge233.network.virginmedia.net [81.96.224.201]

3 brnt-bb-1a-ae2-0.network.virginmedia.net [195.182.178.82]

4 * * manc-bb-1b-as5-0.network.virginmedia.net [62.252.192.90]

5 tele-ic-3-ae0-0.network.virginmedia.net [212.43.163.70]

6 162-14-250-212.static.virginmedia.com [212.250.14.162]

7 209.85.255.175

8 209.85.251.190

9 64.233.174.187

10 * * *

Computing statistics for 250 seconds...

Source to Here This Node/Link

Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address

0 fileserver [192.168.0.104]

15/ 100 = 15% |

1 --- 100/ 100 =100% 85/ 100 = 85% 10.89.180.1

0/ 100 = 0% |

2 9ms 15/ 100 = 15% 0/ 100 = 0% osr01croy-ge233.network.virginmedia.net [81.96.224.201]

1/ 100 = 1% |

3 12ms 23/ 100 = 23% 7/ 100 = 7% brnt-bb-1a-ae2-0.network.virginmedia.net [195.182.178.82]

0/ 100 = 0% |

4 16ms 16/ 100 = 16% 0/ 100 = 0% manc-bb-1b-as5-0.network.virginmedia.net [62.252.192.90]

1/ 100 = 1% |

5 22ms 24/ 100 = 24% 7/ 100 = 7% tele-ic-3-ae0-0.network.virginmedia.net [212.43.163.70]

0/ 100 = 0% |

6 27ms 17/ 100 = 17% 0/ 100 = 0% 162-14-250-212.static.virginmedia.com [212.250.14.162]

1/ 100 = 1% |

7 17ms 21/ 100 = 21% 3/ 100 = 3% 209.85.255.175

0/ 100 = 0% |

8 27ms 18/ 100 = 18% 0/ 100 = 0% 209.85.251.190

1/ 100 = 1% |

9 24ms 19/ 100 = 19% 0/ 100 = 0% 64.233.174.187

81/ 100 = 81% |

10 --- 100/ 100 =100% 0/ 100 = 0% fileserver [0.0.0.0]



Trace complete.

Splitarra
20-03-2010, 17:10
Here is a pathping to bbc as requested

Welshchris
20-03-2010, 17:21
I am having identical issues to u mate on 50mb and no one can track down the issue.

My connection for the most part is fine now, but every now and then it grinds to a dead hault and then i get results like this....

C:\Users\c>ping bbc.co.uk

Pinging bbc.co.uk [212.58.224.138] with 32 bytes of data:
Request timed out.
Reply from 212.58.224.138: bytes=32 time=60ms TTL=120
Request timed out.
Reply from 212.58.224.138: bytes=32 time=473ms TTL=120

Ping statistics for 212.58.224.138:
Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
Minimum = 60ms, Maximum = 473ms, Average = 266ms

C:\Users\c>tracert bbc.co.uk

Tracing route to bbc.co.uk [212.58.224.138]
over a maximum of 30 hops:

1 * 178 ms 7 ms
cwma-cmts-07-lback-20.network.virginmedia.net [8
6.5.132.1]
2 * * * Request timed out.
3 10 ms 11 ms 11 ms brhm-bb-1a-ge-130-0.network.virginmedia.net
[212
.43.162.105]
4 16 ms 15 ms 15 ms nrth-bb-1b-ae2-0.network.virginmedia.net
[62.253
.185.85]
5 18 ms 19 ms 19 ms tele-ic-1-as0-0.network.virginmedia.net
[62.253.
184.2]
6 17 ms 19 ms 19 ms pos6-1.rt0.thdo.bbc.co.uk [212.58.239.237]
7 60 ms 207 ms 200 ms 212.58.238.129
8 17 ms 19 ms 19 ms virtual-vip.thdo.bbc.co.uk [212.58.224.138]

Trace complete.

This can last anything from a few mins to almost an hour.

Sephiroth
20-03-2010, 20:10
@ Splittara

The Pathping more or less confirms your earlier ping stats. There is no upstream delay getting onto the VM network according to this ping time snapshot. All the way through the nodes, ping packets are discarded as they are low priority data.

Importantly, there are no packets lost that are addressed to the next or follwing nodes. So on this evidence, I don't see an upstream symptom.

What's your downstream situation? Are downloads up to the mark? What does your event log say? Are there any T3 or T4 timeouts?

Peter_
20-03-2010, 22:27
I am having identical issues to u mate on 50mb and no one can track down the issue.
.
He is on a Cisco and you are on a BSR so they cannot be identical due to being different kit.

Welshchris
20-03-2010, 22:34
just because we are on different kit doesnt mean the problem cant be the same in action.

Ben B
20-03-2010, 22:35
just because we are on different kit doesnt mean the problem cant be the same in action.
The problem might be the same or similar, but the reasoning behind it will surely be different.

Splitarra
20-03-2010, 22:41
heres the event log

The network engineer that i was speaking to did say that they had done some work to eliminate the T3 timeouts, cant remember the date of that but it was around the first half of feb i think.

Mon Feb 8 19:26:11 2010 Mon Feb 8 19:26:12 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:26:37 2010 Mon Feb 8 19:26:37 2010 Critical (3) Unicast Ranging Received Abort Response - initializing MAC;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:26:43 2010 Mon Feb 8 19:26:43 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:26:51 2010 Mon Feb 8 19:26:53 2010 Critical (3) SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:27:07 2010 Mon Feb 8 19:27:07 2010 Critical (3) Unicast Ranging Received Abort Response - initializing MAC;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:27:12 2010 Mon Feb 8 19:27:18 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:27:36 2010 Mon Feb 8 19:27:36 2010 Critical (3) Unicast Ranging Received Abort Response - initializing MAC;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:27:42 2010 Mon Feb 8 19:27:43 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:28:01 2010 Mon Feb 8 19:28:01 2010 Critical (3) Unicast Ranging Received Abort Response - initializing MAC;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:28:08 2010 Mon Feb 8 19:28:08 2010 Warning (5) MDD message timeout;CM-MAC=REMOVED;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 8 19:28:44 2010 Mon Feb 8 19:28:44 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Tue Feb 9 15:46:25 2010 Tue Feb 9 15:46:25 2010 Critical (3) SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Tue Feb 9 15:46:55 2010 Tue Feb 9 15:46:55 2010 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Wed Feb 10 10:20:28 2010 Wed Feb 10 10:20:28 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Fri Feb 12 07:46:41 2010 Fri Feb 12 07:46:41 2010 Critical (3) Unicast Ranging Received Abort Response - initializing MAC;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Fri Feb 12 07:49:11 2010 Fri Feb 12 07:49:11 2010 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 15 07:18:04 2010 Mon Feb 15 07:18:04 2010 Error (4) DHCP RENEW sent - No response for IPv;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 15 11:28:02 2010 Mon Feb 15 11:44:59 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 15 17:02:54 2010 Mon Feb 15 17:02:54 2010 Error (4) DHCP RENEW sent - No response for IPv;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Time Not Established Fri Feb 19 10:11:42 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Sun Feb 21 07:06:05 2010 Mon Feb 22 05:28:53 2010 Error (4) DHCP RENEW sent - No response for IPv;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 22 05:29:36 2010 Mon Feb 22 05:29:36 2010 Notice (6) DHCP Renew - lease parameters time server-62.30.112.121;tftp file-P1ade0bb1ce9c91ad.cm modifie;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 22 15:23:19 2010 Mon Feb 22 17:01:12 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 22 20:50:11 2010 Mon Feb 22 20:50:11 2010 Critical (3) SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 22 21:07:18 2010 Mon Feb 22 21:07:18 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 22 21:08:20 2010 Mon Feb 22 21:08:20 2010 Critical (3) SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Feb 22 21:08:43 2010 Mon Feb 22 21:08:43 2010 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Time Not Established Sat Feb 27 18:22:43 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Sat Feb 27 21:19:55 2010 Mon Mar 1 01:58:22 2010 Error (4) DHCP RENEW sent - No response for IPv;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Mar 1 01:59:14 2010 Mon Mar 1 01:59:14 2010 Notice (6) DHCP Renew - lease parameters tftp file-Pcaa1a92007a50b13.cm modifie;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Tue Mar 2 19:54:40 2010 Tue Mar 2 19:54:40 2010 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Thu Mar 4 11:59:21 2010 Fri Mar 5 10:20:31 2010 Error (4) DHCP RENEW sent - No response for IPv;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Fri Mar 5 10:21:13 2010 Fri Mar 5 10:21:13 2010 Notice (6) DHCP Renew - lease parameters time server-62.30.112.121;tftp file-Pcaa1a92007a50b13.cm modifie;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Tue Mar 9 16:32:20 2010 Wed Mar 10 20:23:39 2010 Error (4) DHCP RENEW sent - No response for IPv;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Wed Mar 10 20:24:29 2010 Wed Mar 10 20:24:29 2010 Notice (6) DHCP Renew - lease parameters tftp file-Pcaa1a92007a50b13.cm modifie;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Sun Mar 14 08:55:57 2010 Mon Mar 15 07:58:23 2010 Error (4) DHCP RENEW sent - No response for IPv;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Mon Mar 15 07:59:06 2010 Mon Mar 15 07:59:06 2010 Notice (6) DHCP Renew - lease parameters time server-62.30.112.122;tftp file-Pcaa1a92007a50b13.cm modifie;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Fri Mar 19 11:57:47 2010 Sat Mar 20 15:13:00 2010 Error (4) DHCP RENEW sent - No response for IPv;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;
Sat Mar 20 15:13:50 2010 Sat Mar 20 15:13:50 2010 Notice (6) DHCP Renew - lease parameters tftp file-Pcaa1a92007a50b13.cm modifie;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VER=3.0;


When the problem happens my downloads drop to around the 5mb mark. all other times its a solid 50mb. the upload speed doesnt seem to be affected and always comes up at 1.6mbps on speedtests.

In regards to you saying the path ping shows that the pings just seem to be getting discarded, ive run a pathping when the line is running correctly and dont get any discards, ive included a screenshot demonstrating this. Is it possible that actual traffic is being discarded as well as pings when the line is running slowly?

Peter_
20-03-2010, 22:42
just because we are on different kit doesnt mean the problem cant be the same in action.
We get different faults that may look similar but cannot be identical due to it being a different manufacturer whose kit uses completely different software and scripts to work.

So you cannot claim identical faults.

Sephiroth
20-03-2010, 23:37
Your latest pathping means that it's not happening now. The event log suggests that when the T3 timeouts occur you'd see the degradation.

So on that basis, an upstream problem, like noise is likely.

I imagine VM have CMTS logs that might throw light on what happened around the times reported in your event log. It would need network analysis IMO.

Splitarra
22-03-2010, 14:06
I got a response from vm today following the network monitoring, they were monitoring from 20.30 friday for 24hours so that covers the time period i posted the bbc pathping with the packetloss. They have said that they saw no packetloss during this period and have said that it was being monitored constantly.

i just cant see how they're not able to see the packetloss as i can see it immediately if i ping my connection from work and its running slowly.

Ive sent through the pathping posted here for them to check as they requested and the next thing ill be doing is running more tracerts/pathpings from work back to home so that i can demonstrate the problem going from the other direction.
What ill also do is try running some tests from another vm connection to see if that reveals anything different compared to running it from outside the vm network.

---------- Post added at 14:06 ---------- Previous post was at 14:04 ----------

Your latest pathping means that it's not happening now. The event log suggests that when the T3 timeouts occur you'd see the degradation.

So on that basis, an upstream problem, like noise is likely.

I imagine VM have CMTS logs that might throw light on what happened around the times reported in your event log. It would need network analysis IMO.

Thanks for having a look at this.

I dont believe theres any direct correlation between the t3 timeouts and the drops in speed as the drops im getting are much more frequent than the timeouts and the times dont appear to match up at all

Splitarra
22-03-2010, 15:50
The line is currently running slow so here's the pathping/tracert from work to home, i censored the ip and hostname.

pinging this way indicates the problem to be somewhere between the 13 and last hop

Splitarra
22-03-2010, 16:57
lines still running slowly so i tried a tcpping to see what that would show, seems the dropped packets do generally come back but very very slowly

Splitarra
23-03-2010, 12:00
Ive had another update from vm today and they gave me the following update

Just had an update from Networks. They have advised me after you sent the results yesterday they tested the connection again for a few hours. They can see packet loss between the CMTS(Ubr) and your router but not between the CMTS and your modem. They have advised me this rules out the Virgin Media data network. They have also advised If you use ping plotter or MTR you might see some packet loss at first due to the ACL (access list on the CMTS uplinks) -- this would not impact normal data just ICMP.

im willing to try a new router, im willing to try anything really tho i dont think it will help as i do still get the same issue directly connected to the modem with a single pc (different network cable was used as well).

could it be a bad network port on the modem? although i am on my 3rd modem as well.

pip08456
23-03-2010, 12:51
Why don't you get back in touch with networks and arrange a period when you will just use direct to modem and they can monitor to rule out their suggestion it is the router at fault? May not work out but surely worth a try.

cook1984
24-03-2010, 15:40
I have had a similar issue for months. It tends to be worse when it rains, leading me to think that there is a leak somewhere.

Unfortunately it is virtually impossible for VM to diagnose this kind of thing. There just does not seem to be a procedure for it.

Posting to the newsgroup is the best option, but unfortunately the volume of traffic is now getting pretty high and the techs loose track of your case so end up asking for the same data over and over, even though you already posted it, and then suggesting the same thing over and over.

Splitarra
24-03-2010, 16:46
I'll be connecting a pc directly to the modem as pip08456 suggested this evening for vm to test. so we'll see what results they get from the ping responses off my pc.

the rain suggestion is interesting and i havent really taken any note of weather conditions when its slow. i dont think it is anything like rain but ill try to check next time its slow, i would have though i would get drops in the power level or snr if it was something like rain causing this?

i don't think posting this in the newsgroup forum would be of any benefit, im already dealing directly with the network engineers and the Chief Executive's Office.

One of the responses ive had virgin come back to me a number of times is that they're claiming i'm the only one that seems to be having this issue. If we can get people to keep reporting these issues they're having and get them raised to senior levels in virgin then maybe they might start to realise its more of a problem than they think right now.

if we can get similar results from virgins testing we may be able to get closer to an idea of where the problem is comming from.

Sephiroth
24-03-2010, 19:45
A rain phenomenon would cause SNR to fall. You would also see upstream power rise.

Splitarra
24-03-2010, 20:01
ok thanks, its not rain then as modem stats dont change at all from when its running ok and when it isnt