Re: Post RS Errors
 

When/if they send you another tech, then the tap change can be made. Important to get all this in your file notes. Ask the Forum Team member to do that.

Re: Post RS Errors
 

Ok, thanks. I presume when the tech was last out, he just moved it on the current tap point, rather than moving to another? The forum team member is waiting to hear back from an email she has sent to the tech who last came out, for an update. If she doesn't hear anything then she's going to arrange for a new Superhub to be sent out tomorrow. I don't know if it'll help though. Had a couple of dropouts overnight.

http://www.thinkbroadband.com/ping/s...23-04-2015.png

23/04/2015 03:25:19 GMT 23/04/2015 03:25:19 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 03:25:19 GMT 23/04/2015 03:25:19 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 03:25:19 GMT 23/04/2015 03:25:19 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 03:25:19 GMT 23/04/2015 03:25:19 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 03:25:19 GMT 23/04/2015 03:25:19 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 03:25:19 GMT 23/04/2015 03:25:19 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 03:25:19 GMT 23/04/2015 03:25:19 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 03:25:18 GMT 23/04/2015 03:25:18 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 03:25:14 GMT 23/04/2015 03:25:14 GMT Critical (3) 84000500 SYNC Timing Synchronization failure - Loss of Sync
23/04/2015 03:25:13 GMT 23/04/2015 03:25:13 GMT Critical (3) 84000500 SYNC Timing Synchronization failure - Loss of Sync
23/04/2015 02:09:01 GMT 23/04/2015 02:09:01 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 02:09:01 GMT 23/04/2015 02:09:01 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 02:09:01 GMT 23/04/2015 02:09:01 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 02:09:01 GMT 23/04/2015 02:09:01 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 02:09:01 GMT 23/04/2015 02:09:01 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 02:09:01 GMT 23/04/2015 02:09:01 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 02:09:01 GMT 23/04/2015 02:09:01 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 02:09:01 GMT 23/04/2015 02:09:01 GMT Warning (5) 84020200 Lost MDD Timeout
23/04/2015 02:08:57 GMT 23/04/2015 02:08:57 GMT Critical (3) 84000500 SYNC Timing Synchronization failure - Loss of Sync
23/04/2015 02:08:57 GMT 23/04/2015 02:08:57 GMT Critical (3) 84000500 SYNC Timing Synchronization failure - Loss of Sync

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 13 9 10 11 12 14 15 16
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) 0.95 0.06 0.21 0.49 0.63 1.12 1.19 1.26
RxMER (dB) 36.17 35.97 35.97 36.17 36.61 36.61 36.84 36.61
Pre RS Errors 414754 367639 374310 347346 441633 435656 438585 466876
Post RS Errors 206202 161448 169767 159677 249880 246223 252402 280655

Re: Post RS Errors
 

Been a change of plan, it's been arranged for a Principal Technician to come on Tuesday. So without telling him how to do his job, would it be right for him to consider:

1. Moving to a different tap point
2. Check the condition of the coax cable and consider a repull if necessary
3. Maybe change the Superhub

Re: Post RS Errors
 

Is this fault service affecting?

Re: Post RS Errors
 

Well see that's the thing, I always seem to get full speed. Its not like I'm pushing for something to be done, the forum team member sent me a PM on Wednesday asking how things had been. I replied back that the SNR seemed to be ok but I was still getting the post rs errors. She sent an email to who she thought was the engineer who attended to get an update (turns out it was someone else), and they replied back, saying to book an engineer again. I'm just going along with what they are saying.

Re: Post RS Errors
 

The PT is fully competent at judging (and doing) what needs to be done including everything on your list.

Quite simply, Post-RS errors are bad - they should not occur. One can't rule out a dudgy Superhub and it'll prolly be the first thing the PT may try.

Re: Post RS Errors
 

PT has been, really pleasant bloke. He's swapped out the Superhub for another. Did also say that it could be that the coax cable is damaged but he didn't check it. I'll have to see if I get anymore errors, hopefully not.

