RichardDavies wrote: > Could you please try to explain this a little more clearly? I'm not > completely following your explanation of the various numbers. I assume > that based on your explanation, "Ping 2s3q6f" indicates that it's > pinging every 2 seconds and doing a quick reset after 3 failed pings and > a full reset after 6 failed pings. But I get lost on the 10 array > digits. What's the difference between array indexes 0-7 if they're all > counts of failed pings? When does a failed ping increment index 0 vs 1 > vs 2, etc? What event(s) triggers each index to reset (if they do > reset)?
Array indexes [0..7] are all counts of failed pings coming before a successful ping. So, if a ping succeeded, then failed 2 times before a success, that success would increment the [2] index, which counts the number of times the ping test failed 2 times before succeeding. This roughly counts how long connectivity was lost. If all the pings worked perfectly, then there would be zero failed pings, so the [0] index would increment on each successful ping test. Index [6] is a count of how many times the ping test failed before it finally succeeded, and did not trigger the full reset. Since in this case the quick reset was done after 3 failed pings, that means that 3 ping tests after the quick reset, the ping succeeded, just in the nick of time to avoid the full reset. If the ping had not succeeded, the full reset parameter, 6, would trigger a full reset. The array is important for tuning the reset algorithm. We don't want to reset too quickly before the radio's 'network stack' (driver, etc.) can do their things. And we don't want to do a full reset too soon after a quick reset because the quick reset evidently takes a few pings to recover. These recoveries are counted in the Failed Pings array. Index [0] is a counter of the times the ping test did not fail. [1..2] count recoveries by the network stack by itself plus the full reset (which wraps the counter back to 1). Indexes [3..6] count recoveries by the quick method. It seems that the number of quick recoveries [8] less the sum of [3..6] is equal to the number of full resets [9] because the full reset is triggered when the quick recovery does not recover after the 6th failed ping. The indexes are reset whenever wlanpoke is restarted. This might be because of a modification and relaunch (killing the previous instance), or booting the radio, which launches wlanpoke. Perhaps the "Log File Analysis" manual.txt section should be revised for improved clarity. There was a revision in version 0.7.3, published 3/21/2021. BTW, there is a trade off between script complexity and the desire to troubleshoot or tune the system. We want the script to take minimal resources (cpu, memory, 'disk' space) away from the music player or operating system (especially not the networking!). And it needs to be easy to understand, modify, and maintain. This means that analysis has to be done on the desktop (i.e., the user). This script is more complicated than most. If it were a compiled executable, it could do much more more efficiently, but then users would not be able to vet (important!) or easily modify it, or add features to support their own investigations, or fix bugs. ------------------------------------------------------------------------ POMdev's Profile: http://forums.slimdevices.com/member.php?userid=70558 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 _______________________________________________ Radio mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/radio
