Closed
Bug 397721
Opened 17 years ago
Closed 17 years ago
bl-bldxp01 perf numbers jump after reboot
Categories
(Release Engineering :: General, defect, P3)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: rhelmer, Unassigned)
Details
Performance numbers from the win32 perf machine, bl-bldxp01, sometimes jump after a reboot.
Sometimes the numbers come back to "normal" after several runs, sometimes after another reboot.
I'd like to know why this is happening, so we can prevent it on this machine and future perf test machines.
Reporter | ||
Updated•17 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Updated•17 years ago
|
Assignee: build → rhelmer
Status: ASSIGNED → NEW
Reporter | ||
Updated•17 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P3
Comment 1•17 years ago
|
||
Here's a plausible (if unpalatable) theory:
"Normal" test results rely on the VNC server having crashed
Rob checked if VNC was responding at 01:09 PDT, it wasn't (black screen) and in-progress Trunk run then had "normal" results for Txul and Ts. Subsequent runs on both Mozilla1.8 & Trunk have had sensible results for all tests. A few minutes before 01:09, he found that VNC was responding fine.
(Note: the perf boxes align their start time with the build they're testing, so a later test appears on the waterfall at 01:09. You need to look at the test which started at 00:14 to see the Txul & Ts I mention above).
A potential solution is to switch to the RealVNC server, which Talos apparently uses without any issues. There may be a change in the baseline as a result, so comments from devs about the preferred course of action would be welcome.
Alice & Ben, can you confirm RealVNC works ok ?
That does sound plausible.
Comment 3•17 years ago
|
||
RealVNC has been working great for us on XP. There is one or two caveats, that are addressed <a href="http://wiki.mozilla.org/ReferencePlatforms/Test/WinXP#RealVNC">. Basically, once VNC is setup as a service and you've rebooted you can't logon with RDP anymore, or else VNC breaks.
Reporter | ||
Comment 4•17 years ago
|
||
I think we should switch to the RealVNC server (from TightVNC server), but we'll need to make it clear when the switch took place (maybe during the next IT outage window?).
It'll be interesting to see how this changes the numbers.
I'm not going to be able to actively work on this much longer so setting back to default assignee, but leaving open so we can continue investigating.
Assignee: rhelmer → build
Status: ASSIGNED → NEW
Reporter | ||
Comment 5•17 years ago
|
||
I've replaced TightVNC server with RealVNC server as of today (we haven't had builds since 4am due to bug 398423, which is an instance of bug 386594).
Updated•17 years ago
|
Assignee: build → nobody
QA Contact: mozpreed → build
Comment 6•17 years ago
|
||
Is this still a problem after the VNC server replacement or can we close this bug?
I note that we are mothballing this machine (see bug#413695), and it seems from comment#1 that Talos is already doing the right thing here.
Comment 7•17 years ago
|
||
This happened again this week, so yes, it's still happening.
Comment 8•17 years ago
|
||
As we are mothballing this machine (see bug#413695) anyway, should we WONTFIX
this bug?
It seems from comment#1 that this is already working in Talos.
Comment 9•17 years ago
|
||
Closing as WONTFIX, because this machine is being turned off. See details in bug#413695.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•12 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•