Re: Post RS Errors
 

Still getting these errors despite the new Shub. Latest response via PM seems to suggest that as long as the connection stays up, then everything is fine.


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 13 9 10 11 12 14 15 16
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) 1.87 1.69 1.77 1.83 1.67 2.19 2.40 2.52
RxMER (dB) 36.61 36.61 36.39 36.61 36.84 36.84 36.84 36.84
Pre RS Errors 63628 27770 57325 20737 56711 63468 64958 69245
Post RS Errors 35396 10986 29775 10011 34528 42150 43650 47964

Upstream
US-1 US-2 US-3 US-4
Channel Type 2.0 N/A N/A 2.0
Channel ID 50 N/A N/A 51
Frequency (Hz) 39400000 N/A N/A 32600000
Ranging Status Success Other Other 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) 47.25 N/A N/A 47.25
T1 Timeouts 0 0 0 0
T2 Timeouts 0 0 0 0
T3 Timeouts 2 0 0 1
T4 Timeouts 0 0 0 0

Most of those seem to of racked up overnight. I'm quite tempted to go down the CEO route even though I shouldn't really need to.

Re: Post RS Errors
 

There should be NO post-RS errors during normal operation. At your RxMER (SNR) level, I'd expect correctable errors. There should be NO uncorrectable errors and it is service affecting even if you hardly notice it.

Thing to find out is if your neighbours have the same.

VM's job is to get the noise out of the segment and I wouldn't find their answer satisfactory. It's a fob-off.

Re: Post RS Errors
 

Yep, definitely seems like a fob off. Latest response just seems to have defaulted to the "Your connection works, what do you expect us to do?" answer. Hence, why I'm reluctantly thinking of going down the CEO route. Unless there's anything/anyone I can contact in between?

Re: Post RS Errors
 

I'll tell you where it's service affecting.

