Quote:
Originally Posted by Sephiroth
[SEPH]: What are you on about? Where does my connection come into it, which happens to be post-RS error free?
|
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.
Quote:
|
[SEPH]: I'm well aware of applications that are intolerant of packet loss. IP Telephony is likely to be part of VM's future strategy and in addition to resilience measures at the cabinet and possibly within the modem, noise and hence dropped packets will be and thus are now a zero quantum aim.
|
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.
Quote:
|
The post-RS error count is the value under examination and available to VM for investigative purposes.
|
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.
Quote:
|
I merely state that the value during normal operations should be zero as it is on mine and on a fair number of those who post up their stats here.
|
You stated:
Quote:
Originally Posted by Sephiroth
There should be NO uncorrectable errors and it is service affecting even if you hardly notice it.
|
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.
Quote:
Originally Posted by Sephiroth
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.
|
Which is incorrect. UDP downloads are rare, and any application doing UDP downloads has built-in error detection and recovery.
Quote:
Originally Posted by Sephiroth
Post-RS errors cannot NOT be service affecting. Packets are corrupt and need to be retransmitted.
|
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.
Quote:
Originally Posted by Sephiroth
Thank you for the red blob. That was quite nasty.
|
What on earth are you on about now.
---------- Post added at 12:25 ---------- Previous post was at 12:12 ----------
Quote:
Originally Posted by Eeeps
... but the design uses retransmission rather that FEC so service is impacted (to some degree).
|
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.
Join CF
You are here: 
