|
40m
QIL
Cryo_Lab
CTN
SUS_Lab
TCS_Lab
OMC_Lab
CRIME_Lab
FEA
ENG_Labs
OptContFac
Mariner
WBEEShop
|
| 40m Log |
Not logged in |
 |
|
|
 Wed Sep 30 02:01:28 2009, rob, Update, Locking, week 
|
 Thu Oct 1 15:42:55 2009, rob, Update, Locking, c1susvme2 timing problems update
| |
Fri Oct 2 14:52:55 2009, rana, Update, Computers, c1susvme2 timing problems update
| |
Fri Oct 2 15:11:44 2009, rob, Update, Computers, c1susvme2 timing problems update update
| |
Mon Oct 12 14:51:41 2009, rob, Update, Computers, c1susvme2 timing problems update update update
|
|
|
Message ID: 2037
Entry time: Thu Oct 1 15:42:55 2009
In reply to: 2027
Reply to this: 2041
|
| Author: |
rob |
| Type: |
Update |
| Category: |
Locking |
| Subject: |
c1susvme2 timing problems update |
|
|
| Quote: |
|
We've also been having problems with timing for c1susvme2. Attached is a one-hour plot of timing data for this cpu, known as SRM. Each spike is an instance of lateness, and a potential cause of lock loss. This has been going on for a quite a while.
|
Attached is a 3 day trend of SRM CPU timing info. It clearly gets better (though still problematic) at some point, but I don't know why as it doesn't correspond with any work done. I've labeled a reboot, which was done to try to clear out the timing issues. It can also be seen that it gets worse during locking work, but maybe that's a coincidence. |
|
|