50M Think Broadband Ping Monitor Results (POST YOURS) - Page 313

Kushan · 19-11-2014, 09:05

The system is as solid as ever, it would seem.

roughbeast · 20-11-2014, 20:33

Quote:

Originally Posted by Sephiroth

I had the same TBB glitch but there was no reboot.

I suspect that Roughie didn't have a reboot either.

What kind of TBB glitch shows up like that?

There goes another?

Does the Superhub Log show us anything significant?

Super Hub
Sign In
Network Log

home
Router Status
Network Log

Network Log First Time Last Time Priority Error Number Description
20/11/2014 18:36:32 GMT 20/11/2014 18:36:32 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
20/11/2014 18:36:32 GMT 20/11/2014 18:36:32 GMT Critical (3) 82000700 Unicast Ranging Received Abort Response - initializing MAC
20/11/2014 18:36:31 GMT 20/11/2014 18:36:31 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
20/11/2014 18:36:31 GMT 20/11/2014 18:36:31 GMT Critical (3) 82000700 Unicast Ranging Received Abort Response - initializing MAC
20/11/2014 18:36:30 GMT 20/11/2014 18:36:30 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
20/11/2014 18:36:30 GMT 20/11/2014 18:36:30 GMT Critical (3) 82000700 Unicast Ranging Received Abort Response - initializing MAC
20/11/2014 18:36:29 GMT 20/11/2014 18:36:29 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
20/11/2014 18:36:29 GMT 20/11/2014 18:36:29 GMT Critical (3) 82000700 Unicast Ranging Received Abort Response - initializing MAC
20/11/2014 18:36:28 GMT 20/11/2014 18:36:28 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
20/11/2014 18:36:28 GMT 20/11/2014 18:36:28 GMT Critical (3) 82000700 Unicast Ranging Received Abort Response - initializing MAC
20/11/2014 18:36:27 GMT 20/11/2014 18:36:27 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
20/11/2014 18:36:27 GMT 20/11/2014 18:36:27 GMT Critical (3) 82000700 Unicast Ranging Received Abort Response - initializing MAC
20/11/2014 18:36:26 GMT 20/11/2014 18:36:26 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
20/11/2014 18:36:26 GMT 20/11/2014 18:36:26 GMT Critical (3) 82000700 Unicast Ranging Received Abort Response - initializing MAC
20/11/2014 18:36:25 GMT 20/11/2014 18:36:25 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
20/11/2014 18:36:25 GMT 20/11/2014 18:36:25 GMT Critical (3) 82000700 Unicast Ranging Received Abort Response - initializing MAC
20/11/2014 18:36:24 GMT 20/11/2014 18:36:24 GMT Warning (5) 85010200 TCS Partial Service
20/11/2014 18:36:24 GMT 20/11/2014 18:36:24 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
20/11/2014 18:36:24 GMT 20/11/2014 18:36:24 GMT Critical (3) 82000700 Unicast Ranging Received Abort Response - initializing MAC
20/11/2014 18:36:23 GMT 20/11/2014 18:36:23 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out

© 2010 Virgin Media. All rights reserved.

Sephiroth · 20-11-2014, 21:35

Roughie

Do always post the upstream/downstream levels when posting the network log.

In your case today, your TBB graph would seem to be unique to you and not a TBB glitch because, for example and unlike the previous time, I don't have the same "glitch" as you.

Anyway, you log shows a problem in the upstream - like you only have a partial upstream service. Hence the need to see the stats that fo with the network log.

qasdfdsaq · 20-11-2014, 23:57

Quote:

Originally Posted by roughbeast

What kind of TBB glitch shows up like that?

As stated above, glitches with routing between VM and TBB.

---------- Post added at 23:57 ---------- Previous post was at 23:56 ----------

Quote:

Originally Posted by Sephiroth

In your case today, your TBB graph would seem to be unique to you and not a TBB glitch because, for example and unlike the previous time, I don't have the same "glitch" as you..

Indeed, nor do most other people.

roughbeast · 21-11-2014, 08:06

Quote:

Originally Posted by Sephiroth

Roughie

Do always post the upstream/downstream levels when posting the network log.

In your case today, your TBB graph would seem to be unique to you and not a TBB glitch because, for example and unlike the previous time, I don't have the same "glitch" as you.

Anyway, you log shows a problem in the upstream - like you only have a partial upstream service. Hence the need to see the stats that fo with the network log.

Seph. It's so damn hard to present the copied stats from the SH2 GUI. I always duck the challenge. Is there an easy way of doing it? HTML doesn't seem to work here. Code tag doesn't help; not so far anyway.

Sephiroth · 21-11-2014, 09:30

The easy way of doing it, Roughie, is a simple copy & paste. If the formatting doesn't work out, no worries. The info will be there. Don't forget to repost the network log to keep everything contemporaneous.

Stats awaited!

roughbeast · 21-11-2014, 10:35

Quote:

Originally Posted by Sephiroth

The easy way of doing it, Roughie, is a simple copy & paste. If the formatting doesn't work out, no worries. The info will be there. Don't forget to repost the network log to keep everything contemporaneous.

Stats awaited!

Here goes. Hopefully this data is still relevant to the conditions existing at the time of the glitch.

