castor_fou wrote: > ... any effect in the number of connectivity losses per day... > I don't follow completely your explanation under Log File Analysis. ... > Ping 2s-1q6f Events, Fails[0..7] 8154s : Qr:0 Fr:27 Wr:0 Wc:0 [ > 2299 10 0 0 0 0 27 0 ] > ...Are you confident we could get an actual solution packaged in > community firmware fixing all our disconnection issues? The number of connectivity losses may go up if the quick reset effects don't last very long, but 'hopefully', those brief outages they will not result in music interruptions. You are experiencing 12 resets per hour, that's high, especially considering your very good signal level of -54 dBm.
Too bad the script is so complicated as it is. The modest mitigation portion is just detection, a full "brute force" reset, one of many possible 'quick' resets, and making sure that the os software stack is running (e.g. 'wpa_cli' occasionally disappears, and we relaunch it). Most of the script is data capture, which takes a lot of processing time. Some of the data is for validating the script, but most of it is for evaluating the environment and the radio's response to the outages. It is not practical to do other than the most basic analysis on the radio using a script. So we have to do it ourselves, perhaps by processing the captured data with some (e.g., your) desktop analysis code. Explaining the data in an understandable and concise manner is not easy, and there are so many different cases to explain, especially as the software evolves into new areas of investigation. For example, we are not logging actual music interruptions for correlation to outages, but the most important measure is music interruptions, and is critical to evaluating different mitigation methods. "Confident" would be going too far. The attitude is "Hopeful." The real solution would be for Qualcomm/Atheros to investigate and patch their (by necessity closed) chip firmware, if not to prevent loss of receiver sensitivity then at least to monitor it and offer some much quicker method for resetting or adjusting the systems on the chip so that they do not repeatedly fail to respond to packets. What we can do is build on the expressly open yet unavailable source os driver stack to implement detection and mitigation that can work far more quickly and efficiently than the current mitigation script, so that the usual buffering would make very brief degradations or interruptions unnoticeable. Whether the latter mitigation can be adequately justified, tested, and validated and thus be fit for inclusion into an official software release is for others to decide. ------------------------------------------------------------------------ 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
