So after having broke Allegra by updating the kernel, I was able to get it running again by copying the xorg.conf.backup file over xorg.conf in /etc/X11.  So at this point in time, Allegra is running with generic video drivers, as opposed to the ATI specific and proprietary drivers.

c1susvme1 is behaving weirdly.  I've restarted it several times but its computation time is hanging out around 260 usec, making it useless for suspension control and locking.  I also found a PS/2 keyboard plugged in, which doesn't work, so I unplugged it.  It needs to be plugged into a PS/2 keyboard/mouse Y-splitter cable. 

 Kiwamu and I brought 2 SUPER MICRO PCs from Willson house into 40m.

Both PCs are hooked up into Martian network. One is named as bscteststand for BSC which has been set up by Cds people and another one is named kami1 for temporary use for CLIO which is a bland new, no operating installed PC. This bland new PC will be returned Cds or 40m once another new PC which we will order within several days arrives.

IP address for each machine is 131.215.113.83 and 131.215.113.84 respectively.

We have installed CentOS5.2 into the new PC.

#!/bin/csh -f
setenv POSIXLY_CORRECT
while (! { ezcawrite.bin $* })
      echo "Retry $0 $*"
end

I added the following repos which I found on allegra to megatron and then did a 'yum install sshfs' on both machines:

allegra:yum.repos.d>l
total 28
-rw-r--r-- 1 root root  428 Feb 12 16:47 rpmforge.repo
-rw-r--r-- 1 root root  684 Feb 12 16:47 mirrors-rpmforge
-rw-r--r-- 1 root root 1054 Feb 12 16:47 epel-testing.repo
-rw-r--r-- 1 root root  954 Feb 12 16:47 epel.repo
-rw-r--r-- 1 root root  626 Feb 12 16:47 CentOS-Media.repo
-rw-r--r-- 1 root root 1869 Feb 12 16:47 CentOS-Base.repo
-rw-r--r-- 1 root root  179 Feb 12 16:47 adobe-linux-i386.repo

This also required me to import the rpmforge GPG key:

sudo rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

I found that tdsdata doesn't work.

When I star tdsdata, he takes a few ~ 10 seconds of data, and he dies with a message "Segmentation fault".
I tried to get data for some times and some channels, and this problem was observed everytime.
I also tried tdsdata on allegra, op440m and mafalda, and it didn't work on all of them.

Yesterday, I got a new version of tdsdata (which modified the problem of Message ID: 1328) and tried to build 
thme on my directory (/cvs/cds/caltech/users/kakeru.....)
This may have some relation to this problem.

restartFE c1lsc

restartFE c1lsc c1asc c1susvme1

restartFE all

fb:controls>./tpman &
[1] 1037
fb:controls>VMIC RFM 5565 (0) found, mapped at 0x2868c90
VMIC RFM 5579 (1) found, mapped at 0x2868c90
Could not open 5565 reflective memory in /dev/daqd-rfm1
16 kHz system
Spawn testpoint manager
Channel list length for node 0 is 4168
Test point manager (31001001 / 1): node 0

After the boot-fest, the nightly backup to Powell-Booth failed, and an automatic email got sent to me. I restarted the ssh agent, following the instructions in /cvs/cds/caltech/scripts/backup/000README.txt .

Because of the network interference we've had from the CLIO system for the past 3-4 days, I asked the guys to remove

the test stand from the 40m lab area. It is now in the 40m control room. Since it needed an ethernet connection to get out

for some reason we've let them hook into GC. Also, instead of using a real timing signal slaved to the GPS, Jay suggested

just skipping it and having the Timing Slave talk to itself by looping back the fiber with the timing signal. Osamu will enter

more details, but this is just to give a status update.

This morning there was a confliction of tpman running on fb40m and kami1. Alex fixed it temporary but Rana suggested it was better to move both PCs outside martian. We moved both PCs physically to the control room and connected to general network with a local router. I believe it won't conflict anymore but if you guess these PC might have trouble please feel free to shutdown.

Today's work summary:

 *connected expansion chassis to bscteststand

 *obtained signals on dataviewer, dtt for both realtime and past data on bscteststand with 64kHz timing signal

Questions:

Excitation channels are not shown, only "other" is shown.

qts.mdl should run with 16kHz but 16kHz timing causes a slow speed on dataviewer and failing data aquisition on dtt. We are using 64kHz timing but is it really correct?