I you do any UDP downloads (you can Google UDP if necessary), there is no retransmission of corrupted packets unless your end (application has software to detect this. When you try to unpack such downloads, a CRC error occurs and the data is useless.

Zero post-RS (except for the boot up moments) is the only acceptable level.

Re: Post RS Errors
 

To be honest, I don't know if I do do any UDP downloads. Googled it, still not sure.

Re: Post RS Errors
 

I would disagree. Consumer products are neither designed nor expected to be 100% reliable. You could say there should be NO dropped calls or cut-outs during normal operation of a mobile network but nobody returns a phone because it drops one or two calls every year.

---------- Post added at 11:19 ---------- Previous post was at 11:18 ----------

You don't. Nobody does. UDP is not used for downloading.*

* It's sometimes used for torrents but that has it's own error checking and retransmission anyway.

---------- Post added at 11:20 ---------- Previous post was at 11:19 ----------

I challenge you to find *any* internet service in the world that has zero packet loss at any time.

Re: Post RS Errors
 

I can't see the point in all of this. It works. If I had 10 billion errors I couldn't care as long as my service works

Re: Post RS Errors
 

Downlads no, but I'd be interested in knowing how real time services like VoIP and Gaming are. Those are where you're going to see major issues.

Completely agree with everything else though - nothing is ever guaranteed to be 100% reliable, TCP itself was built around the principle that it's not reliable.

Re: Post RS Errors
 

Agree that there should be no post errors, if you have post errors the Forward Errors Control,(FEC) cannot correct the errors and depending on how bad it is will determine as to what level of disruption will occur to your picture or Broadband service.

I also agree that most networks will have a small amount of errors but VM do have a spec at the cab that shouldn't be exceeded

Re: Post RS Errors
 

Would this affect streaming from Netflix? I usually get the picture going pixelated once or twice for a few seconds, regardless of what I'm watching. I assumed it was something to do with Netflix but perhaps not.

I also notice that I'm getting a few T3 timeouts recently and that the upstream power is slowly climbing up.

Re: Post RS Errors
 

For UDP, you'll get missing packets so anything "Realtime" will go missing.

For TCP (which I think is what Netflix will use?), you'll see lower speeds as TCP retransmits until it goes through. For netflix, that could cause a drop in picture quality as netflix is fairly dynamic.

Re: Post RS Errors
 

I have noticed that too, although it doesn't happen too often. Sometimes it'll just drop the quality down to 240 and then reasonably quickly, work its way back up to 1080.

Re: Post RS Errors
 

This can happen for hundreds of different reasons.

You need to stop speculating and post a TBB graph to determine if it's service affecting or not.

Re: Post RS Errors
 

Post-RS errors cannot NOT be service affecting. Packets are corrupt and need to be retransmitted. There should be no post-RS errors.

As Qasi says, corrupting noise can happen for multiple reasons. If it's not your modem and especially if your neighbours sow the same phenomenon, it has to be fixed by VM.

Re: Post RS Errors
 

https://www.cableforum.co.uk/images/local/2015/08/3.png

Live graph. Doesn't really show anything out of the ordinary (ignore the spike just before 2pm, that was just a quick reboot of the router).

Re: Post RS Errors
 

That's like saying low signal on my phone cannot NOT be service affecting. There should always be 100% signal.

Not going to happen.

The internet is designed around the fact corrupt packets happen and is designed to deal with it.

A service is not affected if it works as intended. A connection that is not designed to be 100% reliable being not 100% reliable does not mean it's incapable of working as intended.

---------- Post added at 17:59 ---------- Previous post was at 17:58 ----------

You seem to have quite a spike around 5:30pm. That level of packet loss is enough to cause minor to moderate connection issues.

The timing suggests the interference is from someone turning on some equipment after getting home from work.

Re: Post RS Errors
 

Not at home to check at the moment but that amount of packet loss is something new. Don't usually see that much on the graph. Appears to of stopped anyway.

Re: Post RS Errors
 

You're nit picking again.

Re: Post RS Errors
 

Too loose a statement. 100% of what?

I'm nitpicking?! Your entire participation in this thread has been nothing but nitpicking.

You're arguing about un-noticeably minute amounts of loss on somebody else's connection while your own connection is suffering far more corruption. Shouldn't you be off complaining to VM about your "unacceptable" levels of packet loss which "must" be "service affecting" because it's ten times higher than Jon22's?

Here's a few articles you might want to read in order to get clued up on the sort of applications that really cannot tolerate any packet loss:

http://www.fragmentationneeded.net/2...own-is-up.html
http://etherealmind.com/myth-fibrech...er-token-ring/
http://packetpushers.net/dont-drop-t...rust-ethernet/

---------- Post added at 22:58 ---------- Previous post was at 22:48 ----------

That level of packet loss is the kind that would start affecting your service. The remaining 23 hours or so of your chart looks perfectly fine, and shows a normal error rate that is completely non-service-affecting.

Any slowness or issues you notice with Netflix - unless during periods of high packet loss like between 5:30 and 6:15pm above - are due to something unrelated, e.g. congestion, and not receive errors.

Re: Post RS Errors
 

Thank you for the red blob. That was quite nasty.

Re: Post RS Errors
 

... but the design uses retransmission rather that FEC so service is impacted (to some degree).

Re: Post RS Errors
 

I have a .NET application that may help diagnose this.

It reads the HTML downstream and upstream stats pages from the SH and logs the details to a CSV file every second along with the time stamp.

Currently it is designed for SH2 web pages but may work with the AC version.

PM me if you'd like a copy.

Ian

Re: Post RS Errors
 

Your entire case has been about arguing post-RS errors cause corrupt or loss packets. Your connection has more corrupt or loss packets yet you claim I'm nitpicking.

You're pointing to his post-RS error counter as an indication of detrimental service yet deem your own connection acceptable because you do not have access to the error counter on your connection. Yet the actual effect and actual service is worse on your line, regardless of cause.

As been stated before telephony over the cable network will use different protocols, different modulation, and different channels. Even assuming they are not already less susceptible to errors, the level of corruption or loss on the OP's line is sufficient to cause 0.25 seconds of garbled audio during a 1-hour phone call.

We've already determined the post-RS error count is immaterial and has no effect on his service. Your constant reference to an irrelevant statistic, simply because you can see it, is pretty much the definition of nitpicking.

I can guarantee you get more "post-RS errors" every second reading from your hard drive but you don't claim it's faulty because you probably don't have access to the numbers.

You stated:
Which is incorrect. An issue is service affecting if it affects the purpose of a service. The purpose of a broadband service is to deliver IP data correctly and in reasonable time. In this respect, his connection is functioning better than yours. If I were to take your narrow-minded view, I'd argue zero post-RS errors is service affecting, because your line with zero post-RS errors is worse at delivering IP data correctly than his.

Which is incorrect. UDP downloads are rare, and any application doing UDP downloads has built-in error detection and recovery.

Which is incorrect. The point of the service is not to maintain an arbitrary error counter at zero at all times. The point of the service is to deliver IP data. His connection delivers IP data within the expected and accepted level of reliability.

Again, your own connection delivers IP data with a lower level of reliability and more packet loss. If you think his 0.007% packet loss is "service affecting" you should be investigating where the 0.05% packet loss on your line is coming from. If you think your own connection is "fine" then you ought to stop nitpicking by pointing to a counter that is having no effect on his service.

What on earth are you on about now.

---------- Post added at 12:25 ---------- Previous post was at 12:12 ----------

Careful, before Seph accuses you of nitpicking.

While it is correct a retransmission might mean the service is only operating at 99.993% efficiency instead of 100%, the service was not designed to offer 100% reliability at all times. The use of TCP in the first place, and not having 100% perfectly tuned parameters for each and every server you ever connect to has a far bigger impact than 0.007% of packets being retransmitted.

Simply put, it is operating within normal parameters.

P.S. The second article I linked above lists plenty of places in addition to the CPE where errors can occur:

the software driver
the network adapter
the ingress buffer on the network switch port
the egress buffer on the network switch port
the module or silicon handling the switch port
the backplane or module interconnect of the fibrechannel switch
the module or silicon handling the switch port
the egress buffer on the network switch port
the ingress buffer on the network switch port
the available bandwidth of the interconnect between switch
and so until it arrives at the storage array
the egress buffer on the network switch port
the ingress buffer on the storage switch

While specific to FC networks, the same applies on Ethernet. Simply because one has access to the post-RS counters on a cable modem does not make it any more significant a source of uncorrectable errors than any of the above that you can't see the counters for. Ultimately the end-to-end IP packet delivery is what matters.

Re: Post RS Errors
 

Apologies for raising this thread but having more issues again. Since Thursday, I've noticed that the upstream power has risen from 47dBmv to 54dBmv. I also noticed that one of the downstream channels wasn't locked on Friday night. A quick reboot sorted that but I've had a look again this morning and once again, the same downstream channel is not locked. So ignoring the Post RS errors, anyone care to speculate what could be causing the two issues? I know I could have a technician out to move the coax on the tap point, to bring the upstream down, but surely that's just masking whatever the problem is? They did that before.

DS-1 DS-2 DS-3 DS-4 DS-5 DS-6 DS-7 DS-8
Frequency (Hz) 299000000 267000000 275000000 283000000 N/A 307000000 315000000 323000000
Lock Status(QAM Lock/FEC Sync/MPEG Lock) Locked Locked Locked Locked Unlocked Locked Locked Locked
Channel ID 13 9 10 11 N/A 14 15 16
Modulation 256QAM 256QAM 256QAM 256QAM Unknown 256QAM 256QAM 256QAM
Symbol Rate (Msym/sec) 6.952000 6.952000 6.952000 6.952000 N/A 6.952000 6.952000 6.952000
Interleave Depth I=12
J=17 I=12
J=17 I=12
J=17 I=12
J=17 N/A I=12
J=17 I=12
J=17 I=12
J=17
Power Level (dBmV) 0.49 -0.35 -0.21 0.11 N/A 0.78 0.76 0.81
RxMER (dB) 36.17 35.97 35.97 36.17 N/A 36.61 36.39 36.17
Pre RS Errors 103292 46755 79057 48506 N/A 101166 103705 104660
Post RS Errors 80076 31024 54188 35974 N/A 83174 85617 86248

US-1 US-2 US-3 US-4
Channel Type 2.0 N/A N/A 2.0
Channel ID 50 N/A N/A 51
Frequency (Hz) 39400000 N/A N/A 32600000
Ranging Status Success Other Other 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) 53.75 N/A N/A 54.00
T1 Timeouts 0 0 0 0
T2 Timeouts 0 0 0 0
T3 Timeouts 0 0 0 3
T4 Timeouts 0 0 0 0

