Now that we have DTT fully up and running with AWG, I took a *good* open loop transfer function for the PMC control loop.

I am sure there are some things I haven't yet understood about my loop...

In the digital world I have:

• A 1 Hz pole for control
• Two 1Hz zeros and 10 Hz poles for antidewhitening to comensate for the Piezo Driver Box.

It appears that the frame builder has stopped writing to file again. Actually what I see if the following:

1. I can't retrieve any data from the last couple of days in dataviewer or DTT
2. I can see data from three days ago.

I'm not sure why this is. Perhaps the disk is full again. Restarting the frame builder didn't help so we need to start digging a little deeper I think.

TL;DR WE SHOULD GET A NEW HARD DRIVE THAT IS BIGGER FOR ACTUAL LOOKBACK TIME.

• 4 2TB drives in raid? Redundant
• Maybe these for 220$ each? (options)

So me and Aidan were looking at the DAQ and trying to figure out our lookback because things weren't working. I deleted all the data in frames and kept the number of files.

In the current configuration we have:

• 60 files in /frames/full each of which store 1 hour of data.
• Each /frames/full/dataxx folder contains 225 *.gwf files 16 seconds apart each, for a total of 1 hour of data.
• These are each 16255955 bytes. So each frames data file is 3657589875. (3.66 Gigs)
• A total size of 204.3 GB

I did a "df -h" and found that the frames drive (or partition) is 275 GB

I did a "du -hs frames/trend" and found that we already have 90 GB of data written in the trend section. (this is bad...275 < 204+90)

du -hs /frames/trend/minute/raw = 30 GB

The /raw directories contained ALL the DAQ channels ever from the old OMS build @ 27 MB each. I deleted all these files. but they were immediately remade and are growing. Fixed?

Someone either added, or we never commented out all the epics channels in

/cvs/cds/caltech/chans/daq/C0EDCU.ini

in /cvs/cds/caltech.target/fb.

I edited this out and restarted the frontend, and it seems we aren't giving away 30 GB that we need anymore.

We also have redundant channels in the "NOT YET RECORDING TRENDS ABOUT THE PSL" in this file. Half are prefixed with C2, half are prefixed with C3. Once we get one of these halves to work, we should delete the others (probably in /cvs/cds/caltech/chans/daq/C2EDCU.ini) These are 5MB each and there are roughly 50 of them.

I don't know if/how the size of the /frames/full/dataxx/blahblah.gwf files scale with number of DAQ channels we have set, but we use 27 MB in /frames/trend/minute/raw for each DAQ channel we add.

I expect that something not nice will happen with the system when we try to write to the Nth frames/full file and run out of space. /frames/trend is now at 60 GB, and I didn't delete anything that was already there, so we should have enough space to get a full /frames/full cycle of 205 GB if this doesn't grow.

Running out of disk space is sad:

1. Setup a cron to text Dmass and Aidan when the disk gets to 95%.
2. Talk to Alex and then get 2-4 TB of space. We don't need raid yet.

I added in some boost to the PMC Loop. The loop is now locked with a net:

Poles: 10 25 0

Zeros 150 50

And some gain to make my boost stages actually boost. zpk(150,10,15) and zpk(50,25,2) are my "boost" stages.

My locking algorithm:

• Get close to the fringe and let the system spaz out using my 72 Hz PMC PZT pole for locking
• Engage FM4, which is a zero at 72 Hz and a pole at 1 Hz
• Engage my Boost stages
• Engage my integrator (zero at 1 Hz and a pole at zero)

Results of the loop with the boost on and off (with slightly different gain settings) are attached in pdfs

RED: Boosts on, integrator on, gain slightly lower to move my UGF (~ factor of 2)

GREEN: No boost, integrator on

BLUE: Some old spectrum of the PMC Transmission light. I don't *believe* that this calibration has changed, but could be wrong.

PD1_IN1 is my PMC Transmission

ISS1 is my error signal

Whenever I come in to make a measurement, more often than not DTT is nonresponsive. This is fixed by

telnet fb0 8087

daqd>shutdown

But it seems this should not be happening, and may have other negative consequences for us.

Spotted a ton of accumulating overflows on the DAQ - specifically the output for DMass's PZT on his PMC.

It looks, from the EPICS screen, like that channel is trying to output a lower number of counts (~ -90000) than the DAQ can reasonably drive. (+/- 20V = 64K counts). We should try and set upper and lower limits on the channels. I'm not sure why this isn't set automatically in the RCG.

Also made a note on the ATF wiki ...

Seems to be a non-fatal error though.

I had left some of my output filters off on accident from doing a cavity sweep. This should be fixed.

Came in and found the PMC_PZT output trying to deliver an obscenely large number of counts to the DAC.

Not really sure where the issue is coming from - looks like the filters in the attached module. Anyway, just set a limit on what that module can output for the time being. Will leave this one for DMass to figure out.

Frank was talking about rebooting the frame builder last night. That shouldn't have affected the front end though. But if we do want to reboot the front end will all our settings be saved and restored automatically?

Filt 1 integrates.

Infinite gain at DC.

There's constant input.

You should try just leaving FM4 on all the time.  Since the purpose of this FM is to make the loop 1/f everywhere from 1Hz to several kHz, the loop should be stable over very large gain ranges.  This makes locking much easier.

the following 35W laser-system data is now available as (slow) EPICS channels (read access only so far):