We found c1lsc, c1iscex, c1iscey, c1susvme, c1asc and c1sosvme are dead.
We  turned off all watchdogs and turned off all lock of suspensions.
Then, I tried to reboot these machines from terminal, but I couldn't login to all of these machines.

So, we turned off and on key switches of these machines physically, and login to them to run startup scripts.

Then we turned on all watchdogs and restored all IFO.

Now they look like they are working fine.
 

I tried to play an .avi file on allegra. In a normal universe this would be easy, but because its linux I was foiled.

The default video player (Totem) doesn't play .avi or .wmv format. The patches for this work in Suse but not Fedora. Kubuntu but not CentOS, etc.I also tried installing Kplayer, Kaffeine, mplayer, xine, Aktion, Realplay, Helix, etc. They all had compatibility issues with various things but usuallylibdvdread or some gstreamer plugin.So I pressed the BIG update button. This has now started and allegra may never recover. The auto update wouldn't work in default mode becauseof the libdvdread and gstreamer-ugly plugins, so I unchecked those boxes. I think we're going to have this problem as long as we used any kind ofadvanced gstreamer stuff for the GigE cameras (which is unavoidable).

I really don't understand why my programs that I used to use to get data from the HP Spectrum Analyzer and the Marconi frequency generator don't work anymore.

I spent hours trying to debug the code but I can't sort the problem out.

The main problem seem to be with the function recv from the socket library. Somehow it can't anymore get any data from the instruments. The thing I can't understand, though, is that if called directly from the python terminal it works fine!

In particular the problem is with the following lines in my code:

netSock.send("mkpk;mka?\n")
netSock.send("++read eoi\n")
tmp = netSock.recv(1024)

Tried a lot of tickering but it didn't work.

I attach the two scripts I've been using. One (sweepfrequencyPRC.py) calls the other (HP4395PRC.py).

They worked egregiously for weeks in the past. Don't know what happened since then.

This morning Joe looked at my code and made me notice that for some reason the query to the Spectrum Analyzer made by netSock.recv(1024) contained two answers. It was like the buffer contained the answer two different queries.

After some experiment I found that basically the GPIB interface wasn't switching from the "auto 1" to the "auto 0" mode as it should. I rewrote part of the code and that seemed have solved the problem.

Still don't understand why it used to work in the past and then it stopped.

nodus was hanging because it was trying to mount the cit40m account from rigel and rigel was not responding.

Neither I nor Yoichi can recall what the cit40m account does for us on nodus anymore and so I commented it out of the nodus /etc/vfstab.

nodus may still need a boot to make it pay attention. I was unable to do a 'umount' to get rid of the rigel parasite. But mainly I don't want anything in

the 40m to depend on the LIGO GC system if at all possible.

We successfully compiled and installed the Real time Code Generator "Hello World" example (which is a skeleton for the ETMX suspension controller) on megatron.  In order to get it to compile, we had to add a flag indicating the computer is stand alone, and not using a myrinet card at the moment.  This was done by adding the shmem_daq = 1 flag to the cdsParameters module.  The symptom was it was unable to find gm.h (and there is no installed /opt/gm directory).

It is called "sam".  It was installed to /cvs/cds/caltech/target/sam, and produced medm screens in /cvs/cds/caltech/medm/c1/sam.  As nothing points to these, I figure it won't harm any of the current configuration, but lets us play around a bit.  If by some strange reason, these do cause problems, feel free to remove them.

#
# Script to backup via rsync the most recent 40m minute trends and
# any changes to the /cvs/cds filesystem.
#
50 05 * * * /cvs/cds/caltech/scripts/backup/rsync.backup < /dev/null > /cvs/cds/caltech/scripts/\
backup/rsync.backup.log 2>&1

30 06 * * * find /usr/controls/jobs -mtime +7 -exec /bin/rm -f {} \;

Having determined that Rana (the computer) was having to many issues with testing the new Raid array due to age of the system, we proceeded to test on fb40m.

We brought it down and up several times between 11 and noon.  We  eventually were able to daisy chain the old raid and the new raid so that fb40m sees both.  At this time, the RAID arrays are still daisy chained, but the computer is setup to run on just the original raid, while the full 14 TB array is initialized (16 drives, 1 hot spare, RAID level 5 means 14 TB out of the 16 TB are actually available).  We expect this to take a few hours, at which point we will copy the data from the old RAID to the new RAID (which I also expect to take several hours).  In the meantime, operations should not be affected.  If it is, contact one of us.