Network Log
First Time Last Time Priority Error Number Description
19/07/2015 08:26:16 GMT 19/07/2015 08:26:16 GMT Warning (5) 84020200 Lost MDD Timeout
19/07/2015 07:54:23 GMT 19/07/2015 07:54:23 GMT Warning (5) 84020200 Lost MDD Timeout
19/07/2015 07:54:20 GMT 19/07/2015 07:54:20 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
19/07/2015 07:54:18 GMT 19/07/2015 07:54:18 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
19/07/2015 07:54:16 GMT 19/07/2015 07:54:16 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out

Re: Post RS Errors
 

you defo need someone out either way with all those post rs errors. If the problem isn't local (i.e your end) then it will get escalated to networks for fixing.

Re: Post RS Errors
 

Whilst I agree, there just not interested in the errors. Had 4 visits ranging from adjusting levels to replacing the SH. Admittedly they did get networks to improve the downstream SNR. Not one of these visits has sorted the errors out though. The only thing that hasn't been changed is the coax cable.

Re: Post RS Errors
 

The T3 timeouts are indicative of a possible network fault and if you have had 4 visits then it should have been escalated. I would do the following in this order:

1) Ring up tech support (hopefully not India), explain the problem and ask for the principle technician to come out
2) If they refuse put the phone down, ring back go through to retentions and make a complaint. I am sure they will arrange for the principle tech to come out
3) In the unlikely event that doesn't work, make a complaint with the CEOs office (tom.mockridge@virginmedia.co.uk) and they will DEFINITELY get the principle tech out to sort it out and it will be followed through to resolution. I have dealt with the CEOs office before when I got screwed big time and they kicked ass and got it fixed.

