Closed Bug 397721 Opened 17 years ago Closed 17 years ago

bl-bldxp01 perf numbers jump after reboot

Categories

(Release Engineering :: General, defect, P3)

x86
Windows XP
defect

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.
Status: NEW → ASSIGNED
Assignee: build → rhelmer
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Priority: -- → P3
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 ?
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.
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
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).
Assignee: build → nobody
QA Contact: mozpreed → build
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.
This happened again this week, so yes, it's still happening.
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.
Closing as WONTFIX, because this machine is being turned off. See details in bug#413695.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.