This afternoon the alignment script chrashed after returning sysntax errors. We found that the tpman wasn't running on the framebuilder becasue it had probably failed to get restarted in one of the several reboots executed in the morning by Alex and Jo.

Restarting the tpman was then sufficient for the alignment scripts to get back to work.

Restarted backup since fb40m was rebooted.

The 40m frame builder is currently being patched to be able utilize the full 14 TB of the new raid array (as opposed to being limited to 2 TB).  This process is expected to take several hours, during which the frame builder will be unavailable.

The Elog started crashing last night. It turns out I was the culprit, and whenever I tried to upload a certain 500kb .png picture, it would die. It has happened both when choosing "upload" of a picture, and when choosing "submit" after successfully uploading a picture. Both culprits were ~500kb .png files.

we did a hard reboot of c1susvme1, c1susvme2, c1sosvme, and c1susaux.  We are hoping this will fix some of the weird suspension issues we've been having (MC3 side coil, ITMX alignment).

I just restarted the elog.  It was crashed for unknown reasons.  The restarting instructions are in the wiki.

c1susvme2 has been running just a bit late for about a week.  I rebooted it. 

The plot shows SRM_FE_SYNC, which is the number of times in the last second that c1susvme2 was late for the 16k cycle.   Similarly for ETMX.

The reboot appears to have worked.

I restarted ntpd on op440m to solve a "synchronization error" that we were having in DTT.  I also edited the config file (/etc/inet/ntp.conf) to remove the lines referring to rana as an ntp server; now only nodus is listed.

To do this:

log in as root

/usr/local/bin/ntpd -c /etc/inet/ntp.conf

rob, alberto, rana, pete

we reset this computer, which was out of sync (16384 in the FE_SYNC field instead of 0)

Restarting the framebuilder didn't work, but the problem now appears to be fixed.

Upon reflection, we also decided to try killing all open DTT and Dataviewer windows.  This also involved liberal use of ps -ef to seek out and destroy all diag's, dc3's, framer4's, etc.

That may have worked, but it happened simultaneously to killing the tpman process on fb40m, so we can't be sure which is the actual solution.

To restart the testpoint manager:

what you type is in bold:

rosalba> ssh fb40m

fb40m~> pkill tpman

The tpman is actually immortal, like Voldemort or the Kurgan or the Cylons in the new BG.  Truly slaying it requires special magic, so the pkill tpman command has the effect of restarting it.

In the future, we should make it a matter of policy to close DTTs and Dataviewers when we're done using them, and killing any unattended ones that we encounter.

After poking around for a few minutes several facts became clear:

1) At least one GPIB interface has a hard ethernet connection (and does not currently go through the wireless).

2) The wireless on the laptop works fine, since it can connect to the router.

3) The rest of the martian network cannot talk to the router.

This led to me replugging the ethernet cord back into the wireless router, which at some point in the past had been unplugged.  The computers now seem to be happy and can talk to each other.

I checked out a copy of matapps into /cvs/cds/caltech/apps/lscsoft so that I could find the matlab function strassign.m, which is necessary for some old mDV commands to run.  I don't know why it became necessary or why it disappeared if it did.

In /cvs/cds/caltech


1.6M    2008-8-15.pdf
2.9M    40mUpgradeOpticalLayoutPlan01.pdf
2.4M    alh
19M     apache
18G     apps
11M     archive
4.0K    authorized_keys2
8.0K    backup.notes
8.0K    backup.notes~
1.9G    build
62G     burt
47M     cds
13M     cds40m
37M     chans
70G     conlog
52K     crontab
12K     cshrc.40m
12K     cshrc.40m~
36M     diag
1.4G    dmt
8.2M    framecpp-0.2.0
1.7M    free_080730.pdf
57M     gds
9.8G    home
60K     hooks
8.0K    hosts.40m
4.0K    id_rsa
10M     iscmodeling
110M    ldg-4.7
648M    libs
4.0K    log2.txt
224K    logs
0       log.txt
238M    medm
344M    NB
148M    NB_080304
211M    NB_080307
401M    NB40
1.2G    noisebudget.071109
837M    noisebudget.bak.20060623
3.5M    oldtarget
123M    root
5.7M    savesets
208K    schematics
655M    scripts
13G     scripts_archive
1.1M    state
3.7G    svn
4.0K    svn-commit.tmp
7.3G    target
295M    target_archive
6.7M    test
72K     test.png
4.0K    tmp
8.0K    typescript
35G     users
205M    wind