Re: Post RS Errors
 

In addition to the General's advice, it is worth checking with VM supplied neighbours. If they have a similar problem, then you're likely looking at a cooked component in the street cabinet - something like that.

Re: Post RS Errors
 

Do VM not have the capability to do this remotely? As in looking at who is connected to a particular cabinet and then checking there stats? I'm probably sounding stubborn but I don't particularly fancy knocking on people's doors asking if I can check their stats :p:

Re: Post RS Errors
 

they sure do and that is what networks will do if/when the fault gets escalated to them. Septh was suggesting it as more of by-the-by in conversation with your neighbours just so you have got more evidence to back you up. I live in a cul de sac and am quite chummy with all my neighbours and wouldn't think anything of asking them if they have all got probs with their connection. That way when the tech comes out and they say "we'll swap the shub again and see if that helps" you can say "it won't help because I know everyone else in the street has got the same problem". On the two times I have had an area fault in the last 16 years it was fixed in 4 hours once it was escalated.

Re: Post RS Errors
 

As per what the Genral says. But it will be yonks before VM get round to doing that. You want it fixed quickly? Help with the diagnostics. Ask people you know how their BB is doing.

Re: Post RS Errors
 

Do the analogue amps have remote monitoring and tell back? I very much doubt it.

Maybe VM can infer a problem location by using statistical analysis from a number of CPE but I'd bet that the coaxial cable network doesn't have monitoring down to the cab level.

Re: Post RS Errors
 

VM do have remote monitoring in place for 2nd line once it's escalated as before then there's too much to monitor.

