REPRODUCIBILITY (% or how often): 100%
BUILD ID = OS VERSION (Settings > About product): Suomenlinna 4.3.0.12
HARDWARE (XA2, X10, X10 II, …): XA2
UI LANGUAGE: en-us
REGRESSION: (compared to previous public release: Yes, No, ?): ?
DESCRIPTION:
ssh connections to the XA2 are annyoing choppy and any network related action seems to suffer from overload situations.
PRECONDITIONS:
XA2 flashed to Suomenlinna, WiFI infrastructure known to work very well with countless other devices and very strong S/N ratio.
STEPS TO REPRODUCE:
- Power up, connect to WiFi, and make sure to interact with touchscreen to avoid entering any power saving mode for the next minute!
- devel-su
date; time ping -4 -c 5 -i 1 google.com ; sleep 61 ; date; time ping -4 -c 5 -i 1 google.com
- wait a minute and note the result doesn’t show any unexpected numbers.
- wait agin, now without intercating, so until display switches dark
- repeat the exactly same command from 2)
- After waiting some minutes, wake up the phone
EXPECTED RESULT:
Mon Nov 15 11:30:45 CET 2021
PING google.com (142.250.185.78): 56 data bytes
64 bytes from 142.250.185.78: seq=0 ttl=64 time=1.278 ms
64 bytes from 142.250.185.78: seq=1 ttl=64 time=19.334 ms
64 bytes from 142.250.185.78: seq=2 ttl=64 time=20.637 ms
64 bytes from 142.250.185.78: seq=3 ttl=64 time=1.600 ms
64 bytes from 142.250.185.78: seq=4 ttl=64 time=19.146 ms
— google.com ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 1.278/12.399/20.637 ms
real 0m 4.04s <<<<<<<<<<<<<<<<<<<<<<<<<< This is what I expect
user 0m 0.00s
sys 0m 0.00s
Mon Nov 15 11:31:50 CET 2021 <<<<<<<<<<<<< This is what I expect too (61s+4s after invocation)
PING google.com (142.250.185.78): 56 data bytes
64 bytes from 142.250.185.78: seq=0 ttl=64 time=4.565 ms
64 bytes from 142.250.185.78: seq=1 ttl=64 time=20.215 ms
64 bytes from 142.250.185.78: seq=2 ttl=64 time=20.087 ms
64 bytes from 142.250.185.78: seq=3 ttl=64 time=19.929 ms
64 bytes from 142.250.185.78: seq=4 ttl=64 time=19.880 ms
— google.com ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 4.565/16.935/20.215 ms
real 0m 4.04s <<<<<<<<<<<<<<<<<<<<<<<<<< With non-sleeping XA2, again I see what I expect
user 0m 0.00s
sys 0m 0.00s
ACTUAL RESULT:
When screen is still powerd up, actual result corresponds to expected result shown above!
When XA2 is sleeping, this is the result:
Mon Nov 15 11:33:56 CET 2021 <<<<<<<<<<- Note the time of invocation
PING google.com (142.250.185.78): 56 data bytes
64 bytes from 142.250.185.78: seq=0 ttl=64 time=3.691 ms
64 bytes from 142.250.185.78: seq=1 ttl=64 time=23.232 ms
64 bytes from 142.250.185.78: seq=2 ttl=64 time=20.705 ms
64 bytes from 142.250.185.78: seq=3 ttl=64 time=19.000 ms
64 bytes from 142.250.185.78: seq=4 ttl=64 time=17.515 ms
— google.com ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 3.691/16.828/23.232 ms
real 0m 30.64s <<<<<<<<<<<<<---------- 30 seconds for 4*1s+latency??? Should be 4s, not 30s!!!
user 0m 0.00s
sys 0m 0.00s
Mon Nov 15 11:41:32 CET 2021 <<<<------!!! only after wkaing device up, sleep(1) continues, and shows that XA2 was 9 minutes in coma, instead of sleeping 60s!
PING google.com (142.250.185.78): 56 data bytes
64 bytes from 142.250.185.78: seq=0 ttl=64 time=1.550 ms
64 bytes from 142.250.185.78: seq=1 ttl=64 time=19.505 ms
64 bytes from 142.250.185.78: seq=2 ttl=64 time=21.037 ms
64 bytes from 142.250.185.78: seq=3 ttl=64 time=19.698 ms
64 bytes from 142.250.185.78: seq=4 ttl=64 time=7.333 ms
— google.com ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 1.550/13.824/21.037 ms
real 0m 4.06s
user 0m 0.00s
sys 0m 0.00s
ADDITIONAL INFORMATION:
This very simplistic analysis reflects exacly all the network related problems I observed with XA2 and s1p (VoIP app), email (synchronizing) and SSH.
(RTT of google.com above shows WiFi Latency only, you will see different numbers usually)
I have no idea about arm timecounters (clocks) nor about linux counter implementations, with x6 and unix I’d simply guess TSC is incharge and switching to ACPI or i8254 would work it arround…
But this is a really severe issue which I hope Jolla will adderss really quick.
Can others please do the same test on different hardware? And maybe on XA2 with pre-Suomenlinna?
Thanks for your contribution, we need to track that down as quick as possible!
Conclusion of the numbers from above:
It’s about the hardware timecounter suffering from power saving state.
This affects at least sleep(1) and most likely any other programatically used timecounter (timeout) functions - obviously even in the TCP-IP stack.
I hope there’s a ARM timecounter keeping counting during sleep, which linux kernel is able to utilize for standard time keeping clock. So there’s just a little sysctl/kern-conf tweak needed to utilize the ‘correct’ clock. But as mentioned, I’m not the linux guy…