[C2:PSL-AMP_MANUALMODE]
[C2:PSL-AMP_DBILOCK]
[C2:PSL-AMP_DCUROK]
[C2:PSL-AMP_ENABLETEC]
[C2:PSL-AMP_ERR]
[C2:PSL-AMP_OFF]
[C2:PSL-AMP_RESET]
[C2:PSL-AMP_DTEMPERR]
[C2:PSL-AMP_ENABLEPWRDOG]
[C2:PSL-AMP_SYSTEMOK]
[C2:PSL-AMP_LOWPWR]
[C2:PSL-AMP_CHILLERR]
[C2:PSL-AMP_DVOLT1]
[C2:PSL-AMP_DVOLT2]
[C2:PSL-AMP_PWR1]
[C2:PSL-AMP_PWR2]
[C2:PSL-AMP_PWR3]
[C2:PSL-AMP_D1TEMP]
[C2:PSL-AMP_D2TEMP]
[C2:PSL-AMP_D3TEMP]
[C2:PSL-AMP_D4TEMP]
[C2:PSL-AMP_D1PWR]
[C2:PSL-AMP_D2PWR]
[C2:PSL-AMP_D3PWR]
[C2:PSL-AMP_D4PWR]
[C2:PSL-AMP_DCUR1]
[C2:PSL-AMP_DCUR2]
[C2:PSL-AMP_XTALTEMP]
[C2:PSL-AMP_SECS]
[C2:PSL-AMP_MINS]
[C2:PSL-AMP_HRS]
[C2:PSL-AMP_DAYS]
[C2:PSL-NPRO_D1PWR]
[C2:PSL-NPRO_D2PWR]
[C2:PSL-NPRO_D1TEMPSET]
[C2:PSL-NPRO_D2TEMPSET]
[C2:PSL-NPRO_D1TEMP]
[C2:PSL-NPRO_D2TEMP]
[C2:PSL-NPRO_D1TEMPERR]
[C2:PSL-NPRO_D2TEMPERR]
[C2:PSL-NPRO_TEMPGUARD1]
[C2:PSL-NPRO_TEMPGUARD2]
[C2:PSL-NPRO_XTALTEMPSET]
[C2:PSL-NPRO_XTALTEMP]
[C2:PSL-NPRO_XTALTEMPERR]
[C2:PSL-NPRO_CURSET]
[C2:PSL-NPRO_CUR]
[C2:PSL-NPRO_NEMON]

i've checked some of them but not all, so feel free to check all channels you new and let me know if something is not working or should be changed. i also have to add the units for each channel...

in order to have access to the laser data i had to change the network a bit. the laser and the windows computer (T42 notebook) are now in the real-time segment (as all other machines). IP-adresses are assigned via DHCP, might change this to fixed ones later...if there are any problems please let me know...

A little bird told me (ELOG ELOG PLEASE) that "the DAQ is now broken in 58"

Whatever has been done to the front end/framebuilder (inclusive of Frank adding the channels, and maybe rebuilds?) appears to have made everything not work with the ATF system.

• All test points are now gone as far as dataviewer is concerned, only the DAQ channels remain
• I can telnet into fb0 and dropkick it, but this fixes nothing
• I suspect some funk with DCUIDs somewhere, if this is the problem PKing may know more about what is needed to have trending and a FE system work simultaneously, and Alex definitely does.
• I can prove nothing about my above suspicions
• I am leaving for 3 weeks, someone should look at this and try to fix it
• There is also the possibilitiy that the network restructuring borked something. I am unsure if anything has been working since then.

@Aidan/Alastair: Has anything other than the trending channels been working since the trending channels were added?

the dataviewer doesn't work in realtime mode. if you close the grace window the application crashes and you have to kill it manualy. viewing trend data is working. anyone had this before and knows how to fix it?

ordered new hard disks for the FB - will arrive soon, with the help of alex i would like to exchange the old one at the end of this week / beginning next week - FB might be down for half a day - any days when we can't do that because of important measurements to be done or so? plz let me know

will install a new (second) workstation beginning next week -  we will replace the hard disk of the current, second computer by a new one- we do NOT delete anything on the old one, we keep it as it is until we decide that we really don't need anything from that disk anymore - anyway, if you have data on that disk plz download it now, otherwise it is a lot more work later on...

As before but with electronics noise added.

Am running the following script overnight to increase the loop gain for the fiber loop every 4 hours.

The process is gain_change.sh

#!/bin/csh
# - - - - - - - - - - - - - - - - - - - -
# scan the FS loop gain up from 100 to 1000 in 4 hour increments
# 17th Sept 2009


   sleep 5
   ezcawrite "C2:ATF-GENERIC_GENOUT8_GAIN" "100"
   sleep 14400
   ezcawrite "C2:ATF-GENERIC_GENOUT8_GAIN" "330"
   sleep 14400
   ezcawrite "C2:ATF-GENERIC_GENOUT8_GAIN" "1000"

network is working again, broke the DAQ several times but is running again now. workstation2 has still the problem with the graphics card - have to buy/get a dual head card anyway, so this might be fixed by then. we can now start to install all the tools we need/want. i bought a second disk to make a copy of the final installed system to replace the one in the first workstationas well. then we have two identical and up-to-date workstations

today Larry said that we have to change the IP addresses for the Lab. We are still using the 131.215.113.xxx  network, which has historic reasons but should be changed as we are working in a private subnetwork and those addresses are public ones which are used outside as well. So i will change it to a 10.x.x.x network at the end of this week....

There were no testpoints according to DTT and DV - This is because:
/cvs/cds/caltech/target/gds/param/tpchn_M1.par was commented out of /cvs/cds/caltech/target/fb/master. 

Changing this solved (some of) the problems we encountered.

We also encountered an unkillable frontend process at some point -

• startatf runs killatf.
• killatf kills atffe.rtl
• sudo pkill <process number> gave no error message yet the atffe.rtl process was still running. start

The above appeared to be correlated with running startatf a number of times, (so killing and restarting everything repetitively.) We have zero interest in trying to repeat the unkillable bug so we rebooted oms and everything seemed ok.

pkill can not slay the processes spawned by the .rtl files, because they are kernel modules, and thus operate in a lower domain.  Sometimes you may invoke the demon of /sbin/rmmod instead of rebooting.

I couldn't get any output from the DAC when I ran my frontend at 32 kHz (on a 64 kHz clock). In an attempt to solve this, I did a cvs update in the advLigo directory.

There were MANY ERRORS in every step of the make process, and nothing really worked.

I tried to revert to a previous version by looking at

>cvs log

and doing a

>cvs update -r  <version here>