Don't know if 1st line have access though.

Re: Post RS Errors
 

First line have access to some reporting tools, but very little "realtime" data.

Re: Post RS Errors
 

I thought as much.

Re: Post RS Errors
 

I don't see how they can remote to a passive component. So I don't think they can remote to a street cabinet unless it has an optical node. They can all remote to several modems in a street - which are not passive devices.

I also thought that STORM, established some 5 years ago whereby hourly stats are grabbed from active modems would provide information of the sort needed.

Re: Post RS Errors
 

I knew that some sort of monitoring was in place but wasn't sure what.

Nevertheless that is a huge amount of data to wade through unless escalated to 2nd line who will then take a look.

Perhaps Igni could enlighten us further.

Re: Post RS Errors
 

The "huge amount of data" was precisely why they did STORM. The back end processing was supposed to show where problems were developing .

Re: Post RS Errors
 

The operative word being "supposed".

Re: Post RS Errors
 

Plenty of ways to remotely monitor passive components. How do you think fibre engineers locate a break in a passive cable dozens of miles out to sea?

Re: Post RS Errors
 

I didn't say remotely monitor. I said "remote to".

Re: Post RS Errors
 

Talk about pointless pedantism. You were replying to a post that clearly stated "remotely monitor", and you don't "remote to" an optical node either, that's just nonsense.

Eeeps was talking about remote monitoring
pip08456 was talking about remote monitoring
You said "remote to" but clearly meant remote monitoring. Or perhaps you've sunken to the point you'd rather claim your statement was nonsense than to be wrong?

Re: Post RS Errors
 

Sent an email to the CEO office last night and I've spoken to the person who has been appointed to look after the complaint. Another technician coming on Wednesday. Hopefully get this sorted now.

Re: Post RS Errors
 

Why don't you just go away. Always nitpicking on me. I know exactly what I meant - the ability to log onto an active device or read a MIB.

Re: Post RS Errors
 

Says the person constantly with the false accusations of nitpicking. Oh the hypocrisy.

Re: Post RS Errors
 

Grrr, why does this always happen just before a technician is about to come. Looks as though there was a brief outage around 7:30pm (was out at the time) according to the TBB graph.

https://www.cableforum.co.uk/images/local/2015/08/3.png

Upstream power levels have now significantly reduced from the 54dBmv they were.

US-1 US-2 US-3 US-4
Channel Type 2.0 N/A N/A 2.0
Channel ID 50 N/A N/A 51
Frequency (Hz) 39400000 N/A N/A 32600000
Ranging Status Success 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) 40.71 N/A N/A 40.25
T1 Timeouts 0 0 0 0
T2 Timeouts 0 0 0 0
T3 Timeouts 1 0 0 0
T4 Timeouts 0 0 0 0

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 13 9 10 11 12 14 15 16
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) 0.35 -0.20 -0.00 0.19 0.18 0.61 0.66 0.67
RxMER (dB) 36.39 36.39 36.17 36.39 36.84 36.84 36.84 36.39
Pre RS Errors 792 1287 694 472 617 364 477 504
Post RS Errors 359 695 211 79 265 68 193 193

