3/30
CVS web
http://bicep0.caltech.edu/cgi-bin/cvsweb/cvsweb.cgi/gcp/3/31
Computer Names at Caltech
The computers in the high bay have been renamed to make them clearly distinct
from the bicep analysis cluster in Bridge. From now on, numbers 0-19 are
reserved for Bridge, and 30-39 for the high bay. Specific machines:
* bicep34, formerly bicep4, is the primary MCE computer
* bicep31, formerly bicep1, is the GCP development machine
* bicep33, formerly bicep3, is the Dell desktop machine on the desk in the southeast corner
* bicep2 is the new machine from Chicago, used for the test MCE crate.
Trace data frame handling in Control Layer
control/code/unix/control_src/common/
genericcontrol.c
Program::main() {
ControlProg* cp;
cp = new_ControlProg(
...
cp_event_loop(cp);
}
static ControlProg* new_ControlProg(std::string startupScript) {
initialize everything to NULL or 0;
for(i=0; i
t->type = thread_table + i;
cp->arraymap = new_Arraymap();
cp->pipe = new_PipeChan(...) // shutdown message pipe
}
static int cp_event_loop(ControlProg* cp); {
nready = select(...);
case -1:
error
default:
If an active channel is found, call its I/O method.
check for connection requests on the control-server port
}
struct ControlProg {
ArrayMap* arraymap
PipeChan* pipe
CpThread thread[NTHREAD]
RtController* rtc
RtScanner* rts
RtoptCam* rto
MonitorServer* ms
ImMonitorServer* ims
ControlServer* cs
ComList active_list
fd_set read_fds
fd_set send_fds
int fd_set_size
CpWhatNext whatnext
gcp::util::AntNum defaultAntSet
std::string* startupScript_
}
static CpThreadType thread_table[] = {
{CP_SCHEDULER, ...
{CP_ARCHIVER, ...
{CP_LOGGER, ...
{CP_NAVIGATOR, ...
{CP_GRABBER, ...
{CP_TERM, ...
}
enum {NTHREAD = sizeof(thread_table)/sizeof(thread_table[0])}
typdedf struct {
CpThreadType* type
PipeChan* pipe
void* state
pthread_t thread
int running
} CpThread;
typedef struct {
CpThreadId id
CP_NEW_FN(* new_fn)
CP_DEL_FN(* del_fn)
CP_THREAD_FN(* start_fn)
CP_STOP_FN(* stop_fn)
PIPE_SENT_FN(* sent_fn)
size_t sizeof_message
} CpThreadType;
genericcontrol.h
4/1
Tracing data frame handling in Control Layer (continued)
genericcontrol.c
structs
- ControlProg
- RtScanner
- SockChan
- MonitorClient
- MonitorServer
- ImMonitorServer
- CpThread
- ComHead
- ComAspect
- RtController
- ControlServer
struc ControlProg {
ArrayMap* arraymap
PipeChan* pipe
CpThread thread[NTHREAD]
RtController* rtc
RtScanner* rts
RtoptCam* rto
MonitorServer* ms
ImMonitorServer* ims
ControlServer* cs
ComList active_list
fd_set read_fds
fd_set send_fds
int fd_set_size
CpWhatNext whatnext
gcp::util::AntNum defaultAntSet
std::string* startupScript_
}
typedef struct {
int port
SockChan* sock
RegRawData* frame // The latest frame
} RtScanner
new_RtScanner(* cp, * arraympa) {
}
struct SockChan {
ComHeader head
SOCK_RCVD_FN(* rcvd_fn)
SOCK_SENT_FN(* sent_fn)
SOCK_COND_FN(* cond_fn)
gcp::control::NetReaderStr* nrs
gcp::control::NetSendStr* nss
}
typdef struct { // An object to record the resources of an external monitor client
SockChan* sock
MonitorState state // enum
RegSet* regset
unsigned interval // sampling interval
unsigned dropped
} MonitorClient
typedef struct {
int port // port on which to listen for clients
int nss_size
int nrs_size
MonitorClient clients[MONITOR_CLIENTS]
} MonitorServer
typdedf struct {
CpThreadType* type
PipeChan* pipe
void* state
pthread_t thread
int running
} CpThread;
struct ComHeader {
ChanType type
void* client_data
ComAspect read
ComAspect write
}
struct ComAspect {
ComHeader* parent
int fd
fd_set* active_set
CHAN_IO_FN(* io_fn)
ComAspect* next
ComAspect* prev
}
typedef struct {
int port
SockChan* sock
PipeChan* pipe
struct status {
pthread_mutex_t guard
int guard_ready
int online }
} RtController
static SOCK_RCVD_FN(rts_rcvd_fn) {
}
gcp/control/code/unix/libunix_src/common/
regdata.c
structs
- RegRawData
typedef struc {
unsigned nslot // the number of elements in slots[]
int* slots // the array of monitored registers
gcp::util::ArrayDataFrameManager* fm
} RegRawData
cp->rts is the RtScanner
rts->frame is a RegRawData struct
frame->fm is an ArrayDataFrameManager
check:
rts_rcvd_fn
ini_CommHeader(...)
4/2
Continue above.
new ControlProg -->
new RtScanner -->
rts->sock = new_SockChan(..., rts_rcvd_fn, rts_sent_fn, rts_cond_fn)
cp_event_loop() -->
SOCK_RCVD_FN(rts_rcvd_fn)
// read the frame
// write frame to Monitor Clients
add_writable_channel(cp, &(cp->ms->clients+i->sock->head) )
(&cp->active_list)->tail = &head->write
// This adds the write ComAspect of a MonitorClient
cp_event_loop() -->
ComAspect chan = cp->active_list.head
// Call MonitorClient->sock->head->write->io_fn = sock_write_fn
chan->io_fn(cp, chan->parent) -->
CHAN_IO_FN(sock_write_fn) -->
switch( nss_send_msg(sock->nss)) ) --> // calls fn from control/code/unix/libunix_src/common/netbuf.c
// should return NET_SEND_DONE
case NetSendStr::NET_SEND_DONE:
sock->sent_fn(cp, sock) -->
SOCK_SENT_FN(mc_sent_fn) -->
// for normal operation
client->state = MC_SENDING_REGS
close_socket_channel(cp, sock, SOCK_ERROR)
Location:
control/code/unix/control_src/common/archiver.h, .c
struct Archiver {
ControlProg* cp
gcp::util::Pipe* pipe
ListMemory* list_mem
List* clients
CcPipeMsg ccmsg
char* dir
char* path
FILE* fp
FrameBuffer fb
bcp::control::NetBuf* net
int filter
int file_size
int nrecorded
struct tv_offset
gcp::control::ArchiverWriter* writer_
}
// This is the entry ponit of the archiver thread
CP_THREAD_FN(archiver_ thread) {
Archiver* arc = (Archiver* ) arg;
ArchiverMessage msg;
select(...)
...
}
4/3
Check out gcp onto find
$ cvs -d bicep0.caltech.edu:/home/bicep0/cvsroot checkout gcp32 Mb of source code.
Hello, World! Mex
Write a mex program:
#include "mex.h"
void mexFunction(int nlhs, mxArray *plhs[],
int nrhs, const mxArray *prhs[]) {
mexPrintf("Hello, world!\n");
}
tell Matlab which compiler to use:
$ mex -setup
The options files available for mex are:
2: /usr/local/matlab7p3/bin/gccopts.sh :
Template Options file for building gcc MEX-files
2
compile:
mex hello.crun:
$ matlab >> hello Hello, world! >> exitWahoo!!
Matlab Arcfile reader
gcp/matlab/common/matReadArc.cc
1) gcp/matlab/common/matReadArc.cc
compile this.
This gets compiled using a special compiler "mex" which is provided with
Matlab to make file matReadArc.mexa64.
2) run matlab and check it links in by invoking the command.
3) Upgrade to teh new super fast version of the reader which Erik recently upgraded spt and sza to. This appears ty be:
/home/sptdaq/gcpDeployMerge/gcp/matlab/common/bin_MatReadArcOpt.cc
which compiles to sptMatReadArcOpt.mexa64
1):
on find (which has matlab), try:
$ make Executing depend rule cc -I/usr/local/matlab7p2/extern/include/ /usr/local/matlab7p3/extern/include/ -MM matReadArc.cc MexParser.cc > Makefile.rules matReadArc.cc:62:37: gcp/util/common/Monitor.h: No such file or directory matReadArc.cc:67:35: gcp/util/common/Debug.h: No such file or directory matReadArc.cc:68:44: gcp/util/common/RegDescription.h: No such file or directory matReadArc.cc:69:39: gcp/util/common/RegParser.h: No such file or directory MexParser.cc:3:41: gcp/matlab/common/MexParser.h: No such file or directory MexParser.cc:5:39: gcp/util/common/Exception.h: No such file or directory MexParser.cc:6:39: gcp/util/common/LogStream.h: No such file or directory make: *** [depend] Error 1
$ locate "/mex.h"
/usr/local/matlab7p2/extern/include/mex.h
/usr/local/matlab7p3/extern/include/mex.h
$ make Executing depend rule echo "MATINC is " -I/usr/local/matlab7p2/extern/include/ /usr/local/matlab7p3/extern/include/ MATINC is -I/usr/local/matlab7p2/extern/include/ /usr/local/matlab7p3/extern/include/ cc -I/usr/local/matlab7p2/extern/include/ /usr/local/matlab7p3/extern/include/ -c MexParser.cc MexParser.cc:3:41: gcp/matlab/common/MexParser.h: No such file or directory MexParser.cc:5:39: gcp/util/common/Exception.h: No such file or directory MexParser.cc:6:39: gcp/util/common/LogStream.h: No such file or directory MexParser.cc:10: error: `gcp' has not been declared MexParser.cc:10: error: `matlab' is not a namespace-name ...
on find:
/home/sptdaq/spt_analysis/archive/read_arc.m
http://www.mathworks.com/support/tech-notes/1600/1605.html
he next step is to tell MATLAB which compiler you want to use to build the MEX-file. You do this with the mex -setup command. You can choose the LCC compiler, the C compiler included with MATLAB. This is what it looks like from the MATLAB command prompt:
$ mex -setup
The options files available for mex are:
2: /usr/local/matlab7p3/bin/gccopts.sh :
Template Options file for building gcc MEX-files
2
Try to compile:
$ mex matReadArc.cc matReadArc.cc:62:37: gcp/util/common/Monitor.h: No such file or directory ...
It is not finding the directories properly.
/home/kstory/gcp/util/common/Monitor.h
$ mex matReadArc.cc -I/home/kstory/ -I/home/kstory/gcp/control/code/unix/libunix_src/common/
I got a file called matReadArc.mexa64 !!
tcaswell: that is matlab
you need to make a simlink someplace that points g++ at a version in its range
matlab ships with its own c libraries
which are what the mex files are run against
so you need to use the one it likes
copy read_arc.m from spt:
/home/sptdaq/spt_analysis/archive/read_arc.m
Try to run:
>> regs={'array.frame.utc'}
>> d=read_arc(regs,'09-Feb-2006:22:05:00','09-Feb-2006:22:25:00')
??? Undefined command/function 'read_arc_matlab'.
Error in ==> read_arc at 56
data = read_arc_matlab(regs, start, finish, arcdir, calfile);
kstory@spt:~> cd /home/sptdaq/gcpDeployMerge/gcp/matlab/common/
kstory@spt:common> ls
bin_MatReadArc.cc MatArchiveConvFn.cc MexHandler.o sptMatReadArc.mexa64*
bin_MatReadArcOpt.cc MatArchiveConvFn.h MexParser.cc sptMatReadArcOpt.mexa64*
bin_MatRefrac.cc MatArchiveConvFn.o MexParser.h sptMatRefrac.mexa64*
Makefile MexHandler.cc MexParser.h~
Makefile.rules MexHandler.h MexParser.o
4/6
Review:
working on find.
In gcp/matlab/common/
- matReadArc.cc was compiled using mex
- copied read_arc.m
- Need function read_arc_matlab to be on the Matlab path
Talk with Clem:
- ldd shows which libraries are linked to something
- >> path shows the matlab path
- Add things to the matlab path with ~/matlab/startup.m
I copied Clem's startup.m file into my ~/matlab/ directory
- sptMatReadArcOpt.mexa64 is most up-to-date reader
In read_arc.m:
- change read_arc_matlab(...) to whatever is in matReadArc(...)
- change arcdir
- change cal file
Try running:
>> clear
>> regs={'array.frame.utc'};
>> d=read_arc(regs,'06-Apr-2009:14:20:57','06-Apr-2009:14:21:00')
??? Invalid MEX-file '/home/kstory/gcp/matlab/common/matReadArc.mexa64': /home/kstory/gcp/matlab/common/matReadArc.mexa64: undefined symbol: _ZTVN3gcp4util9CoordAxesE.
Error in ==> read_arc at 57
data=matReadArc(regs,start,finish,arcdir,calfile);
Hmm, not sure what is going on here.
Copy over newer files:
/home/eml/gcp/matlab/common/
Not sure that will work.
Try this:
kstory@find:common/$ mex -v matReadArc.cc -I/home/kstory/ -I/home/kstory/gcp/control/code/unix/libunix_src/common/
-> mexopts.sh sourced from directory (DIR = $HOME/.matlab/$REL_VERSION)
FILE = /home/kstory/.matlab/R14SP3/mexopts.sh
----------------------------------------------------------------
-> MATLAB = /usr/local/matlab7p3
-> CC = gcc
-> CC flags:
CFLAGS = -fPIC -fno-omit-frame-pointer -ansi -D_GNU_SOURCE -pthread -fexceptions
CDEBUGFLAGS = -g
COPTIMFLAGS = -O -DNDEBUG
CLIBS = -Wl,-rpath-link,/usr/local/matlab7p3/bin/glnxa64 -L/usr/local/matlab7p3/bin/glnxa64 -lmx -lmex -lmat -lm -lm -lstdc++
arguments =
-> CXX = g++
-> CXX flags:
CXXFLAGS = -fPIC -fno-omit-frame-pointer -ansi -D_GNU_SOURCE -pthread
CXXDEBUGFLAGS = -g
CXXOPTIMFLAGS = -O -DNDEBUG
CXXLIBS = -Wl,-rpath-link,/usr/local/matlab7p3/bin/glnxa64 -L/usr/local/matlab7p3/bin/glnxa64 -lmx -lmex -lmat -lm -lm
arguments =
-> FC = g77
-> FC flags:
FFLAGS = -fPIC -fno-omit-frame-pointer -fexceptions
FDEBUGFLAGS = -g
FOPTIMFLAGS = -O
FLIBS = -Wl,-rpath-link,/usr/local/matlab7p3/bin/glnxa64 -L/usr/local/matlab7p3/bin/glnxa64 -lmx -lmex -lmat -lm -lm -lstdc++
arguments =
-> LD = g++
-> Link flags:
LDFLAGS = -pthread -shared -Wl,--version-script,/usr/local/matlab7p3/extern/lib/glnxa64/mexFunction.map
LDDEBUGFLAGS = -g
LDOPTIMFLAGS = -O
LDEXTENSION = .mexa64
arguments =
-> LDCXX =
-> Link flags:
LDCXXFLAGS =
LDCXXDEBUGFLAGS =
LDCXXOPTIMFLAGS =
LDCXXEXTENSION =
arguments =
----------------------------------------------------------------
-> g++ -c -I/home/kstory/ -I/home/kstory/gcp/control/code/unix/libunix_src/common/ -I/usr/local/matlab7p3/extern/include -I/usr/local/matlab7p3/simulink/include -DMATLAB_MEX_FILE -fPIC -fno-omit-frame-pointer -ansi -D_GNU_SOURCE -pthread -O -DNDEBUG matReadArc.cc
In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/backward/iostream.h:31,
from matReadArc.cc:64:
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <iostream> instead of the deprecated header <iostream.h>. To disable this warning use -Wno-deprecated.
-> gcc -c -I/home/kstory/ -I/home/kstory/gcp/control/code/unix/libunix_src/common/ -I/usr/local/matlab7p3/extern/include -I/usr/local/matlab7p3/simulink/include -DMATLAB_MEX_FILE -fPIC -fno-omit-frame-pointer -ansi -D_GNU_SOURCE -pthread -fexceptions -O -DNDEBUG /usr/local/matlab7p3/extern/src/mexversion.c
-> g++ -O -pthread -shared -Wl,--version-script,/usr/local/matlab7p3/extern/lib/glnxa64/mexFunction.map -o matReadArc.mexa64 matReadArc.o mexversion.o -Wl,-rpath-link,/usr/local/matlab7p3/bin/glnxa64 -L/usr/local/matlab7p3/bin/glnxa64 -lmx -lmex -lmat -lm -lm
Looking at: spt:/eml/archive/
README
This directory is intended to store tools for reading (and maybe writing?) SPT archive files. ---------------------------------------------------------------------- Files in this directory that are part of the archive reader package: Makefile read_arc.cc contains functions for extracting data read_arc.h read_arc_idl.c idl wrapper read_arc_idl.dlm stuff needed to make an IDL DLM read_arc_idl.export more stuff needed to make an IDL DLM read_arc.m matlab user interface function read_arc_matlab.cc matlab wrapper code read_arc.pro idl user interface function README *N.B. this code uses the spt GCP libraries and the spt_analysis util libraries. See spt_analysis/README for environment variable settings that you need for compiling and running it. --------------------------------------------------------------------- COMPILING INSTRUCTIONS: The Makefile by default assumes that Matlab is installed on the computer (I'll change that if needed). But it doesn't assume that IDL is installed. The Makefile will build a C library and a matlab reader, and optionally an IDL reader if you have an IDL environment variable pointing to an installation of IDL on your machine. For the code to compile, you will need some environment variables to be set. See the spt_analysis/README file for a list. To run the IDL reader you will also need to set up some IDL environment variables that are also specified in that file. If you are using recent versions of matlab, you may also need to set an environment variable pointing to the gcc libraries: setenv LD_PRELOAD /lib/libgcc_s.so.1
Copy over files from:
/home/eml/archive/
> tar -cvf ~/emlTar1.tar read_arc.h read_arc.cc read_arc_matlab.cc README Makefile read_arc.m
into kstory/archive/
$ make ERROR: ld.so: object '/lib/libgcc_s.so.1' from LD_PRELOAD cannot be preloaded: ignored. ... In file included from read_arc.cc:1: read_arc.h:19:28: monitor_stream.h: No such file or directory ...
Try compiling read_arc_matlab.cc:
$ mex -v read_arc_matlab.cc -I/home/kstory/ -I/home/kstory/gcp/control/code/unix/libunix_src/common/ -I/home/kstory/gcp/util/common
Looking at pryke on spt:
spt_analysis/
util/ -> lots of stuff
Matlab path:
>> path
MATLABPATH
/home/kstory/gcp/lib
/home/kstory/gcp/matlab/common
/home/kstory/matlab
/usr/local/matlab7p3/toolbox/matlab/general
...
Talk to Clem again:
Need to link proper files. Try compiling with the Makefile
Write Makefile for matReadArc.cc
It compiles.New error:
>>
>> regs={'antenna0.syncBox.frame_serialNumber'};
>> d=read_arc(regs,'06-apr-2009:20:14:04','06-apr-2009:20:14:05')
nrs_read_msg: End of stream reached prematurely.
Skipping the rest of archive file: 20090406_201404.dat
??? One or more output arguments not assigned during call to "matReadArc".
Error in ==> read_arc at 57
data=matReadArc(regs,start,finish,arcdir,calfile);
57 data=matReadArc(regs,start,finish,arcdir,calfile);
K>>
Try with a properly opened and closed file: Same error.
Make a data file from the real mce and real sync box.
bicep31:
- bicepControl
- bicepMediator
- bicepAntenna
Sync box settings:
Bgtkterm &
Synco> ? DV_Mode = FeeRun_DV FRun_Count = 100 Row_Len = 75 Num_Row = 33
Start the code:
bicep31$ /home/bicep/gcp/bin/bicepViewer & bicep31$ ./startXterms GREEN XTERM: g_31> /home/bicep/gcp/bin/bicepControl logd=/home/bicep/gcp/runlogs logf=bicepTestControl YELLOW XTERM: y_31> /home/bicep/gcp/bin/bicepMediator host=localhost logd=/home/bicep/gcp/runlogs logf=bicepTestMediator PURPLE XTERM: p_31> /home/bicep/gcp/bin/bicepAntennaControl host=localhost antenna=0 dataport=1500 cmdport=1600 simpmac=f simdata=f simgps=t sim1pps=t logd=/home/bicep/gcp/runlogs logf=bicepTestAntennaControl debuglevel=0 prio=f simblast=f simSync=f
bicep21:
- bicepMasd
Run the mce:
$ mce_reset_clean
MCE reset Successful.
$ mce_clock_mode 1 2 2
$ ./mce_pipe_acq 1000 1 100 33
Start the mce:
RED XTERM: r_32> /home/bicep/gcp/bin/bicepMasdControl host=bicep31 mce=0 cmdport=1600 logd=/home/bicep/gcp/runlogs logf=bicepTestMasdControl debuglevel=0 prio=f pipe_data=/data/cryo/mas_data_pipe pipe_runfile=/data/cryo/mas_data_pipe.run simdata=f
4/8
Matlab Arc reader on bicep0
Check out gcp from cvs onto kstory account on bicep0.
compile --> FAIL.
I am missing things like
- tcl.h
- tk.h
copy matlab/common/Makefile from find.
compile the mex program:
$ mex -settings 2 $ make matReadArc.cc:64:22: error: iostream.h: No such file or directoryFail...
Matlab Arc reader on find
Try different limits:
>> regs={'antenna0.syncBox.frame_serialNumber'};
over-cover start, over-cover end:
>> d=read_arc(regs,'06-apr-2009:20:50:00','06-apr-2009:22:50:00')
??? One or more output arguments not assigned during call to "matReadArc".
Error in ==> read_arc at 57
data=matReadArc(regs,start,finish,arcdir,calfile);
under-cover start, under-cover end
>> d=read_arc(regs,'06-apr-2009:21:51:00','06-apr-2009:21:51:50')
??? One or more output arguments not assigned during call to "matReadArc".
under-cover start, over-cover end
>> d=read_arc(regs,'06-apr-2009:21:51:00','06-apr-2009:22:51:50')
??? One or more output arguments not assigned during call to "matReadArc".
over-cover start, under-cover end
>> d=read_arc(regs,'06-apr-2009:20:50:00','06-apr-2009:21:51:50')
??? One or more output arguments not assigned during call to "matReadArc".
miss time window:
>> d=read_arc(regs,'06-apr-2009:20:50:00','06-apr-2009:20:51:00')
Directory /home/kstory/gcp/matlab/common/ doesn't contain any suitable archive files.
>> regs={'antenna0.syncBox.frame_serialNumber'};
>> d=read_arc(regs,'06-apr-2009:20:50:00','06-apr-2009:22:50:00')
??? One or more output arguments not assigned during call to "matReadArc".
4/9
Walt's arc reader
Download Walt's arc reader from his email to me.
Copy it to find.
$ tar -xzvf readarc.tgz $ cd readarc/readarc $ mex *.c -o readarcRun the program
$ >> d = readarc('/home/kstory/gcp/matlab/common/','2009-apr-06','2009-apr-07',{'antenna0.frame','mce0.data.fb*'})
readarc - a portable arc file reader
note: this is unstable and untested development code!
d =
antenna0: [1x1 struct]
mce0: [1x1 struct]
Try something different:
>> d = readarc('/home/kstory/gcp/matlab/common/','2009-apr-06:21:40','2009-apr-07',{'mce0.data.fb*'})
d =
mce0: [1x1 struct]
SPT arc reader
Copy over directory from spt:
/home/eml/gcp/matlab/common/
put it in /home/kstory/gcp/matlab/common/
Change make file:
gcp/Makefile
add Make_OBJS = ... matlab
Problem #1:
util/common/Errhandler.h -> function ERR_HANDLER_FN()
Problem #2:
add functions to util/common/Logger.h
4/10
Meeting with Clem
We were able to run the current matReadArc.mexa64 using an absurd time range!!
It appears the register array.frame.utc is set to zero, mjd.
>> regs={'array.frame.utc','antenna0.frame.utc','mce0.frame.utc'}
>>
4/13
Dropped samples in Antenna Layer
Run test_bbcpci
look for:
- missed numbers
- extra hits
- too fast reading
Currently running processes on bicep31 all started on April 10. Kill them.
Sync box is currently set to:
- fr = 47
- rl = 64
- nr = 41
Change it to the usual:
- fr = 100
- rl = 75
- nr = 33
This corresponds to ~100 hz.
On bicep31, working under kstory account.
In directory benton/bbcsync
First try test_bbcpci. This polls the sync box.
The code that reads the serial number appears to be:
serial = ioctl(fp, BBCPCI_IOC_GET_SERIAL);
However this prints our negative numbers that increment by 2??
serial = -1079869545
serial = -1079869543
Now looking at syncBox/bbcpci/ directory.
test7_bbcpci.c
$ g++ test7_bbcpci.c -o test7_bbcpci -lm
Problem:
1) run test7_bbcpci
get numbers like 1570408023
2) run gcp
get numbers like 1570413700
gcp device node is not becoming readable; antenna layer times out.
3) run gcp again
get numbers like 3215363550
Looking for skipped numbers in test_bbcpci
One time it started giving odd numbers. All other times have had no skipped numbers.
bbcsync
Try running syncBox/bbcsync/dummy_reader3.c
compile this with:
$ make dummy_reader3
This program literally just has a select loop watching the device node
/dev/bbc_sync
and when this becomes readable it prints out the serial number and the time spent in the select loop.
Frame numbers are indeed being skipped. Output:
Output: [new number, old number] Skipped number: [3216240184, 3216240182], ST=ST=0, DT=1860558 us Skipped number: [3216240184, 3216240184], ST=ST=1, DT=1860565 us -- Skipped number: [3216242925, 3216242925], ST=ST=0, DT=17 us Skipped number: [3216242927, 3216242925], ST=ST=0, DT=15 us -- Skipped number: [3216245426, 3216245426], ST=ST=0, DT=15 us Skipped number: [3216245428, 3216245426], ST=ST=0, DT=17 us -- Skipped number: [3216246034, 3216246034], ST=ST=0, DT=18 us Skipped number: [3216246036, 3216246034], ST=ST=0, DT=16 us
I added a usleep(10), which pauses for 10 microseconds, between the select and the read. This DOES NOT eliminate skipped frames.
usleep(100), same effect.
Now, if a frame number is skipped, simply read again:
Skipped number: [3216388905, 3216388905], ST=ST=0, DT (read-print)=15 us, DT (select-print)=2 us Read again: 3216388907 -- Skipped number: [3216389128, 3216389128], ST=ST=0, DT (read-print)=19 us, DT (select-print)=2 us Read again: 3216389130 -- Skipped number: [3216390065, 3216390065], ST=ST=0, DT (read-print)=20 us, DT (select-print)=2 us Read again: 3216390067 -- Skipped number: [3216390162, 3216390162], ST=ST=0, DT (read-print)=17 us, DT (select-print)=2 us Read again: 3216390164
Print out time between triggering on the select loop.
The select loop is triggering regularly at ~100Hz, as expected. Even for improper frame numbers.
Problem:
Device node becomes readable, but the frame number doesn't update.
Here "time" is set right after the select loop triggers.
Thus the timing arrival is fine, at 101 Hz.
Skipped number: old = 3217087811, time=1239657974.25052 sec
new = 3217087811, time=1239657974.26042 sec
Skipped number: old = 3217087811, time=1239657974.26042 sec
new = 3217087813, time=1239657974.27032 sec
--
Skipped number: old = 3217087986, time=1239657975.98316 sec
new = 3217087986, time=1239657975.99305 sec
Skipped number: old = 3217087986, time=1239657975.99305 sec
new = 3217087988, time=1239657976.00296 sec
Note:
When you turn on the dummy reader, there are 3 regimes:
1) prints frame numbers very fast, presumably clearing out its buffer
2) prints frame numbers ~2x too fast.
3) after ~30 sec, it slows down to the correct rate (now ~101Hz).
Time for reading is not a problem; waiting 5000 us does not make a difference:
Skipped number: old = 3217215627, t_select=1239659239.72721 sec, t_read=1239659239.73223 sec
new = 3217215627, t_select=1239659239.73711 sec, t_read=1239659239.74212 sec
Skipped number: old = 3217215627, t_select=1239659239.73711 sec, t_read=1239659239.74212 sec
new = 3217215629, t_select=1239659239.74702 sec, t_read=1239659239.75203 sec
4/14
Need to keep after the reader:
1) is array.frame.utc the register inside of a file that the reader uses?
2) where is array.frame.utc written? Clem guesses mediator layer.
4/15
Looking for the long lost array.frame.utc
antenna/control/bicep/
FrameBoard.cc
has registers:
- nsnap
- record
- utc
- lst
- features
- markSeq
This corresponds to antenna0.frame.*
In control/code/unix/libunix_src/common/regmap.c
RegBlockTemp generic_regmap_board[]
is called the "frame" board.
In specificregs.c
RegBoardTemp bicep_array_boards[] = {
{"weather", bicepWeather,...}
}
RegTemplate bicep_array_template = {
bicep_array_boards, ...
}
RegTemplate* specificArrayRegMapTemplate() {
return &bicep_array_template;
}
RegTemp bicep_regtemplates[] = {
{"array",....}
{"antenna0",...}
{"mce0",...}
}
Look for specificArrayRegMapTemplate();
genericregs.c
Regmap* new_ArrayRegMap(void)
util/common/ArrayRegMapDataFrameManager.cc
ArrayRegMapDataFrameManager::initialize()
{
if((regMap_ = new_ArrayRegMap())==0)
ThrowError("Unable to allocate register map");
...
}
util/common/RegMapDataFrameManager.cc
RegMapDataFrameManager::setMjd(double mjd)
RegMapDataFrameManager::setMjd(RegDate& regDate)
RegMapDataFrameManager::setMjd(TimeVal& timeVal)
Walt's ideas for sync box:
1) Try reading out of ioctl(...)
2) Write logbook posting
3) Email Steve Benton
/sys/class/
serial = ioctl(fp, BBCPCI_IOC_GET_SERIAL)
4/16
Try adding read from bbcpci to dummy reader for sync box
Try adding a read call to bbcpci when the select loop triggers:
Skipped number: old = 3241025172, t_select=1239894985.91111 sec, t_read=1239894985.91612 sec
new = 3241025172, t_select=1239894985.91612 sec, t_read=1239894985.92113 sec
bbc_pci: new = 3241026512
Skipped number: old = 3241025172, t_select=1239894985.91612 sec, t_read=1239894985.92113 sec
new = 3241025174, t_select=1239894985.92116 sec, t_read=1239894985.92617 sec
bbc_pci: new = 3241026512
Skipped number: old = 3241025179, t_select=1239894985.94624 sec, t_read=1239894985.95125 sec
new = 3241025179, t_select=1239894985.95126 sec, t_read=1239894985.95626 sec
bbc_pci: new = 3241026512
Skipped number: old = 3241025179, t_select=1239894985.95126 sec, t_read=1239894985.95626 sec
new = 3241025181, t_select=1239894985.95629 sec, t_read=1239894985.96130 sec
bbc_pci: new = 3241026512
...
Skipped number: old = 3241026363, t_select=1239894991.87994 sec, t_read=1239894991.88494 sec
new = 3241026363, t_select=1239894991.88495 sec, t_read=1239894991.88996 sec
bbc_pci: new = 3241027020
Skipped number: old = 3241026363, t_select=1239894991.88495 sec, t_read=1239894991.88996 sec
new = 3241026365, t_select=1239894991.88999 sec, t_read=1239894991.89500 sec
bbc_pci: new = 3241027020
Skipped number: old = 3241026376, t_select=1239894991.94514 sec, t_read=1239894991.95015 sec
new = 3241026376, t_select=1239894991.95015 sec, t_read=1239894991.95516 sec
bbc_pci: new = 3241027020
Skipped number: old = 3241026376, t_select=1239894991.95015 sec, t_read=1239894991.95516 sec
new = 3241026378, t_select=1239894991.95519 sec, t_read=1239894991.96020 sec
bbc_pci: new = 3241027020
FN=3241026400
FN=3241026500
Skipped number: old = 3241026512, t_select=1239894992.62677 sec, t_read=1239894992.63178 sec
new = 3241026512, t_select=1239894992.63178 sec, t_read=1239894992.63679 sec
bbc_pci: new = 3241027020
...
Second try: (no modification to code)
Skipped number: old = 3241041850, t_select=1239895149.43048 sec, t_read=1239895149.43549 sec
new = 3241041852, t_select=1239895149.43550 sec, t_read=1239895149.44051 sec
bbc_pci: new = 0
Skipped number: old = 3241041852, t_select=1239895149.43550 sec, t_read=1239895149.44051 sec
new = 3241041852, t_select=1239895149.44055 sec, t_read=1239895149.44556 sec
bbc_pci: new = 0
...
Add the lines:
ioctl(bbc_fd, BBC_IOC_RESET);
while (ioctl(fp, BBCPCI_IOC_COMREG) !=0); // wait 'til reset is done
And it now does not seem to be skipping any numbers.
It takes some time (~30 seconds) for the sync box to settle into the correct rate. It is too fast before this.
Summary of Sync Box skipped frames problem
I have been trying to debug the skipped frames problem in the Antenna Layer of the gcp.
Symptoms of the problem:
1) The device node becomes readable and is recognized by the select loop at the correct regular intervals. This is good.
2) Occasionally ( approx once every 500 numbers), the device becomes readable but the serial number does not update. In this case, the number read from bbc_sync is the same as the previous number.
3) The following serial number that is read is the previous + 2.
example:
Skipped number: old = 3242096510
new = 3242096510
Skipped number: old = 3242096510
new = 3242096512
bbcpci settings:
Settings from test_bbcpci are initialized as follows:
ioctl(bbcpci_fp, BBCPCI_IOC_RESET);
while (ioctl(bbcpci_fp, BBCPCI_IOC_COMREG) !=0); // wait 'til reset is done
usleep(100000);
ioctl(bbcpci_fp, BBCPCI_IOC_SYNC);
usleep(100000);
ioctl(bbcpci_fp, BBCPCI_IOC_ON_IRQ);
ioctl(bbcpci_fp, BBCPCI_IOC_EXT_SER_OFF);
ioctl(bbcpci_fp, BBCPCI_IOC_IRQ_RATE, 320000);
settings in BlastBusBoard.cc
ioctl(bbc_pci_fd_, BBCPCI_IOC_RESET);
while (ioctl(bbc_pci_fd_, BBCPCI_IOC_COMREG) !=0); // wait until reset is done
usleep(100000);
ioctl(bbc_pci_fd_, BBCPCI_IOC_SYNC);
usleep(100000);
ioctl(bbc_pci_fd_, BBCPCI_IOC_ON_IRQ);
ioctl(bbc_pci_fd_, BBCPCI_IOC_FRAME_RATE, 2);
ioctl(bbc_pci_fd_, BBCPCI_IOC_EXT_SER_ON);
Testing with dummy reader:
In dummy_reader3.cc (kstory/syncBox/bbcsync/ on bicep31), I am opening bbcpci with:
| bbcpci_fp = open("/dev/bbcpci\0", O_RDWR | O_NONBLOCK); |
and opening bbc_sync with:
infd = open ("/dev/bbc_sync\0", O_RDONLY);
I am running a select loop on the bbc_sync device node.
I read the bbc_sync device node with:
r = read (infd, &td, sizeof(struct timing_data));
printf("FN=%u\n", td.serialnumber);
I read the bbcpci card with:
if( read(bbcpci_fp, (void )(&j), sizeof(unsigned int)) == 4) {
if (GET_STORE(j)) {
bbcpci_serial = ioctl(bbcpci_fp, BBCPCI_IOC_GET_SERIAL);
}
}
_Case I: working_
If the settings are as follows:
ioctl(bbcpci_fp, BBCPCI_IOC_EXT_SER_OFF);
ioctl(bbcpci_fp, BBCPCI_IOC_IRQ_RATE, 320000);
Here no frames are skipped, but the serial
_Case II: not working:_
ioctl(bbc_pci_fd_, BBCPCI_IOC_EXT_SER_ON);
//ioctl(bbcpci_fp, BBCPCI_IOC_IRQ_RATE, 320000);
This gives the same skipped numbers problem.
_bbcpci problem:_
In all cases I cannot properly read out the number directly from the bbcpci card. These numbers are always 0.
Current Settings:
ioctl(bbc_pci_fd_, BBCPCI_IOC_ON_IRQ);
ioctl(bbc_pci_fd_, BBCPCI_IOC_FRAME_RATE, 2);
ioctl(bbc_pci_fd_, BBCPCI_IOC_EXT_SER_ON);
// ioctl(bbc_pci_fd_, BBCPCI_IOC_IRQ_RATE, 320000);
New Settings:
ioctl(bbc_pci_fd_, BBCPCI_IOC_EXT_SER_OFF);
ioctl(bbc_pci_fd_, BBCPCI_IOC_IRQ_RATE, 320000);
Results:
I did not see any skipped frames, however the numbers are also
19726350
Which is what I see from test_bbcpci but not from gcp running.
At least this is consistent with the output from the dummy reader.
Qestions:
- Where are the BBCPCI_ functions defined?
I have no idea how this stuff works.
It appears that
BBCPCI_IOC_EXT_SER_ON
Defines whether or not we are using the external sync box or generating numbers with the card.
Next, in dummy_reader4.c try triggering on select loop, but reading directly from bbcpci.
4/17
More Sync Box dropped numbers
kstory/syncBox/bbcpci/test7_bbcpci
kstory/syncBox/bbcsync/dummy_reader3
These currently print out the same numbers.
Is opening multiple readers on bbcpci a problem?
/gcp/modules/bicep/bbcsync/
2009-02-02 (RWO) - patched version of bbc_sync driver
KBUILD_NOPEDANTIC=1 make
echo "g" > /sys/class/bbc_sync/bbc_sync/interrupts
$ cat interrupts
Interrupts active.
Notes to compile Kernel driver:
1) Edit the file:
/gcp/modules/bicep/bbcsync/bbc_sync.c
2) compile:
KBUILD_NOPEDANTIC=1 make
3) remove the old module:
sudo rmmod bbc_sync
4) Add the new module:
sudo insmod bbc_sync.ko
5) Enable interrupts:
cd /sys/class/bbc_sync/bbc_sync/
echo "g" > /sys/class/bbc_sync/bbc_sync/interrupts
cat interrupts
- This checks if interrupts are active or not
6) run the dummy_reader program.
Case I:
Set serialnumber = number of times through the loop in bbc_sync.c:
for (i=0; i<100; i++) {
int busy;
serialnumber = bbcpci_get_serialnumber(&busy);
if (!busy) break;
udelay(2);
}
serialnumber = i;
bbc_pci: new = 3250620172
Skipped number: old = 0, t_select=1239989970.36483 sec, t_read=1239989970.36483 sec
new = 1, t_select=1239989970.37473 sec, t_read=1239989970.37473 sec
bbc_pci: new = 3250620173, c1c0870d
Skipped number: old = 1, t_select=1239989970.37473 sec, t_read=1239989970.37473 sec
new = 1, t_select=1239989970.38463 sec, t_read=1239989970.38463 sec
bbc_pci: new = 3250620174, c1c0870e
Skipped number: old = 1, t_select=1239989970.38463 sec, t_read=1239989970.38463 sec
new = 0, t_select=1239989970.39453 sec, t_read=1239989970.39453 sec
bbc_pci: new = 3250620175, c1c0870f
I see the loop being iterated 0, 1, or 2 times. No more.
Case II:
Try putting a delay before the bbcpci_get_serialnumber(&busy) call.
Write logbook posting
log onto bmode using the bicep account.
Go to:
/export/raid/bicep0/spuder/public_html/control_software/notes.html
Check that when serialnumber = i, we never get large numbers.
4/20
To do:
1) Sequence of skipped serial numbers
2) software work-around.
Permissions on device nodes in bicep31
I just did
chown root:staff /dev/bbc_pci
chown root:staff /dev/bbc_sync
to change the group ownership of the nodes from 'root' to 'staff'. Since
kstory, bicep, reuben, etc. are members of the group 'staff', we can all write to the nodes.
To make this work after reboot, I changed the 15-bbcsync.rules script and
added a 15-bbcpci.rules in the CVS repository, changed the group from 'bbc'
(which doesn't exist on this machine) to 'staff', and did 'make install' in the bbcsync and bbcpci directories in cvs.
- Walt
This file is in gcp/modules/bicep/bbcsync/15-bbcsync.rules
Skipped numbers (list)
3276087413 3276087813 3276087855 3276087954 3276087999 3276088232 3276088252 3276088329 3276088423 3276088428 3276088671 3276088737 3276088912 3276088928 3276088956 3276089087 3276089103 3276089469 3276089652 3276089767 3276090157 3276090398 3276090667 3276090720 3276090785 3276090850 3276090911 3276091180 3276091277 3276091363 3276091384 3276091408 3276091489 3276091515 3276091771 3276091918 3276092056 3276092109 3276092203 3276092300 3276092454 3276092561 3276092703 3276092708 3276092959 3276093033 3276093127 3276093286 3276093289 3276093493 3276093550 3276093579 3276093622 3276093750 3276093752 3276093779 3276093828 3276094089 3276094246 3276094356 3276094377 3276094514 3276094853 3276094874 3276094882 3276095225 3276095437 3276095681 3276095778 3276095790 3276095840 3276095909 3276096311
Plot of skipped numbers
On average, one out of every 122 serial numbers is skipped.
This is averaged over 8900 serial numbers.
Hacked solution to bbc_sync skipped numbers problem
We now have a hacked solution to the skipped numbers problem from reading the bbc_sync device node.
1) Select loop triggers on the bbc_sync device node
2) read the serial from bbc_sync
3) if serial_current == serial_previous, read again directly from bbcpci.
Email from Walt:
Hi Kyle, The only reason I have in mind is modularity. If a new firmware fixes the timing so that /dev/bbc_sync is always correct, then we can have the blast bus code handle /dev/bbc_pci and the sync box code handle /dev/bbc_sync, with no overlap. The extra check is really just to make it clear in the code what the failure mode is and why we're working around it in this way. You should also add some comments. -Walt > Hi Walt, > Is there a good reason why we don't want to > simply read directly from the bbcpci all of the time? The only reason > I can think of immediately against doing this is if reading from the > bbc_sync device node is faster. > > ~Kyle
Periodicity check:
If you want to characterize it in detail, you could collect a larger sample,
then check that the time differences are distributed exponentially... any
periodicity would be a spike or bump on top of the exponential. I don't see
any such departures on the small sample you've posted.
Work on kstory account at bicep31
For tomorrow:
My "fix" in gcp has been coded up in kstory on bicep31, and compiles.
Check it.
Questions for SyncBox:
- Where can I find out what commands exist, and what they do?
- in test_bbcpci, what is the difference between serial and frame_serial?
4/22
GCP hacked solution to bbc_sync skipped numbers
1) When the Antenna Layer is creating the Data thread, instantiate the BlastBusBoard first.
2) Pass the bbc_pci_fd to the SyncBoard through the constructor. SyncBoard now has a public field, bbc_pci_fd_ where this file descriptor is stored.
3) In DataNew.cc, when the select loop triggers on the device node /dev/bbc_sync, set sampleNumber_prev_, then call SyncBoard::readFrameNumber
4) In SyncBoard::readFrameNumber, read the serial number from bbc_sync. If the number read is equal to the previous serial number, read the number again from bbc_pci.
Not working.
Currently, when I read numbers out of bbc_sync, they do not match those that I read out of bbc_pci. The problem here was that I was trying to set the bbc_pci_fd_ value in SyncBoard before BlastBusBoard had opened the device node.
The numbers still do not match. Example:
[sync pci] = 3293562730, -1001404566
[sync pci] = 3293562731, -1001404565
[sync pci] = 3293562732, -1001404564
[sync pci] = 3293562733, -1001404563
[sync pci] = 3293562734, -1001404562
[sync pci] = 3293562735, -1001404561
[sync pci] = 3293562736, -1001404560
[sync pci] = 3293562737, -1001404559
Now do the following:
// Read bbc_sync retval = read (bbc_sync_fd_, &timing_data_, sizeof(struct timing_data)); // Read bbcpci bbcpci_serial = ioctl(bbc_pci_fd_, BBCPCI_IOC_GET_SERIAL); bbcpci_serial_u = (unsigned) bbcpci_serial; cout<<"[sync pci pci_u] = "<<timing_data_.serialnumber<<", "<<bbcpci_serial<<", "<<bbcpci_serial_u<<endl;; Output: [sync pci pci_u] = 3293576950, -1001390346, 3293576950 [sync pci pci_u] = 3293576951, -1001390345, 3293576951 [sync pci pci_u] = 3293576952, -1001390344, 3293576952 [sync pci pci_u] = 3293576953, -1001390343, 3293576953 [sync pci pci_u] = 3293576954, -1001390342, 3293576954 [sync pci pci_u] = 3293576955, -1001390341, 3293576955
This looks ok. I am concerned that the numbers for the frames are dependent on the conversion between int and unsigned int.
(10 min later)
Now it is not working again, and I'm not sure what I changed:
[sync pci pci_u] = 3293622771, -1001343804, 3293623492 [sync pci pci_u] = 3293622772, -1001343804, 3293623492 [sync pci pci_u] = 3293622773, -1001343798, 3293623498 [sync pci pci_u] = 3293622774, -1001343798, 3293623498
Now Walt is using the gcp on bicep31 and I can't debug anymore. :(
4/23
GCP hacked solution continued
Run the exact code I had from yesterday. It seems to be working!
[sync pci pci_u] = 3301623805, -993343491, 3301623805 [sync pci pci_u] = 3301623806, -993343490, 3301623806 [sync pci pci_u] = 3301623807, -993343489, 3301623807 [sync pci pci_u] = 3301623808, -993343488, 3301623808