This did not seem to work, as I got all sorts of errors along the lines of

cvs update: conflict: src/fe/omc/Makefile is modified but no longer in the repository
C src/fe/omc/Makefile

and I could not do a /advLigo > make atf
I have emailed Alex, things seem FUBAR enough that I think we will have nothing until someone debugs the code or figures out how to revert to a previous version, then debug that code.

So I talked to Alex, and the version of the RCG that was in CVS was not up to date. He fixed this and things seemed to work at 32 kHz.

Until I lnoticed a GIANT 2Hz COMB on my error signal in my loop...

When I look at my error signal in dataviewer, it seems that a sign is wrong somewhere in the downsampling, for it is flipping sign at 2 Hz. THIS SEEMS BAD

...going to 64kHz for now.

I have managed to get the DAQ/FE running at 64, 32, and 16 k. We can now choose our frontend rate.

We are at ~2/3 load at 64k right now.

I may go back down to 32k in light of this.

since today we have a static IP address:

131.215.115.216

services available from outside are currently:

since today we have two new 24" monitors for the second workstation. I had to uninstall the virtualization stuff from centos in order to be able to compile the nvidia driver.

today i installed the latest version of Matlab on WS2 (R2009b). After the installation was finished matlab claimed that the libXo.so.6 package is missing. After installing this package matlab still wanted this package...

I turned out that we need to install the libXo.x86_64 package instead. After installing this i got this error

/apps/matlab_R2009b/bin/glnxa64/MATLAB: error while loading shared libraries: /apps/matlab_R2009b/bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/libtbb.so.2: cannot restore segment prot after reloc: Permission denied

using  chcon -t textrel_shlib_t /apps/matlab_R2009b/bin/glnxa64/libtbb.so.2 could fix the problem, so now Matlab is working on WS2

I am able to connect to the 8088 port, but can only get data through DTT and not dataviewer. Anyone else have this problem?

 i can access the FB using the matlab ligoDV tool, realtime and trend data. i don't have the other dataviewer on my computer. can someone else test it plz

i took me some while to figure out why the java plugin on the workstations in firefox is not working. the mistake was that the standard 32bit version of the JRE was installed (not the 64bit version) and the linked file was the wrong one. the following has to be done in order to get it running:

• download the latest 64bit version of the JRE (e.g. jre-6u16-linux-x64-rpm.bin)

• change permission to "executable"

• run installation

• go to the firefox configuration directory in your home directory, e.g /home/controls/.mozilla/plugins/

