POMdev wrote:
> It looks like the automatic gateway detection does not have to be
> overridden, as it seems reliable.
>
> Looking at your logs, what stands out to me is, first of all, the very
> low signal level ...Link Quality:26/94 Signal level:-69 dBm Noise
> level:-96 dBm Tx excessive retries:34.... I might have this backwards,
> but it might be that "Franky24" has a higher signal level than
> "Franky2". That said, I mistakenly ran a radio with similar levels and
> it continued to work, albeit with more frequent resets. Also, your
> "failed" to "reset" time is only 7 seconds vs 19 seconds here, but your
> "reset" to "up" time is 28 seconds vs 19 seconds here. Perhaps the long
> up time delay has something to do with low signal strength.
>
> Since the music generally kept playing here, it seemed OK with the hard
> coded test frequency and failure delay values. Synchronization adds
> another level of complexity, and these values may not be optimum for
> that use case. I think your changes are entirely appropriate, others
> might consider doing the same.
>
> The script was giving the radio network stack software, and any other
> possible future lower level mitigating solutions, every opportunity to
> do recover before "pulling the rug out" from the radio and restarting
> everything. Regrettably, the script does not track how many times the
> radio recovers from a few missed pings. We could add a statistic for
> number of failed pings and longest ping failure for later transmission
> to evaluate the time out constants. Modifying these values could lead to
> an improvement.
>
> BTW, there are other ways to monitor failures than synchronization. The
> TCP logger ncat described in manual.txt seems the easiest, yielding a
> real time display and saved log of failures. I also use the excellent
> Nirsoft Wireless Network Watcher and NetworkConnectLog apps for an
> on-screen real time update (although brief interruptions may not be
> captured by the latter two).
>
> Thanks for the report.
After 2 weeks testing this is my intermediate feedback:
- both Vonets work very well, the 300n is more hot using the Logitech
power supply than the 300g. Also the light-emitting diodes of the 300g
are easier to cover by tape (opening the case) than the 300n
- the Script works pretty well. I modified it in order to trigger a
restart after 3 unsuccessful pings instead of 6 (too conservative for
a healthy network environment). However if you play synchronized
music, you will have two interruptions when the Radio restarts the
WIFI.
- While in synchronized environments the script might no be ideal, it
helps to keep the Radio "alive and online", Thus I would recommend to
include it into the next Community Firmware --> Ralphy. Without the
script the radio turns offline and needs to be rebooted with
neighboring WIFI-6...
------------------------------------------------------------------------
frankd's Profile: http://forums.slimdevices.com/member.php?userid=52885
View this thread: http://forums.slimdevices.com/showthread.php?t=109953
_______________________________________________
Radio mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/radio
