New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 620222 link

Starred by 1 user

Issue metadata

Status: Archived
Owner:
Last visit > 30 days ago
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

verify is slow caused by servo

Project Member Reported by dshi@chromium.org, Jun 15 2016

Issue description

Verify special task is way slower than before. It used to take less than 10s, now it can be as long as 40s. e.g.,
http://chromeos-shard2-staging.hot.corp.google.com/results/hosts/chromeos4-row10-rack9-host11.cros/1182-verify/20161506001334/debug/autoserv.DEBUG

One reason is that servo verification takes unnecessarily long:
time ping -c 3 chromeos4-row10-rack9-host11-servo.cros
PING chromeos4-row10-rack9-host11-servo.cros.corp.google.com (100.107.203.45) 56(84) bytes of data.

--- chromeos4-row10-rack9-host11-servo.cros.corp.google.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2014ms

real    0m12.027s

The servo chromeos4-row10-rack9-host11-servo.cros can be resolved but not online. We shouldn't waste time on checking servo repeatedly.
 
There are 2 places where we ping the servo host:
- host init
- detecting servo label

It's a bit hard to take out the servo detecting logic out of those two places.  We can consider shortening the timeout and the number of retries.  I'm not sure if there was a reason for trying 3 times, perhaps we can get away with trying 2 times with a timeout of 2 seconds cutting down the wait from 12 seconds to 4?

That being said, the verify should only take a long time if the servo host is unresponsive (saving 24 seconds total from waiting for servo host detection to timeout).
Labels: akeshet-pending-downgrade
ChromeOS Infra P1 Bugscrub.

P1 Bugs in this component should be important enough to get weekly status updates.

Is this already fixed?  -> Fixed
Is this no longer relevant? -> Archived or WontFix
Is this not a P1, based on go/chromeos-infra-bug-slo rubric? -> lower priority.
Is this a Feature Request rather than a bug? Type -> Feature
Is this missing important information or scope needed to decide how to proceed? -> Ask question on bug, possibly reassign.
Does this bug have the wrong owner? -> reassign.

Bugs that remain in this state next week will be downgraded to P2.

Comment 3 by sosa@chromium.org, Jul 18 2017

Status: Archived (was: Untriaged)

Sign in to add a comment