• create a link here to the file "libnpjp2.so" (not "libjavaplugin_jni.so" as some web pages tell you") located in the java directory (e.g. /usr/java/jre1.6.0_16/lib/amd64/), e.g using "ln -s /usr/java/jre1.6.0_16/lib/amd64/libnpjp2.so /home/controls/.mozilla/plugins/libnpjp2.so"

• go to the firefox directory in your home directory, e.g. /home/controls/.mozilla/firefox/bv02gt30.default/

• delete the config file "pluginreg.dat"

• run firefox

• go to the firefox plugin config page typing "about:plugins"

• firefox now registers all plugins again and creates a new config file. the following page should show the java plugins (and all others)

today i got an "old" computer and lots of 250Gig drives from Larry. It turned out that the "old" computer is newer than our existing stuff and a sseconf computer of this type is used by Rolf as the stand-alone RT system.

I will get a copy of the stand-alone version on a couple of drives tomorrow, so we can use this computer as a second, independent framebuilder for EPICS channels and fileserver for our individual home directories, whic will be mounted on each workstation.

When we upgrade the existing frontend to more space using SATA drives instead of old expensive SCSI drives we will change the historic arrangement that the frontend requires the workstation to be up in order to mount the RT stuff.

We will also change the internal network addresses. I prepared a graph which i will post tomorrow or so and also print it and put a copy next to the workstations in the lab. I will start with all new machines and if everything is running we change the fb and ws1 too.

Since I wasn't able to get dataviewer to read the C2 channels remotely, I just used DTT to grab 7000 seconds of data with a 0.1 Hz BW from the laser from today. Don't we have dataviewer running somewhere?

In any case, the channels came out fine. Nothing strange looking.

update: I ssh'd in and ran dataviewer off of ws1.

for the amplifier, you can see that many of these channels are bit noise. I have also made a directory called /users/Templates/ where we can put all of our useful DV / DTT files for group enjoyment.

i will start changing some of the computers today. after all changes are done and we have all the new computers running it will look like this:

 i will check this. it might be the resolution of the beckhoff stuff. sometimes you see the last one or two bits fluctuating, especially if the values are very small...

the DAQ and network will be down the next couple of hours...

network is up again. added the new fileserver (not running yet) and the new opc-server (running, but not active yet).

as we were running out of sockets in the computer rack i decided to remove the old power strips and replace it by one large (20 outlets) tripp lite one. now including the new computers, monitors etc we have still 5 sockets left.

network is the same as before as alex couldnt make the copies of the stand-alone RT system yet. we decided today that we have to upgrade the existing one they have to a newer version first. the chances are good that we can install everything tomorrow afternoon...

will will change the network NOW, so everything will be down for some time

did all the network changes. Network inside the lab is now

10.0.1.xxx / 255.255.255.0

the addresses are (slightly changed since the posting of the network drawing):

 the new fileserver will be available next week as we have to set up the home directories first and copy the RT-stuff from WS1 to there as well.

A new network diagram as well as more detailed information about the new stuff will be posted next week...

the following, updated graph shows the network topology and detailed information about each computer in the lab network.

Additional compters and equipment will be added soon (like e.g. the RT stuff from peter to get it into the frames of fb1)

nothing has changed in principle so far. Each computer is available by using it's old name, except the frontend, which is now called "fb0" or "fb" and not OMS anymore.

So, finaly we made it and the new fileserver is up and running.

All programs like dataviewer, dtt, EPICS extensions etc are now located in the "/opt" folder in the cvs directory. We just copied everything to there, so all historic stuff as well latest versions can be found there.

The home directories for all users are located in "/cvs/users" and the DAQ stuff can be found in "/cvs/cds". The cvs directory is mounted to "/cvs" on all machines.. Additional links for "/opt" and "/users"  exist in the root directories if each machine and point to the cvs directory.

PLEASE USE THE HOME DIRECTORIES TO STORE ANY DATA. This allows you to access it easily from each machine. Localy stored stuff willt be deleted if we have to change the disks in the workstations, e.g. we plan to exchange the disk in WS1 with a copy of the fresh installed stuff on WS2. So please check if there are files stored on WS1 localy. If yes and if you wish to keep them plz copy them to your home directory in /users.

Total size for the disks for home directories and installed software is 1TB (two 1TB disks as a RAID1), which should be plenty for the next couple of years.

The new machine is called "fb1" as it acts as a second framebuilder for slow channels in parallel to fb0, the old framebuilder running on the frontend. The configuration for that is located in "/cvs/cds/caltech/target/fb1" ,the configuration for fb0 is located in "/cvs/cds/caltech/target/fb". So don't mix it up. The config files for both framebuilders are in "/cvs/cds/caltech/chans/daq/", so be carefull when editing ! The reason for this is that the framebuilder configuration is different for each one, but the channel list is identical. So both fb access the same list of channels (same files) which makes it easier to keep it consistent. In addition individual channels (using seperate files) can be used to add channels. I will change the names for the current config files (EPICS channels) this week to make it more clear whats inside, e.g. i will create individual files for individual subsystems like the 35W laser, environmental monitoring and peters PSL stuff.

NO FAST, RT-CHANNELS ARE RECORDED BY FB1.

This is impossible as we don't have Myrinet running in the lab and so FB1 can't see those channels ! Only FB0 is storing fast channels!!

Frames are written to an independent 250G disk, which should last for about 2 years of full frames and trend data... we have to check the total amount of channels next month and then change the time for full frames stored in order to have more space for trend data...

Nothing has changed for the RT frontend except the new links for the NFS directories so far. We will replace the disks when the special cable arrives (hopefully this week)

installation specific code:  3JE2-6F8M3KH

Requestor: Brian Rounds
Customer Name: Frank Seifert
Company: California Institute of Technology
Phone: 626-395-3049
Email: seifert_f@ligo.caltech.edu
Install Specific Code: 3JE2-6F8M3KH
Activation Code: 25KG8LMI7
Date/Time: 10/22/2009 6:05:57 PM

error messages i received while starting fb1 yesterday. don't know how to fix it. restarting a couple of times even with only 1 channel doesn't help. alex is informed...

[Thu Oct 22 23:54:42 2009] ->3: start main 30
Thu Oct 22 23:54:42 2009 [4429]:Allocated move buffer size 263295 bytes
[Thu Oct 22 23:54:42 2009] main started
[Thu Oct 22 23:54:42 2009] ->3: start profiler
[Thu Oct 22 23:54:42 2009] ->3: # comment out this block to stop saving data
[Thu Oct 22 23:54:42 2009] frame saver started
[Thu Oct 22 23:54:42 2009] ->3: start frame-saver
[Thu Oct 22 23:54:43 2009] ->3: sync frame-saver
[Thu Oct 22 23:54:43 2009] ->3: start trender
[Thu Oct 22 23:54:43 2009] trender started
[Thu Oct 22 23:54:43 2009] trend frame saver started
[Thu Oct 22 23:54:43 2009] ->3: start trend-frame-saver
[Thu Oct 22 23:54:44 2009] ->3: sync trend-frame-saver
[Thu Oct 22 23:54:44 2009] ->3: # dont' need these
[Thu Oct 22 23:54:44 2009] ->3: #start minute-trend-frame-saver
[Thu Oct 22 23:54:44 2009] ->3: #sync minute-trend-frame-saver
[Thu Oct 22 23:54:44 2009] raw minute trend frame saver started
[Thu Oct 22 23:54:44 2009] ->3: start raw-minute-trend-saver
[Thu Oct 22 23:54:44 2009] ->3: #start frame-writer "225.225.225.1" broadcast="131.215.113.0" all
[Thu Oct 22 23:54:44 2009] ->3: #sleep 5
[Thu Oct 22 23:54:44 2009] producer started
[Thu Oct 22 23:54:44 2009] ->3: start producer
[Thu Oct 22 23:54:44 2009] ->3: start epics dcu
[Thu Oct 22 23:54:44 2009] edcu started
[Thu Oct 22 23:54:44 2009] ->3: start epics server "C0:DAQ-FB1_" "C2:DAQ-FB1_"
[Thu Oct 22 23:54:44 2009] epics server started
[Thu Oct 22 23:54:44 2009] ->3: start listener 8087
[Thu Oct 22 23:54:44 2009] ->3: start listener 8088 1
[Thu Oct 22 23:54:44 2009] ->3: sleep 60
[Thu Oct 22 23:54:44 2009] EDCU has 139 channels configured; first=0

[Thu Oct 22 23:54:44 2009] Epics server started
[Thu Oct 22 23:54:44 2009] Couldn't open `/rtl_mem__fb1_dummy_daq' read/write

epicsThreadOnceOsd epicsMutexLock failed.
*** glibc detected *** /cvs/cds/caltech/target/fb1/daqd: double free or corruption (out): 0x0000000013b94610 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3a9d671cec]
/lib64/libc.so.6(cfree+0x8c)[0x3a9d67590c]
/usr/local/lib/libframecpp8-1.so.14(_ZN9__gnu_cxx9hashtableISt4pairIKjN8FrameCPP11Compression13compress_typeEEjNS_4hashIjEESt10_S
elect1stIS6_ESt8equal_toIjESaIS6_EE5clearEv+0x3f)[0x2b9bec009f8f]
/usr/local/lib/libframecpp8-1.so.14[0x2b9bec002890]
/lib64/libc.so.6(__cxa_finalize+0x8e)[0x3a9d63363e]
/usr/local/lib/libframecpp8-1.so.14[0x2b9bebf534a6]
======= Memory map: ========
00400000-00473000 r-xp 00000000 09:00 23953923                           /cvs/cds/caltech/target/fb1/daqd
00673000-00675000 rw-p 00073000 09:00 23953923                           /cvs/cds/caltech/target/fb1/daqd
00675000-03497000 rw-p 00675000 00:00 0
13b0b000-13e8d000 rw-p 13b0b000 00:00 0                                  [heap]
400a5000-400a6000 ---p 400a5000 00:00 0
400a6000-400e6000 rw-p 400a6000 00:00 0
407ab000-407ac000 ---p 407ab000 00:00 0
407ac000-411ac000 rw-p 407ac000 00:00 0
414b8000-414b9000 ---p 414b8000 00:00 0
414b9000-414d9000 rw-p 414b9000 00:00 0
414d9000-414da000 ---p 414d9000 00:00 0
414da000-4151a000 rw-p 414da000 00:00 0
419e3000-419e4000 ---p 419e3000 00:00 0
419e4000-423e4000 rw-p 419e4000 00:00 0
423e4000-423e5000 ---p 423e4000 00:00 0
423e5000-42de5000 rw-p 423e5000 00:00 0
42de5000-42de6000 ---p 42de5000 00:00 0
42de6000-437e6000 rw-p 42de6000 00:00 0
437e6000-437e7000 ---p 437e6000 00:00 0
437e7000-441e7000 rw-p 437e7000 00:00 0
441e7000-441e8000 ---p 441e7000 00:00 0
441e8000-44be8000 rw-p 441e8000 00:00 0
44be8000-44be9000 ---p 44be8000 00:00 0
44be9000-455e9000 rw-p 44be9000 00:00 0
455e9000-455ea000 ---p 455e9000 00:00 0
455ea000-45fea000 rw-p 455ea000 00:00 0
45fea000-45feb000 ---p 45fea000 00:00 0
45feb000-469eb000 rw-p 45feb000 00:00 0
469eb000-469ec000 ---p 469eb000 00:00 0
469ec000-473ec000 rw-p 469ec000 00:00 0
473ec000-473ed000 ---p 473ec000 00:00 0
473ed000-47ded000 rw-p 473ed000 00:00 0
47ded000-47dee000 ---p 47ded000 00:00 0
47dee000-487ee000 rw-p 47dee000 00:00 0
487ee000-487ef000 ---p 487ee000 00:00 0
487ef000-491ef000 rw-p 487ef000 00:00 0
491ef000-491f0000 ---p 491ef000 00:00 0
491f0000-49bf0000 rw-p 491f0000 00:00 0
3a9c600000-3a9c61c000 r-xp 00000000 fd:00 17072132                       /lib64/ld-2.5.so
3a9c81b000-3a9c81c000 r--p 0001b000 fd:00 17072132                       /lib64/ld-2.5.so
3a9c81c000-3a9c81d000 rw-p 0001c000 fd:00 17072132                       /lib64/ld-2.5.so
3a9ca00000-3a9ca35000 r-xp 00000000 fd:00 39885243                       /usr/lib64/libreadline.so.5.1
3a9ca35000-3a9cc34000 ---p 00035000 fd:00 39885243                       /usr/lib64/libreadline.so.5.1
3a9cc34000-3a9cc3c000 rw-p 00034000 fd:00 39885243                       /usr/lib64/libreadline.so.5.1
3a9cc3c000-3a9cc3d000 rw-p 3a9cc3c000 00:00 0
3a9d600000-3a9d74c000 r-xp 00000000 fd:00 17072139                       /lib64/libc-2.5.so
3a9d74c000-3a9d94c000 ---p 0014c000 fd:00 17072139                       /lib64/libc-2.5.so
3a9d94c000-3a9d950000 r--p 0014c000 fd:00 17072139                       /lib64/libc-2.5.so
3a9d950000-3a9d951000 rw-p 00150000 fd:00 17072139                       /lib64/libc-2.5.so
3a9d951000-3a9d956000 rw-p 3a9d951000 00:00 0
3a9da00000-3a9da82000 r-xp 00000000 fd:00 17072143                       /lib64/libm-2.5.so
3a9da82000-3a9dc81000 ---p 00082000 fd:00 17072143                       /lib64/libm-2.5.so
3a9dc81000-3a9dc82000 r--p 00081000 fd:00 17072143                       /lib64/libm-2.5.so
3a9dc82000-3a9dc83000 rw-p 00082000 fd:00 17072143                       /lib64/libm-2.5.so
3a9de00000-3a9de02000 r-xp 00000000 fd:00 17072145                       /lib64/libdl-2.5.so
3a9de02000-3a9e002000 ---p 00002000 fd:00 17072145                       /lib64/libdl-2.5.so
3a9e002000-3a9e003000 r--p 00002000 fd:00 17072145                       /lib64/libdl-2.5.so
3a9e003000-3a9e004000 rw-p 00003000 fd:00 17072145                       /lib64/libdl-2.5.so
3a9e200000-3a9e216000 r-xp 00000000 fd:00 17072149                       /lib64/libpthread-2.5.so
3a9e216000-3a9e415000 ---p 00016000 fd:00 17072149                       /lib64/libpthread-2.5.so
3a9e415000-3a9e416000 r--p 00015000 fd:00 17072149                       /lib64/libpthread-2.5.so
3a9e416000-3a9e417000 rw-p 00016000 fd:00 17072149                       /lib64/libpthread-2.5.so
3a9e417000-3a9e41b000 rw-p 3a9e417000 00:00 0
3a9e600000-3a9e614000 r-xp 00000000 fd:00 39883979                       /usr/lib64/libz.so.1.2.3
3a9e614000-3a9e813000 ---p 00014000 fd:00 39883979                       /usr/lib64/libz.so.1.2.3
3a9e813000-3a9e814000 rw-p 00013000 fd:00 39883979                       /usr/lib64/libz.so.1.2.3
3aa1e00000-3aa1e07000 r-xp 00000000 fd:00 17072167                       /lib64/librt-2.5.so
3aa1e07000-3aa2007000 ---p 00007000 fd:00 17072167                       /lib64/librt-2.5.so
3aa2007000-3aa2008000 r--p 00007000 fd:00 17072167                       /lib64/librt-2.5.so
3aa2008000-3aa2009000 rw-p 00008000 fd:00 17072167                       /lib64/librt-2.5.so
3aa3200000-3aa320d000 r-xp 00000000 fd:00 17072153                       /lib64/libgcc_s-4.1.2-20080825.so.1
3aa320d000-3aa340d000 ---p 0000d000 fd:00 17072153                       /lib64/libgcc_s-4.1.2-20080825.so.1
3aa340d000-3aa340e000 rw-p 0000d000 fd:00 17072153                       /lib64/libgcc_s-4.1.2-20080825.so.1
3aa3a00000-3aa3ae6000 r-xp 00000000 fd:00 39883774                       /usr/lib64/libstdc++.so.6.0.8
3aa3ae6000-3aa3ce5000 ---p 000e6000 fd:00 39883774                       /usr/lib64/libstdc++.so.6.0.8
3aa3ce5000-3aa3ceb000 r--p 000e5000 fd:00 39883774                       /usr/lib64/libstdc++.so.6.0.8
3aa3ceb000-3aa3cee000 rw-p 000eb000 fd:00 39883774                       /usr/lib64/libstdc++.so.6.0.8
3aa3cee000-3aa3d00000 rw-p 3aa3cee000 00:00 0
3aa6800000-3aa6815000 r-xp 00000000 fd:00 17072457                       /lib64/libnsl-2.5.so
3aa6815000-3aa6a14000 ---p 00015000 fd:00 17072457                       /lib64/libnsl-2.5.so
3aa6a14000-3aa6a15000 r--p 00014000 fd:00 17072457                       /lib64/libnsl-2.5.so
3aa6a15000-3aa6a16000 rw-p 00015000 fd:00 17072457                       /lib64/libnsl-2.5.so
3aa6a16000-3aa6a18000 rw-p 3aa6a16000 00:00 0
3aa7000000-3aa712d000 r-xp 00000000 fd:00 17072195                       /lib64/libcrypto.so.0.9.8e
3aa712d000-3aa732c000 ---p 0012d000 fd:00 17072195                       /lib64/libcrypto.so.0.9.8e
3aa732c000-3aa734d000 rw-p 0012c000 fd:00 17072195                       /lib64/libcrypto.so.0.9.8e
3aa734d000-3aa7351000 rw-p 3aa734d000 00:00 0
3ab0000000-3ab004e000 r-xp 00000000 fd:00 39888487                       /usr/lib64/libncurses.so.5.5
3ab004e000-3ab024e000 ---p 0004e000 fd:00 39888487                       /usr/lib64/libncurses.so.5.5
3ab024e000-3ab025c000 rw-p 0004e000 fd:00 39888487                       /usr/lib64/libncurses.so.5.5
3ab025c000-3ab025d000 rw-p 3ab025c000 00:00 0
3ab1000000-3ab100f000 r-xp 00000000 fd:00 39888455                       /usr/lib64/libbz2.so.1.0.3
3ab100f000-3ab120e000 ---p 0000f000 fd:00 39888455                       /usr/lib64/libbz2.so.1.0.3
3ab120e000-3ab1210000 rw-p 0000e000 fd:00 39888455                       /usr/lib64/libbz2.so.1.0.3
2aaaaaaab000-2aaab23aa000 rw-p 2aaaaaaab000 00:00 0
2aaab23d7000-2aaab23e1000 r-xp 00000000 fd:00 17072154                   /lib64/libnss_files-2.5.so
2aaab23e1000-2aaab25e0000 ---p 0000a000 fd:00 17072154                   /lib64/libnss_files-2.5.so
2aaab25e0000-2aaab25e1000 r--p 00009000 fd:00 17072154                   /lib64/libnss_files-2.5.so
2aaab25e1000-2aaab25e2000 rw-p 0000a000 fd:00 17072154                   /lib64/libnss_files-2.5.so
2aaab4000000-2aaab4042000 rw-p 2aaab4000000 00:00 0
2aaab4042000-2aaab8000000 ---p 2aaab4042000 00:00 0
2b9bea8d8000-2b9bea8d9000 rw-p 2b9bea8d8000 00:00 0
2b9bea906000-2b9bea907000 rw-p 2b9bea906000 00:00 0
2b9bea907000-2b9bea965000 r-xp 00000000 09:00 21545637                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libca.so
2b9bea965000-2b9beab65000 ---p 0005e000 09:00 21545637                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libca.so
2b9beab65000-2b9beab6a000 rw-p 0005e000 09:00 21545637                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libca.so
2b9beab6a000-2b9beabac000 r-xp 00000000 09:00 21545612                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libcas.so
2b9beabac000-2b9beadac000 ---p 00042000 09:00 21545612                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libcas.so
2b9beadac000-2b9beadb0000 rw-p 00042000 09:00 21545612                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libcas.so
2b9beadb0000-2b9beadb8000 r-xp 00000000 09:00 21545635                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libasHost
.so
2b9beadb8000-2b9beafb8000 ---p 00008000 09:00 21545635                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libasHost
.so
2b9beafb8000-2b9beafb9000 rw-p 00008000 09:00 21545635                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libasHost
.so
2b9beafb9000-2b9beafbb000 rw-p 2b9beafb9000 00:00 0
2b9beafbb000-2b9beb006000 r-xp 00000000 09:00 21545613                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libCom.so
2b9beb006000-2b9beb205000 ---p 0004b000 09:00 21545613                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libCom.so
2b9beb205000-2b9beb20a000 rw-p 0004a000 09:00 21545613                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libCom.so
2b9beb20a000-2b9beb232000 r-xp 00000000 09:00 21545603                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libgdd.so
2b9beb232000-2b9beb431000 ---p 00028000 09:00 21545603                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libgdd.so
2b9beb431000-2b9beb433000 rw-p 00027000 09:00 21545603                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libgdd.so
2b9beb433000-2b9beb453000 r-xp 00000000 09:00 21545636                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/librecIoc
.so
2b9beb453000-2b9beb652000 ---p 00020000 09:00 21545636                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/librecIoc
.so
2b9beb652000-2b9beb654000 rw-p 0001f000 09:00 21545636                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/librecIoc
.so
2b9beb654000-2b9beb655000 rw-p 2b9beb654000 00:00 0
2b9beb655000-2b9beb659000 r-xp 00000000 09:00 21545624                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libsoftDe
vIoc.so
2b9beb659000-2b9beb859000 ---p 00004000 09:00 21545624                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libsoftDe
vIoc.so
2b9beb859000-2b9beb85a000 rw-p 00004000 09:00 21545624                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libsoftDe
vIoc.so
2b9beb85a000-2b9beb86f000 r-xp 00000000 fd:00 29491230                   /usr/local/lib/libtestpoint.so
2b9beb86f000-2b9beba6e000 ---p 00015000 fd:00 29491230                   /usr/local/lib/libtestpoint.so
2b9beba6e000-2b9beba6f000 r--p 00014000 fd:00 29491230                   /usr/local/lib/libtestpoint.so
2b9beba6f000-2b9beba70000 rw-p 00015000 fd:00 29491230                   /usr/local/lib/libtestpoint.so
2b9beba70000-2b9beba7e000 rw-p 2b9beba70000 00:00 0
2b9beba7e000-2b9bebadb000 r-xp 00000000 fd:00 39892684                   /usr/local/lib/libgeneral-1.so.14.0.0
2b9bebadb000-2b9bebcda000 ---p 0005d000 fd:00 39892684                   /usr/local/lib/libgeneral-1.so.14.0.0
2b9bebcda000-2b9bebcdd000 rw-p 0005c000 fd:00 39892684                   /usr/local/lib/libgeneral-1.so.14.0.0
2b9bebcdd000-2b9bebcde000 rw-p 2b9bebcdd000 00:00 0
2b9bebcde000-2b9bebce0000 r-xp 00000000 fd:00 29491225                   /usr/local/lib/libframecpp-1.so.14.0.0
2b9bebce0000-2b9bebedf000 ---p 00002000 fd:00 29491225                   /usr/local/lib/libframecpp-1.so.14.0.0
2b9bebedf000-2b9bebee0000 rw-p 00001000 fd:00 29491225                   /usr/local/lib/libframecpp-1.so.14.0.0
2b9bebee0000-2b9bebee3000 rw-p 2b9bebee0000 00:00 0
2b9bebee3000-2b9bec048000 r-xp 00000000 fd:00 29491220                   /usr/local/lib/libframecpp8-1.so.14.0.0
2b9bec048000-2b9bec247000 ---p 00165000 fd:00 29491220                   /usr/local/lib/libframecpp8-1.so.14.0.0
2b9bec247000-2b9bec251000 rw-p 00164000 fd:00 29491220                   /usr/local/lib/libframecpp8-1.so.14.0.0
2b9bec251000-2b9bec2f4000 r-xp 00000000 fd:00 29491215                   /usr/local/lib/libframecpp7-1.so.14.0.0
2b9bec2f4000-2b9bec4f3000 ---p 000a3000 fd:00 29491215                   /usr/local/lib/libframecpp7-1.so.14.0.0
2b9bec4f3000-2b9bec4f9000 rw-p 000a2000 fd:00 29491215                   /usr/local/lib/libframecpp7-1.so.14.0.0
2b9bec4f9000-2b9bec61f000 r-xp 00000000 fd:00 29491210                   /usr/local/lib/libframecpp6-1.so.14.0.0
2b9bec61f000-2b9bec81f000 ---p 00126000 fd:00 29491210                   /usr/local/lib/libframecpp6-1.so.14.0.0
2b9bec81f000-2b9bec826000 rw-p 00126000 fd:00 29491210                   /usr/local/lib/libframecpp6-1.so.14.0.0
2b9bec826000-2b9bec827000 rw-p 2b9bec826000 00:00 0
2b9bec827000-2b9bec915000 r-xp 00000000 fd:00 29491205                   /usr/local/lib/libframecpp4-1.so.14.0.0
2b9bec915000-2b9becb15000 ---p 000ee000 fd:00 29491205                   /usr/local/lib/libframecpp4-1.so.14.0.0
2b9becb15000-2b9becb1b000 rw-p 000ee000 fd:00 29491205                   /usr/local/lib/libframecpp4-1.so.14.0.0
2b9becb1b000-2b9becbbf000 r-xp 00000000 fd:00 39899156                   /usr/local/lib/libframecpp3-1.so.14.0.0
2b9becbbf000-2b9becdbe000 ---p 000a4000 fd:00 39899156                   /usr/local/lib/libframecpp3-1.so.14.0.0
2b9becdbe000-2b9becdc3000 rw-p 000a3000 fd:00 39899156                   /usr/local/lib/libframecpp3-1.so.14.0.0
2b9becdc3000-2b9bece34000 r-xp 00000000 fd:00 39899151                   /usr/local/lib/libframecppcmn-1.so.14.0.0
2b9bece34000-2b9bed033000 ---p 00071000 fd:00 39899151                   /usr/local/lib/libframecppcmn-1.so.14.0.0
2b9bed033000-2b9bed037000 rw-p 00070000 fd:00 39899151                   /usr/local/lib/libframecppcmn-1.so.14.0.0
2b9bed037000-2b9bed03a000 rw-p 2b9bed037000 00:00 0
2b9bed03a000-2b9bed050000 r-xp 00000000 09:00 21545618                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libdbStat
icHost.so
2b9bed050000-2b9bed250000 ---p 00016000 09:00 21545618                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libdbStat
icHost.so
2b9bed250000-2b9bed251000 rw-p 00016000 09:00 21545618                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libdbStat
icHost.so
2b9bed251000-2b9bed253000 rw-p 2b9bed251000 00:00 0
2b9bed253000-2b9bed25e000 r-xp 00000000 09:00 21545633                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libasIoc.
so
2b9bed25e000-2b9bed45e000 ---p 0000b000 09:00 21545633                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libasIoc.
so
2b9bed45e000-2b9bed45f000 rw-p 0000b000 09:00 21545633                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libasIoc.
so
2b9bed45f000-2b9bed461000 rw-p 2b9bed45f000 00:00 0
2b9bed461000-2b9bed499000 r-xp 00000000 09:00 21545611                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libdbIoc.
so
2b9bed499000-2b9bed698000 ---p 00038000 09:00 21545611                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libdbIoc.
so
2b9bed698000-2b9bed69b000 rw-p 00037000 09:00 21545611                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libdbIoc.
so
2b9bed69b000-2b9bed69d000 rw-p 2b9bed69b000 00:00 0
2b9bed69d000-2b9bed69f000 r-xp 00000000 09:00 21545630                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libregist
ryIoc.so
2b9bed69f000-2b9bed89e000 ---p 00002000 09:00 21545630                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libregist
ryIoc.so
2b9bed89e000-2b9bed89f000 rw-p 00001000 09:00 21545630                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libregist
ryIoc.so
2b9bed89f000-2b9bed8b6000 r-xp 00000000 09:00 21545617                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libdbStat
icIoc.so
2b9bed8b6000-2b9bedab5000 ---p 00017000 09:00 21545617                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libdbStat
icIoc.so
2b9bedab5000-2b9bedab7000 rw-p 00016000 09:00 21545617                   /cvs/opt/epics-3.14.9-linux/base/lib/linux-x86/libdbStat
icIoc.so
2b9bedab7000-2b9bedabc000 rw-p 2b9bedab7000 00:00 0
7fff46f68000-7fff46f7d000 rw-p 7ffffffea000 00:00 0                      [stack]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0                  [vdso]

