Problem with bridge mode with remote desktop

[phhusson]

To be able to test our devices which doesn't have USB host, we are using pywalt bridge mode, and forward the mort using adb reverse.
This needed to change the IP in APK source code to 127.0.0.1

Doing this, we hit some clock issues.
Checking the drift, or forcing re-sync of clocks doesn't seem to raise anything. Latency is always around 120us.

This has been tested on an Android 5.1 phone, both in USB Host mode and adb reverse bridged mode.
USB host mode works properly, adb reverse bridged mode raises negative dt, all events are dropped because of this.

Sometimes we notice small abs(dt) like -20, but sometimes it looks like the dt is coming from previous tap.
For instance if we wait ~ 15s between two taps, we notice a ~15s dt.

Have you got some ideas on where to look at?

[kamrik]

The bridge script assumes that it runs on the same device as the app and therefore has access to the same clock (this is the case we have with ChromeOS where the bridge is needed because the app has no access to USB).

It's possible to get rid of this assumption by using the WaltDevice.simpleSyncClock()
Call it in WaltDevice.syncClock() instead of the connection.syncClock() here
https://github.com/google/walt/blob/master/android/WALT/app/src/main/java/org/chromium/latency/walt/WaltDevice.java#L220

I think with the simpleSyncClock() your setup should work ok, but the clock synchronization accuracy will be lower, probably in the order of 2-4 ms.

Thanks for the detailed description of your setup, it sounds interesting.

[phhusson]

This does help indeed thanks.
Now, at the end of the test pass (like after 20 taps on tap latency), when doing calling updateLag, the python bridge kills itself because it isn't properly initalized

Here is the stack trace

w>: '6724782\n'
w<: 'bridge update'
bridge command: bridge update, pausing ser2net thread...
Paused ser2net thread
Traceback (most recent call last):
  File "walt.py", line 707, in <module>
    run_tcp_bridge(args)
  File "walt.py", line 691, in run_tcp_bridge
    srv.serve()
  File "walt.py", line 640, in serve
    self.connections_loop()
  File "walt.py", line 602, in connections_loop
    self.net2ser_loop()
  File "walt.py", line 617, in net2ser_loop
    data = self.net2ser(data)
  File "walt.py", line 570, in net2ser
    self.walt.estimate_lag()
  File "walt.py", line 231, in estimate_lag
    times_local_received[i] = time.time() - self.base_time
TypeError: unsupported operand type(s) for -: 'float' and 'NoneType'

[kamrik]

There is no implementation for "simple" updateLag. The workaround is to comment out the call to either updateLag() on Java side or estimate_lag() on Python side. It doesn't provide useful data anyway.

What sync accuracy are you getting?
When syncing it displays Remote clock: .... lagBounds = (0, x)
It means that the WALT clock is behind the Android clock by at most x us.

[phhusson]

Thanks this works.

Loss of clock accuracy seems to be around 3ms when averaged.
Latency is quite random between 4ms and 11ms

[phhusson]

For reference, here is my current diff:
http://pastebin.com/mndUN7P4