Chrome Version: M-56, chromeOS build 8991.0.0, chrome 56.0.2919.
Device:  Guado

The purpose of this exercise was to throttle upload and download rates on a wired ethernet interface; launch a kiosk app that is mostly a downloader (80% images, 20% short videos), then in the background manually start an auto-update and see what the effect is on the app and overall system behavior.

What steps will reproduce the problem?
(1) Install a M-56 build that supports network interface throttling via a "dbus-send" command (8991.0.0 in this case).

(2) Enterprise-enrolled the Guado to a domain (crosprqa4.com) with an Org. Unit having these Device Settings:
    Disallow auto-updates.
    No reboot after updates.
    Force-installed Rise Player kiosk app (webstore id: mfpgpdablffhbfofnhlpgmokokbahooi)

(2) Break to VT2 and manually set the upload and download rates for the wired ethernet connection to be 4096 kbits/second:
   dbus-send --print-reply --system --dest=org.chromium.flimflam / org.chromium.flimflam.Manager.SetNetworkThrottlingStatus boolean:true uint32:4096 uint32:4096

(3) Return to the sign-in screen, and manually launch Rise Player using the Display ID UZ3BPGE55KK7 (mostly still images and some short videos).

(4) Once the Rise Player begins showing images, break to VT2, login as root and manually begin an auto-update:
# crosh
crosh> autest
^d
# tail -f /var/log/update_engine.log

(5) Once it is certain an update is in progress, return to the kiosk screen (VT1) and watch what happens. 

What is the expected result?
The Rise Player should run a little slower, perhaps not noticeably for still images, but videos might need some extra buffering time.  The auto-update should run to completion.

What happens instead?
The auto-update was humming along at just under 3200 kbits/second for several minutes, but at the 19% mark (of a ~510mb install payload), its progress slowed markedly to about 150 kbits/second, which lasted for 31 seconds before resuming its normal rate.  On the Rise Player side, the app was showing a split screen of two images and was just starting to replace one of them with a new image.  Normally that replacement happens in 2 seconds or so, but this time it seemed hung.

During the slow period I did a "top" command to see if there was a cpu-hog.  Three chrome processes were active:  One at ~25% cpu, the other two around 17% cpu; the system overall was about 78% idle.

After the 31 second slow period was over, Rise Player showed the new image.

Rise Player and the auto-update continued normally for about 3 more minutes, when Rise Player suddenly crashed (the screen flashed and went black for about 3 seconds), then the app tried to restart.  It showed two frames where images would go, with the message in each: "Wait for image to download...".  No image showed up until the auto-update had finished about 15 minutes later.

I have attached the generate_logs output (taken after the auto-update had finished), and the update_engine.log file produced by the autest command.



 

Deleted: update_engine.log 177 KB

update_engine.log 177 KB View Download

Deleted: log-113016-083315.tar.gz 312 KB

log-113016-083315.tar.gz 312 KB Download