alex fixed it and so fb1 is now online again...

We exchanged the hard drives in the FE this week and also updated the RT Kernel and other software on this machine. It's running the latest RT Kernel without the Myrinet stuff now so we removed that card from the computer too.

The FB running on this machine has now two 1.5TB drives for the frames. The first drive contains the full frames, the other the trend data. This should be enough space for the next years. The drives are mounted to the individual directories where the stuff is saved. As the new FB creates all the directories the configuration of the directory structure for the FB is now obsolete, but still in the config file! The only important number is the number of files written to each directory...Two independent cron jobs take care about the usage of the disk space. If the amount of total data exceeds a certain value (95% at the moment) the oldest files are deleted. Logfiles are located in "../target/fb/" and called "wiper.log" and "wiper_trend.log". Right now the status is:

Fri Oct 30 12:25:01 PDT 2009

TREND DATA:

Directory disk usage:
/frames/trend/minute_raw 560400k
/frames/trend/second 414056k
Combined 974456k or 951m or 0Gb

/frames/trend size 1442145212k at 0.07%
/frames/trend is below keep value of 95.00%
Will not delete any files
df reported usage 0.08%

FULL FRAMES:

Directory disk usage:
/frames/full 46696012k
Combined 46696012k or 45601m or 44Gb

/frames/full size 1442145212k at 3.24%
/frames/full is below keep value of 95.00%
Will not delete any files
df reported usage 3.25%