Network Log
First Time Last Time Priority Error Number Description
21/07/2015 18:32:12 GMT 21/07/2015 18:32:12 GMT Error (4) 68000407 TOD established
21/07/2015 18:31:58 GMT 21/07/2015 18:31:58 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
21/07/2015 18:31:50 GMT 21/07/2015 18:31:50 GMT Notice (6) 84000510 Downstream Locked Successfully
21/07/2015 18:31:45 GMT 21/07/2015 18:31:45 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
21/07/2015 18:31:43 GMT 21/07/2015 18:31:43 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
21/07/2015 18:31:43 GMT 21/07/2015 18:31:43 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
21/07/2015 18:31:41 GMT 21/07/2015 18:31:41 GMT Critical (3) 82000600 Unicast Maintenance Ranging attempted - No response - Retries exhausted
21/07/2015 18:31:41 GMT 21/07/2015 18:31:41 GMT Critical (3) 82000300 Ranging Request Retries exhausted
21/07/2015 18:31:41 GMT 21/07/2015 18:31:41 GMT Critical (3) 82000600 Unicast Maintenance Ranging attempted - No response - Retries exhausted
21/07/2015 18:31:41 GMT 21/07/2015 18:31:41 GMT Critical (3) 82000300 Ranging Request Retries exhausted
21/07/2015 18:31:39 GMT 21/07/2015 18:31:39 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
21/07/2015 18:31:39 GMT 21/07/2015 18:31:39 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
21/07/2015 18:31:37 GMT 21/07/2015 18:31:37 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
21/07/2015 18:31:37 GMT 21/07/2015 18:31:37 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
21/07/2015 18:31:35 GMT 21/07/2015 18:31:35 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
21/07/2015 18:31:34 GMT 21/07/2015 18:31:34 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
21/07/2015 18:31:33 GMT 21/07/2015 18:31:33 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
21/07/2015 18:31:32 GMT 21/07/2015 18:31:32 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
21/07/2015 18:31:31 GMT 21/07/2015 18:31:31 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
21/07/2015 18:31:30 GMT 21/07/2015 18:31:30 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out

Now whether getting the CEO office on to the case has kicked networks butts into fixing it or whether its coincidental, I don't know. Have to see what the technician can find out tomorrow.

Edit: Looking at the My Virgin Media page, the technician appointment looks as though its been cancelled, as its no longer showing. I'm going to have to ring the CEO office tomorrow to find out whats going on.

Re: Post RS Errors
 

From the BQM, there seems to be a low level of constant noise. These are the red bits at the top which denote lost packets on the BQM round trip. If that noise was on the upstream, it could account for the T3 events and eventually the reboot.

The snapshot log you provided shows nothing alarming. If the BQM has stopped showing red at the top then whatever it was might have been cured.

I hope so.

Re: Post RS Errors
 

yup, I bet the tech comes out tomorrow and it is a courtesy visit. He'll know they have fixed it and is coming out to kiss some ass and make sure everything is ok.

Edit: just red your modified post. Tech visits are cancelled when the fault is logged as being fixed so as far as VM are concerned it is fixed (which is certainly looks like from your power levels)

Re: Post RS Errors
 

Hmmm, rebooted the SH yesterday and I've had no Post RS errors until now. Stats are all good and it doesn't appear to be noticeably affecting the connection, so do I just ignore it or carry on chasing up the complaint?

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 13 9 10 11 12 14 15 16
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) 0.40 -0.28 -0.17 0.19 0.24 0.62 0.64 0.70
RxMER (dB) 36.39 36.39 36.17 36.17 36.84 36.84 36.84 36.61
Pre RS Errors 10286 8331 11756 7344 7207 6960 6939 7343
Post RS Errors 4180 940 4409 3347 4250 4286 4297 4788

US-1 US-2 US-3 US-4
Channel Type 2.0 N/A N/A 2.0
Channel ID 50 N/A N/A 51
Frequency (Hz) 39400000 N/A N/A 32600000
Ranging Status Success Other Other 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) 40.50 N/A N/A 40.00
T1 Timeouts 0 0 0 0
T2 Timeouts 0 0 0 0
T3 Timeouts 0 0 0 0
T4 Timeouts 0 0 0 0

Re: Post RS Errors
 

If the post-RS errors are rising in normal use, then you have a fault, imo.

Re: Post RS Errors
 

Spoken to the person looking after the complaint and he's told me that some hardware was replaced in the cabinet. Presumably the amp? I did mention that there was still some Post-RS errors occurring but he couldn't see any issues from their end. So as far as they are concerned, its fixed.

Re: Post RS Errors
 

But are they rising in normal operation?

Re: Post RS Errors
 

if it ain't broken don't fix it

Re: Post RS Errors
 

They seem to come in a burst whether the connection is idle or in use.

