Didn't find what you were looking for?


We have advanced search options to make it easier to locate posts, questions and answers on this community.
More information can be found at Advanced Search Options
If you are looking for something specific, please check if someone else has already asked or answered the same question.

High-Split SNR/Node Health | My attempt at tracking packet loss real-time

wtaylor
wtaylor Posts: 3 Spectator
edited February 27 in Connectivity

High-split/Symmetrical services were offered in my area around October 2024. Upload speed and packet loss out are an issue. A maintenance (wyfy4?) request has been ordered for the node in my area - this script is my attempt to have feedback on when the maintenance has been completed. (this would mean zero discord notifications in default config).

https://github.com/sir-wallaby/lossLess-Liaison/tree/lll-dev

image.png
Tagged:

Comments

  • HT_Greenfield
    HT_Greenfield Posts: 967 Contributor

    Auto-run scripting aside, for what little if anything it may be worth:

    1. Which nominal throughput tier are you on and what kind upload throughput are you measuring?
    2. Ping test packet "loss" is not exclusively reflective of "upload" performance.
    3. What kind ping test packet "loss" do you experience for any specified target(s) that are contiguously upon any Spectrum carriage route(s) that are important to your workflow?
    4. What kind of ping test packet "loss" do you experience for any specified targets that are end-point hosts that are important for your workflow, and what carrier network are they on or do they go through beyond Spectrum?
    5. About the only thing that such of a modest amount of ping test packet "loss" would mean for actual QoS data would be a similarly modest amount of retransmissions, if even that, and, the greater the throughput, the less consequential should such retransmissions be. (With DOCSIS 3.1, such would practically be a fact of life as far as i'm concerned but that's just me. I'm an unfrozen caveman.)
  • wtaylor
    wtaylor Posts: 3 Spectator
    edited February 24

    Within #5, would you say when sending 100 packets, one to three of those packets is dropped. Multiple times, sometimes per hour is a 'fact of life'?

    This testing is all hobby driven (programming/gaming).

  • HT_Greenfield
    HT_Greenfield Posts: 967 Contributor

    To be clear, i compliment you for what sounds like a worthy endeavor. By "for what little if anything it may be worth:", i was referring to the curiosities and comments that i followed with.

    Pardon my wishful thinking: Pushing the forward error correction envelope harder than ever is literally a part of the equation in achieving the immense spectral density and astronomical speed of DOCSIS 3.1 and i would hope that lost or dropped QoS data packets would be retransmitted with exceptionally low net delay and i wouldn't worry about such of a modest amount of such retransmissions unless i had reason to believe it was disaffecting my workflow.

    But that wasn't the most important of my points, because it has only to do with DOCSIS PHY. It was my bad for commenting on an outstanding maintenance request situation in the first place! It won't happen again. ☘️

Categories