We will check the data amount next week in order to estimate the time we have available for full frames (and trend data)...

Same is done for the second FB (FB1). Status here is:

Fri Oct 30 12:05:01 PDT 2009

Directory disk usage:
/frames/trend/minute_raw 78996k
/frames/trend/second 3486564k
/frames/full 2386628k
Combined 5952188k or 5812m or 5Gb

/frames size 241263968k at 2.47%
/frames is below keep value of 98.00%
Will not delete any files
df reported usage 2.55%

i checked the log-files of the wiper job with everything running now (all channels active, testpoints active etc).

FB0 (RT-stuff+EPICS) uses 1428MB per hour for full data and 11MB for trend data. So we should have space for about 40days of full data and 14years of trend data :-) So i think we can replace the large disk for trends by a smaller one if we need a larger one somewhere else...

FB1 (only EPICS) has currently more EPICS channels as FB1 as it saves the 10W MOPA channels too (peters lab). The amount of data is very small compared to FB0 as all channels are only sampled with 16Hz. Something is wrong with the wiper cron job here. The data given in the log file does not match current disk usage so i will check this with alex on monday...

here an updated version of the network schematic. Some upcoming changes are already integrated, e.g. the fiber to peter's lab. This will be probably installed on monday. The video server device might be installed next week as well. More details on this soon.

devices which have more than one network connected are marked with two (different) colored IP addresses. 10.0.0.xxx is peters network, 10.0.1.xxx is the ATF network

.

This from Alex on the 16 Hz comb I was seeing pop up in my test points:

Looks like you can have 3 testpoint and that's it! Selecting one more
takes you over the limit.

I guess we need to redefine our limits.

Make sure there are no stuck testpoints or you would get junk. Watch for
DAQ+TP rate to be under 2000.

There are now four "sites" in data viewer. [C, C2, C3, C4].

This needs to be fixed. C1 = 40m, C2 = ATF. We need to settle on whether the PSL and TCS labs are the same site and should be identified by subsystem names or are totally different Caltech sites.

"C" by itself is not an acceptable name.

 I think that you should be able to see C1 in your dataviewer.  This should be fixed if you can't see our channels (I assume the same fix will let us see your channels since right now the 40m only gets C1's).

"C" alone appears to be a grandfathered in name, from back in the day when the PSL lab was the only place with channels.  So C = C3 = PSL lab. Maybe this should change, but it could be a pain depending on how much stuff from how many years has this naming convention. Elog 412 hashes out the all-C2 vs several different C's situation.