Upstream US-1 US-2 US-3 US-4
Channel Type 2.0 N/A N/A 2.0
Channel ID 2 N/A N/A 1
Frequency (Hz) 39400000 N/A N/A 46200000
Ranging Status Aborted N/A N/A Success
Modulation 16QAM N/A N/A 16QAM
Symbol Rate (Sym/sec) 5120000 N/A N/A 5120000
Mini-Slot Size 4 N/A N/A 4
Power Level (dBmV) 41.00 N/A N/A 42.50
T1 Timeouts 0 0 0 0
T2 Timeouts 0 0 0 0
T3 Timeouts 13 0 0 0
T4 Timeouts 0 0 0 0

Downstream DS-1 DS-2 DS-3 DS-4 DS-5 DS-6 DS-7 DS-8
Frequency (Hz) 299000000 267000000 275000000 283000000 291000000 307000000 315000000 323000000
Lock Status(QAM Lock/FEC Sync/MPEG Lock) Locked Locked Locked Locked Locked Locked Locked Locked
Channel ID 109 105 106 107 108 110 111 112
Modulation 256QAM 256QAM 256QAM 256QAM 256QAM 256QAM 256QAM 256QAM
Symbol Rate (Msym/sec) 6.952000 6.952000 6.952000 6.952000 6.952000 6.952000 6.952000 6.952000
Interleave Depth I=12
J=17 I=12
J=17 I=12
J=17 I=12
J=17 I=12
J=17 I=12
J=17 I=12
J=17 I=12
J=17
Power Level (dBmV) 7.75 8.43 8.47 8.30 8.09 7.46 7.28 7.10
RxMER (dB) 39.40 39.40 39.40 39.40 39.85 39.85 39.85 39.40
Pre RS Errors 372 332 303 279 307 299 288 305
Post RS Errors 295 284 300 277 299 298 278 303

Ignitionnet · 21-11-2014, 15:09

Interesting.

Quote:

The largest cyber attack in history has been carried out against independent media sites in Hong Kong over the past few months, according to the company protecting them, increasing in their intensity each time pro-democracy activists announced new activities or developments.

That has prompted some ISPs like Virgin Media in the UK to play into the hands of the attackers by proactively blocking access to protect their own infrastructure, says Prince, something that he has never seen happen.

“It’s perverse because it means that even though the PopVote infrastructure and Cloudfare were able to defend the attack, there were still some ISPs around the world who were blocking access to the site.”

Through their network of infected personal computers and servers, the attackers have been sending a flood of spoof requests linked to the Hong Kong sites, forcing the ISPs to look up their IP addresses via the DNS global infrastructure. Overwhelmed with requests, ISPs like Virgin halted legitimate connections to the sites.

Sephiroth · 21-11-2014, 16:25

Quote:

Originally Posted by roughbeast

Here goes. Hopefully this data is still relevant to the conditions existing at the time of the glitch.

Upstream US-1 US-2 US-3 US-4
Channel Type 2.0 N/A N/A 2.0
Channel ID 2 N/A N/A 1
Frequency (Hz) 39400000 N/A N/A 46200000
Ranging Status Aborted N/A N/A Success
Modulation 16QAM N/A N/A 16QAM
Symbol Rate (Sym/sec) 5120000 N/A N/A 5120000
Mini-Slot Size 4 N/A N/A 4
Power Level (dBmV) 41.00 N/A N/A 42.50
T1 Timeouts 0 0 0 0
T2 Timeouts 0 0 0 0
T3 Timeouts 13 0 0 0
T4 Timeouts 0 0 0 0

<SNIP>

The upstream seems to have lost a channel (Aborted). This needs calling in or posting on the VM forum.

qasdfdsaq · 21-11-2014, 16:36

Or just turning it off and back on again.

Sephiroth · 21-11-2014, 17:12

Quote:

Originally Posted by qasdfdsaq

Or just turning it off and back on again.

Indeed. Though it is a SH2 so shouldn't need doing.

roughbeast · 21-11-2014, 22:25

Quote:

Originally Posted by qasdfdsaq

Or just turning it off and back on again.

What again? I've done quite a few manual reboots this last few weeks to restore my connection. Looks like a pattern.

---------- Post added at 22:25 ---------- Previous post was at 21:50 ----------

Quote:

Originally Posted by Sephiroth

The upstream seems to have lost a channel (Aborted). This needs calling in or posting on the VM forum.

I have posted the issue on the community forum.

http://community.virginmedia.com/t5/...t/td-p/2553969

qasdfdsaq · 22-11-2014, 01:14

Quote:

Originally Posted by roughbeast

What again? I've done quite a few manual reboots this last few weeks to restore my connection. Looks like a pattern.

Well one lost channel (upstream or downstream) at any random point isn't a huge issue and is fixed by a reboot. Permanently broken channels or repeated failures can indicate an underlying issue, but that particular symptom as a one-off doesn't really mean much.

roughbeast · 22-11-2014, 13:38

Quote:

Originally Posted by qasdfdsaq

Well one lost channel (upstream or downstream) at any random point isn't a huge issue and is fixed by a reboot. Permanently broken channels or repeated failures can indicate an underlying issue, but that particular symptom as a one-off doesn't really mean much.

Given the repeated need to reboot manually I am expecting there to be an underlying problem. I'll give a few days.

qasdfdsaq · 22-11-2014, 17:18

Possibly, but as you've only posted those stats once, it's impossible to say if that one-off issue is causing your repeated problems.