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.