Re: Post RS Errors
 

It means, imo, that there is occasional noise somewhere on the downstream if those errors are increasing without a reboot having occurred.

Re: Post RS Errors
 

However, that can be normal and not necessarily impactful.

Re: Post RS Errors
 

I disagree, though I know what you mean. There should be NO lost data packets at the CPE.

Re: Post RS Errors
 

You are correct, there should be but in the real world, it does sometimes happen. How often it happens is what really matters.

Or rather, whether your service is being affected in a noticeable way is what matters.

Re: Post RS Errors
 

*Sigh* Guess one of the upstream channels is borked now :rolleyes:

Re: Post RS Errors
 

Restart of Shub sorted it. No idea why it dropped one of the upstreams.

Re: Post RS Errors
 

have any of them switched to qam64?

Re: Post RS Errors
 

Not yet, got a feeling that could be a while away. Getting T3 timeouts and Lost MDD Timeout in the network log.

Network Log
First Time Last Time Priority Error Number Description
05/08/2015 22:40:18 GMT 05/08/2015 22:40:18 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
05/08/2015 22:01:58 GMT 05/08/2015 22:01:58 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
05/08/2015 06:18:42 GMT 05/08/2015 06:18:42 GMT Warning (5) 84020200 Lost MDD Timeout
05/08/2015 06:18:42 GMT 05/08/2015 06:18:42 GMT Warning (5) 84020200 Lost MDD Timeout
05/08/2015 06:18:42 GMT 05/08/2015 06:18:42 GMT Warning (5) 84020200 Lost MDD Timeout
05/08/2015 06:18:42 GMT 05/08/2015 06:18:42 GMT Warning (5) 84020200 Lost MDD Timeout
05/08/2015 06:18:42 GMT 05/08/2015 06:18:42 GMT Warning (5) 84020200 Lost MDD Timeout
05/08/2015 06:18:41 GMT 05/08/2015 06:18:41 GMT Warning (5) 84020200 Lost MDD Timeout
05/08/2015 06:18:41 GMT 05/08/2015 06:18:41 GMT Warning (5) 84020200 Lost MDD Timeout
05/08/2015 06:18:40 GMT 05/08/2015 06:18:40 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
05/08/2015 06:18:36 GMT 05/08/2015 06:18:36 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
04/08/2015 23:35:34 GMT 04/08/2015 23:35:34 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
04/08/2015 23:35:33 GMT 04/08/2015 23:35:33 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
04/08/2015 23:35:31 GMT 04/08/2015 23:35:31 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
04/08/2015 23:35:30 GMT 04/08/2015 23:35:30 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
04/08/2015 23:35:29 GMT 04/08/2015 23:35:29 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
04/08/2015 23:35:28 GMT 04/08/2015 23:35:28 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
04/08/2015 23:35:27 GMT 04/08/2015 23:35:27 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
04/08/2015 23:35:23 GMT 04/08/2015 23:35:23 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out
04/08/2015 23:35:23 GMT 04/08/2015 23:35:23 GMT Critical (3) 82000200 No Ranging Response received - T3 time-out

Re: Post RS Errors
 

And broken:

https://www.cableforum.co.uk/images/local/2015/08/3.png

Area fault, hopefully whatever was causing the timeouts and errors will be fixed.

Re: Post RS Errors
 

Looks like it was fixed just before 8pm.

Re: Post RS Errors
 

Yep and hopefully I'm not saying it too early but I reset the counters when I got back from work last night, been no Post-RS errors at all since.

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 13 9 10 11 12 14 15 16
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) -0.11 -0.71 -0.49 -0.23 -0.24 0.08 0.08 0.08
RxMER (dB) 36.17 35.97 35.60 35.97 36.39 36.17 36.17 36.17
Pre RS Errors 3449 4924 4222 1283 8 4 6 7
Post RS Errors 0 0 0 0 0 0 0 0

Re: Post RS Errors
 

No Post-RS errors at all since Friday, so looks as though its been fixed, finally.