Somehow the trigger rate was not matching the trigger source.
Find out that Link 3 was not collecting and possibly holding the fragment assembly in the main thread.
Swap Link3 <-> Link0 on the V1725, restarted.
Needs further investigation!

Date rate is fine now! CPU load is balanced on all 4 threads (~25%)
- irqbalance disabled
- change affinity for A3818 to cpu9: /etc/rc.local add: echo 0200 > /proc/irq/136/smp_affinity
  Check : watch -n 0.1 'cat /proc/interrupts'

Maximum Trigger rate (HW buffer not rising) 1950 Evt/s => 200MB/s 
for event size of 100KB composed of 4 banks with 32us per channel.

Summary of setup of chronobox on network (mostly done by Pierre):

1) Hook up USB connection from chronobox to ds-proto-daq.  Start serial-USB connection by doing

/home/dsproto/online/dsproto_daq/serialusb

can login through serial link.  Added the ssh key for dsproto@ds-proto-daq to the authorized_keys file on
chronobox linux.

ctrl-a, ctrl-x to stop picocom

2) On ds-proto-daq, setup dhcpd server.  Configuration in this file

/etc/dhcp/dhcpd.conf

dhpcd is bond to the second NIC only.  Configure DHCP to give IP 192.168.1.3 to chronobox.  In /etc/hosts set
192.168.1.3 to have hostname chronobox

Power cycle chronobox; it successfully gets IP:

[dsproto@ds-proto-daq dsproto_daq]$ ping chronobox
PING chronobox (192.168.1.3) 56(84) bytes of data.
64 bytes from chronobox (192.168.1.3): icmp_seq=1 ttl=64 time=0.180 ms

3) Can see the chronobox webpage locally as

http://chronobox:8080

4) Some esper tool to access data:  did following to setup esper

  734  yum install python2-pip
  735  pip install esper-tool
  736  yum install ncurses
  738  yum install ncurses-devel
  739  pip install esper-tool

Can then connect to the chronobox by doing

esper-tool interactive http://chronobox:8080

This is as much as I understand at this point... more exploring now...

5) Pierre unplugged the SD card to take it back to Bryerton's room.  But I guess this was bad.

lots of errors on serialUSB link now and the webpage doesn't work anymore:

[ 1246.665269] blk_partition_remap: fail for partition 2
Jan  1 00:20:46 buildroot user.warn kernel: [ 1242.904770] EXT4-fs error: 339 callbacks suppressed
[ 1246.679162] blk_partition_remap: fail for partition 2
Jan  1 00:20:46 buildroot user.crit kernel: [ 1242.904780] EXT4-fs error (device mmcblk0p2):
ext4_find_entry:1437: inode #2: com[ 1246.692884] blk_partition_remap: fail for partition 2
m syslogd: reading directory lblock 0
[ 1246.709020] blk_partition_remap: fail for partition 2
Jan  1 00:20:46 buildroot user.warn kernel: [ 1242.929199] blk_partition_remap: fail for partition 2
[ 1246.717394] blk_partition_remap: fail for partition 2
Jan  1 00:20:46 buildroot user.crit kernel: [ 1242.942971] EXT4-fs error (device mmcblk0p2):
ext4_find_entry:1437: inode #2: com[ 1246.731255] blk_partition_remap: fail for partition 2
m syslogd: reading directory lblock 0
Jan  1 00:20:46 buildroot user.warn kernel: [ 1242.953760] blk_partition_remap: fail for [ 1246.747337]
blk_partition_remap: fail for partition 2
partition 2
Jan  1 00:20:46 buildroot user.crit kernel: [ 1242.967532] EXT4-fs error (device mmcblk0p2):
ext4_find_entry:1437: [ 1246.763481] blk_partition_remap: fail for partition 2
inode #2: comm syslogd: reading directory lblock 0
Jan  1 00:20:46 buildroot user.warn kernel: [ 1242.978320] blk_partition_rem[ 1246.779511] blk_partition_remap:
fail for partition 2
ap: fail for partition 2
Jan  1 00:20:46 buildroot user.crit kernel: [ 1242.992091] EXT4-fs error (device mmcblk0p2): ext4_find[
1246.795586] blk_partition_remap: fail for partition 2
_entry:1437: inode #2: comm syslogd: reading directory lblock 0
Jan  1 00:20:46 buildroot user.warn kernel: [ 1243.002885] blk_[ 1246.811671] blk_partition_remap: fail for
partition 2
partition_remap: fail for partition 2
Jan  1 00:20:46 buildroot user.crit kernel: [ 1243.016656] EXT4-fs error (device mmcblk0p[ 1246.827750]
blk_partition_remap: fail for partition 2

The SDcard is currently required for operation of the device, the ext3/4 filesystem will immediately fail upon removal.


> Summary of setup of chronobox on network (mostly done by Pierre):
> 
> 1) Hook up USB connection from chronobox to ds-proto-daq.  Start serial-USB connection by doing
> 
> /home/dsproto/online/dsproto_daq/serialusb
> 
> can login through serial link.  Added the ssh key for dsproto@ds-proto-daq to the authorized_keys file on
> chronobox linux.
> 
> ctrl-a, ctrl-x to stop picocom
> 
> 2) On ds-proto-daq, setup dhcpd server.  Configuration in this file
> 
> /etc/dhcp/dhcpd.conf
> 
> dhpcd is bond to the second NIC only.  Configure DHCP to give IP 192.168.1.3 to chronobox.  In /etc/hosts set
> 192.168.1.3 to have hostname chronobox
> 
> Power cycle chronobox; it successfully gets IP:
> 
> [dsproto@ds-proto-daq dsproto_daq]$ ping chronobox
> PING chronobox (192.168.1.3) 56(84) bytes of data.
> 64 bytes from chronobox (192.168.1.3): icmp_seq=1 ttl=64 time=0.180 ms
> 
> 3) Can see the chronobox webpage locally as
> 
> http://chronobox:8080
> 
> 4) Some esper tool to access data:  did following to setup esper
> 
>   734  yum install python2-pip
>   735  pip install esper-tool
>   736  yum install ncurses
>   738  yum install ncurses-devel
>   739  pip install esper-tool
> 
> Can then connect to the chronobox by doing
> 
> esper-tool interactive http://chronobox:8080
> 
> This is as much as I understand at this point... more exploring now...
> 
> 5) Pierre unplugged the SD card to take it back to Bryerton's room.  But I guess this was bad.
> 
> lots of errors on serialUSB link now and the webpage doesn't work anymore:
> 
> [ 1246.665269] blk_partition_remap: fail for partition 2
> Jan  1 00:20:46 buildroot user.warn kernel: [ 1242.904770] EXT4-fs error: 339 callbacks suppressed
> [ 1246.679162] blk_partition_remap: fail for partition 2
> Jan  1 00:20:46 buildroot user.crit kernel: [ 1242.904780] EXT4-fs error (device mmcblk0p2):
> ext4_find_entry:1437: inode #2: com[ 1246.692884] blk_partition_remap: fail for partition 2
> m syslogd: reading directory lblock 0
> [ 1246.709020] blk_partition_remap: fail for partition 2
> Jan  1 00:20:46 buildroot user.warn kernel: [ 1242.929199] blk_partition_remap: fail for partition 2
> [ 1246.717394] blk_partition_remap: fail for partition 2
> Jan  1 00:20:46 buildroot user.crit kernel: [ 1242.942971] EXT4-fs error (device mmcblk0p2):
> ext4_find_entry:1437: inode #2: com[ 1246.731255] blk_partition_remap: fail for partition 2
> m syslogd: reading directory lblock 0
> Jan  1 00:20:46 buildroot user.warn kernel: [ 1242.953760] blk_partition_remap: fail for [ 1246.747337]
> blk_partition_remap: fail for partition 2
> partition 2
> Jan  1 00:20:46 buildroot user.crit kernel: [ 1242.967532] EXT4-fs error (device mmcblk0p2):
> ext4_find_entry:1437: [ 1246.763481] blk_partition_remap: fail for partition 2
> inode #2: comm syslogd: reading directory lblock 0
> Jan  1 00:20:46 buildroot user.warn kernel: [ 1242.978320] blk_partition_rem[ 1246.779511] blk_partition_remap:
> fail for partition 2
> ap: fail for partition 2
> Jan  1 00:20:46 buildroot user.crit kernel: [ 1242.992091] EXT4-fs error (device mmcblk0p2): ext4_find[
> 1246.795586] blk_partition_remap: fail for partition 2
> _entry:1437: inode #2: comm syslogd: reading directory lblock 0
> Jan  1 00:20:46 buildroot user.warn kernel: [ 1243.002885] blk_[ 1246.811671] blk_partition_remap: fail for
> partition 2
> partition_remap: fail for partition 2
> Jan  1 00:20:46 buildroot user.crit kernel: [ 1243.016656] EXT4-fs error (device mmcblk0p[ 1246.827750]
> blk_partition_remap: fail for partition 2

a) Bryerton implemented new version of the firmware.  New features:

1) run start/stop state
2) at run start 6 events are sent with 200ms separation
3) there is a greater set of counters about trigger, as well as configuring the trigger.

b) chronobox webpage can be seen here:

https://ds-proto-daq.triumf.ca/chronobox/

The mod_tdm page gives configuration of run state and trigger.  In particular

- button to start/stop run
- button to do manual trigger
- configure which channels are TOP and which are BOTTOM
- configure the number of TOP or BOTTOM channels that need to figure
- DecisionType: true= TOP AND BOTTOM groups must fire; false = TOP OR BOTTOM groups can fire.

c) Start and stop run can also be done on command line with esper tool:

esper-tool write -d true 192.168.1.3 mod_tdm run
esper-tool write -d false 192.168.1.3 mod_tdm run

d) I modified the V1725 frontend to integrate the chronobox start/stop.

At run start
- configure V1725s
- start chronobox with the command-line esper-tool call

At end run
- add deferred transition function which stops run (with esper-tool), then checks whether all the events have
cleared from ring buffers.
- once ring buffers are cleared, finish stopping the V1725s.

In the long run should somehow do the start/stop commands with some http post command, rather than command line
to esper-tool.

e) With the start/stop run could start to compare the timestamps of V1725s and confirm that they matched (ie,
all V1725s got reset at the same time).  Also, all the events are cleared from buffers.

f) However, I found that the frontend program still consistently failed with this error when the trigger rate
was above the maximum sustainable:

Deferred transition.  First call of wait_buffer_empty. Stopping run
[feov1725MTI00,ERROR] [v1725CONET2.cxx:685:ReadEvent,ERROR] Communication error: -2
[feov1725MTI00,ERROR] [feoV1725.cxx:654:link_thread,ERROR] Readout routine error on thread 0 (module 0)
[feov1725MTI00,ERROR] [feoV1725.cxx:655:link_thread,ERROR] Exiting thread 0 with error
Stopped chronobox run; status = 0
Segmentation fault


Next steps:

1) Fix the seg-fault for high rate running.
2) More detailed timestamp checking, with cm_msg(ERRORs)
3) Bryerton is now working on the event FIFO on chronobox.  That will be next thing to integrate.

> f) However, I found that the frontend program still consistently failed with this error when the trigger rate
> was above the maximum sustainable:
> 
> Deferred transition.  First call of wait_buffer_empty. Stopping run
> [feov1725MTI00,ERROR] [v1725CONET2.cxx:685:ReadEvent,ERROR] Communication error: -2
> [feov1725MTI00,ERROR] [feoV1725.cxx:654:link_thread,ERROR] Readout routine error on thread 0 (module 0)
> [feov1725MTI00,ERROR] [feoV1725.cxx:655:link_thread,ERROR] Exiting thread 0 with error
> Stopped chronobox run; status = 0
> Segmentation fault

I sort of 'fix' this problem.  There is some sort of problems between the V1725 readout	thread and the system call
to esper-tools to stop the run.  Some collision between the system resources for these two calls causes the readout
thread ReadEvent call to fail.  I 'fix' the problem by adding in the end_of_run part a 500us pause of the readout
threads before I make the system call to esper-tool.  

Odd.  In principle I think that the system calls and the readout threads are running on different cores.  So not
clear what the problem was.  Should figure out better diagnosis and fix problem properly.

The ChronoBox latest FW is loaded. Let tme know if this is what the chronobox should look like in term of registers.

Are we monitoring the PLL Lock Loss  (odb: /DEAP Alarm ?)

Here is the dump of the 5 first sync triggers without any physics trigger behind.

1 0x830b577 0x17d7855 0x6b33d22 0x6b33d22 8.992791 
2 0x830b577 0x17d7855 0x6b33d22 0x6b33d22 8.992791 
3 0x830b577 0x17d7855 0x6b33d22 0x6b33d22 8.992791 
4 0x830b577 0x17d7855 0x6b33d22 0x6b33d22 8.992791 

1 0x830b581 0x2faf097 0x535c4ea 0x535c4ea 6.992792 
2 0x830b581 0x2faf097 0x535c4ea 0x535c4ea 6.992792 
3 0x830b581 0x2faf095 0x535c4ec 0x535c4ec 6.992792 
4 0x830b581 0x2faf095 0x535c4ec 0x535c4ec 6.992792 

1 0x830b587 0x47868d7 0x3b84cb0 0x3b84cb0 4.992792 
2 0x830b587 0x47868d7 0x3b84cb0 0x3b84cb0 4.992792 
3 0x830b587 0x47868d7 0x3b84cb0 0x3b84cb0 4.992792 
4 0x830b587 0x47868d7 0x3b84cb0 0x3b84cb0 4.992792 

1 0x830b5a1 0x5f5e119 0x23ad488 0x23ad488 2.992794 
2 0x830b5a1 0x5f5e119 0x23ad488 0x23ad488 2.992794 
3 0x830b5a1 0x5f5e117 0x23ad48a 0x23ad48a 2.992794 
4 0x830b5a1 0x5f5e117 0x23ad48a 0x23ad48a 2.992794 

1 0x830b5ab 0x7735959 0xbd5c52 0xbd5c52 0.992795 
2 0x830b5ab 0x7735959 0xbd5c52 0xbd5c52 0.992795 
3 0x830b5ab 0x7735959 0xbd5c52 0xbd5c52 0.992795 
4 0x830b5ab 0x7735959 0xbd5c52 0xbd5c52 0.992795 


With the physics triggers:
1 0x830b5c1 0x1834497f 0xeffc6c42 0x100393be 21.493591 
2 0x830b5c1 0x1834497f 0xeffc6c42 0x100393be 21.493591 
3 0x830b5c1 0x1834497f 0xeffc6c42 0x100393be 21.493591 
4 0x830b5c1 0x1834497f 0xeffc6c42 0x100393be 21.493591 
1 0x830b5d3 0x1834abb5 0xeffc0a1e 0x1003f5e2 21.495601 
2 0x830b5d3 0x1834abb5 0xeffc0a1e 0x1003f5e2 21.495601 
3 0x830b5d3 0x1834abb5 0xeffc0a1e 0x1003f5e2 21.495601 
4 0x830b5d3 0x1834abb5 0xeffc0a1e 0x1003f5e2 21.495601 
1 0x830b5dd 0x18350d7f 0xeffba85e 0x100457a2 21.497603 
2 0x830b5dd 0x18350d7f 0xeffba85e 0x100457a2 21.497603 
3 0x830b5dd 0x18350d7f 0xeffba85e 0x100457a2 21.497603 
4 0x830b5dd 0x18350d7f 0xeffba85e 0x100457a2 21.497603 
1 0x830b5e3 0x183585e7 0xeffb2ffc 0x1004d004 21.500068 
2 0x830b5e3 0x183585e7 0xeffb2ffc 0x1004d004 21.500068 
3 0x830b5e3 0x183585e7 0xeffb2ffc 0x1004d004 21.500068 
4 0x830b5e3 0x183585e7 0xeffb2ffc 0x1004d004 21.500068 
1 0x830b5ed 0x1a10bb9b 0xee1ffa52 0x11e005ae 23.991535 
2 0x830b5ed 0x1a10bb9b 0xee1ffa52 0x11e005ae 23.991535 
3 0x830b5ed 0x1a10bb9b 0xee1ffa52 0x11e005ae 23.991535 
4 0x830b5ed 0x1a10bb9b 0xee1ffa52 0x11e005ae 23.991535 
1 0x830b5fb 0x1a111f65 0xee1f9696 0x11e0696a 23.993578 
2 0x830b5fb 0x1a111f65 0xee1f9696 0x11e0696a 23.993578 
3 0x830b5fb 0x1a111f65 0xee1f9696 0x11e0696a 23.993578 
4 0x830b5fb 0x1a111f65 0xee1f9696 0x11e0696a 23.993578 
1 0x830b607 0x1a118115 0xee1f34f2 0x11e0cb0e 23.995577 
2 0x830b607 0x1a118115 0xee1f34f2 0x11e0cb0e 23.995577 
3 0x830b607 0x1a118115 0xee1f34f2 0x11e0cb0e 23.995577 
4 0x830b607 0x1a118115 0xee1f34f2 0x11e0cb0e 23.995577 
1 0x830b611 0x1a11e2c7 0xee1ed34a 0x11e12cb6 23.997577 
2 0x830b611 0x1a11e2c7 0xee1ed34a 0x11e12cb6 23.997577 
3 0x830b611 0x1a11e2c7 0xee1ed34a 0x11e12cb6 23.997577 
4 0x830b611 0x1a11e2c7 0xee1ed34a 0x11e12cb6 23.997577 


The ZMQ0 banks:
#banks:5 Bank list:-ZMQ0W200W201W202W203-
Bank:ZMQ0 Length: 40(I*1)/10(I*4)/10(Type) Type:Unsigned Integer*4
   1-> 0x000a5f1c 0x000000c4 0x00000001 0x0ebd5273 0x00000001 0x00010001 0xffffffff 0x00000000 
   9-> 0xffff0000 0x00000000 
------------------------ Event# 10 ------------------------
#banks:5 Bank list:-ZMQ0W200W201W202W203-
Bank:ZMQ0 Length: 40(I*1)/10(I*4)/10(Type) Type:Unsigned Integer*4
   1-> 0x000a5f1d 0x000000c5 0x00000001 0x0ebd5279 0x00000001 0x00010001 0xffffffff 0x00000000 
   9-> 0xffff0000 0x00000000 
[dsproto@ds-proto-daq dsproto_daq]$ 

I have done a couple longer tests of the DAQ setup.  The runs were done with a high trigger rate of ~60Hz, with
the V1725 asserting their busy to throttle the trigger.

I found that after a couple hours (~5hours) that we would no longer be getting ZMQ packets from the chronobox. 
 You can see this with error message like

15:29:04.092 2019/04/11 [feov1725MTI00,ERROR] [feoV1725.cxx:1033:read_trigger_event,ERROR] Error: did not
receive a ZMQ bank.  Stopping run.
10:26:37.158 2019/04/11 [mhttpd,INFO] Run #657 started

If I start a new run I am still missing ZMQ packets.  However, if I restart the frontend program (and hence
re-initialize the ZMQ link), then the chronobox does start sending triggers again.  So it may be more of a
problem with the ZMQ setup in the MIDAS frontend.  Needs more investigation.

The DAQ seems to be ready for tests with proto-0 tomorrow.  

I had to invert the first busy input in order to get chronobox to produce triggers.  I modified the setup script

setup_chronobox.sh

so this is now the default.  Not sure why necessary.

Another interesting fact; it seems the chronobox only asks for a DHCP IP when it first boots.  I think that
chronobox and ds-proto-daq were rebooted at the same time; ds-proto-daq dhcp server was probably not running
when chronobox asked for IP.  chronobox got IP fine when it was power cycled.

Tried to get laser sync signal into chronobox (clkin1 input), apparently all triggers dropped by chronobox

Problem is that the same now happen also with the regular setup where the clkin1 signal is taken by the dual timer.

This morning tried to get some data with Vbias=65 V, which seems better for the SiPM in MB1.

Busy handling still erratic.

At the beginning it seemed to work fine with busy_invert off and busy_enable on.

After a while (maybe after the first busy signal?) the only work around seemed to be to disable the busy_enable

The problem reported in ID 117 is somehow fixed this morning.

1) Install and tweak elog:

[root@ds-proto-daq ~]# cat /etc/elogd.cfg 
[global]
port = 8084
MTP host = trmail.triumf.ca
Use Email Subject = {$logbook} $Subject
Remove on reply = Author
Quote on reply = 1
URL = https://ds-proto-daq/elog/

[DS Prototype]
Theme = default
Comment = ELOG for DS Prototype MIDAS DAQ
Attributes = Author, Type, Category, Subject
Options Type = Routine, Problem, Problem Fixed, Configuration, Other
Options Category = General, Hardware, Digitizer, Trigger, MIDAS, Software, Other
Extendable Options = Category, Type
Required Attributes = Author, Type
Page Title = ELOG - $subject
Reverse sort = 1
Quick filter = Date, Type
Email all = lindner@triumf.ca

[root@ds-proto-daq ~]# systemctl start elogd.service
[root@ds-proto-daq ~]# systemctl is-active elogd.service
active
[root@ds-proto-daq ~]# systemctl enable elogd.service

2) Tweak apache and restart 

[root@ds-proto-daq ~]# grep elog /etc/httpd/conf.d/ssl-ds-proto-daq.conf 
ProxyPass /elog/ http://localhost:8084/ retry=1
[root@ds-proto-daq ~]# systemctl restart httpd

3) change MIDAS to use elog

[dsproto@ds-proto-daq bin]$ odbedit 
[local:dsproto:R]/>cd Elog/
[local:dsproto:R]/Elog>create STRING URL
String length [32]: 256
[local:dsproto:R]/Elog>set URL https://ds-proto-daq.triumf.ca/elog/DS+Prototype/

1) Install and tweak elog:

[root@ds-proto-daq ~]# cat /etc/elogd.cfg 
[global]
port = 8084
MTP host = trmail.triumf.ca
Use Email Subject = {$logbook} $Subject
Remove on reply = Author
Quote on reply = 1
URL = https://ds-proto-daq/elog/

[DS Prototype]
Theme = default
Comment = ELOG for DS Prototype MIDAS DAQ
Attributes = Author, Type, Category, Subject
Options Type = Routine, Problem, Problem Fixed, Configuration, Other
Options Category = General, Hardware, Digitizer, Trigger, MIDAS, Software, Other
Extendable Options = Category, Type
Required Attributes = Author, Type
Page Title = ELOG - $subject
Reverse sort = 1
Quick filter = Date, Type
Email all = lindner@triumf.ca

[root@ds-proto-daq ~]# systemctl start elogd.service
[root@ds-proto-daq ~]# systemctl is-active elogd.service
active
[root@ds-proto-daq ~]# systemctl enable elogd.service

2) Tweak apache and restart 

[root@ds-proto-daq ~]# grep elog /etc/httpd/conf.d/ssl-ds-proto-daq.conf 
ProxyPass /elog/ http://localhost:8084/ retry=1
[root@ds-proto-daq ~]# systemctl restart httpd

3) change MIDAS to use elog

[dsproto@ds-proto-daq bin]$ odbedit 
[local:dsproto:R]/>cd Elog/
[local:dsproto:R]/Elog>create STRING URL
String length [32]: 256
[local:dsproto:R]/Elog>set URL https://ds-proto-daq.triumf.ca/elog/DS+Prototype/

I added javascript webdisplay of the V1725 waveforms to the Darkside setup.  You can see the waveform display here:

https://ds-proto-daq.triumf.ca/CS/webdisplay

You can also see the webdisplay that comes built into the JSROOT webserver here:

https://ds-proto-daq.triumf.ca/rootana/

For Pierre: I went through and reset the baselines for all the channels.

First check the maximum trigger rate and maximum data rate for different sample lengths (for each channels):

sample length      Maximum rate   MB/s    CPU % (per thread)
16us               0.44kHz        231     20
6.4us              1.04kHz        214     20  
3.2us              1.95kHz        198     22   
1.6us              3.12kHz        160     26   
0.8us              4.88kHz        127     30   (what are these threads doing?)

Look at the code more.  See that there is a maximum size for the block transfer of 10kB.  Increase this to 130kB
(which is the maximum amount that this board can make per event).  Now find

sample length     Maximum rate       MB/s     CPU % (per thread)
16us              0.68kHz            346      7
6.4us             1.46kHz            300      10 
1.6us             3.6kHz             190      25

Good.  So for long samples we are actually slightly above the maximum transfer rate of 85MB/s*4 = 340MB/s

Tried writing out the data to disk at the maximum 345MB/s rate; the DAQ can't keep up.  Maximum rate was more
like 270MB/s.
I think the mlogger was actually fine.  But I think the write-to-disk speed of the harddrive could not keep up.
 So I think we are limited 
by hardware in that case.  We would need a large raid array to be able to write faster.

Pierre and I got the CERN proxy setup for the Darkside prototype.

Using your CERN single-sign-on identity, you should be able to login to this page

https://m-darkside.web.cern.ch/

and see our normal MIDAS webpage.

The CERN server is proxying the port 80 on ds-proto-daq.  You can also see all the other services through the
same page:

elog:
https://m-darkside.web.cern.ch/elog/DS+Prototype/

chronobox:
https://m-darkside.web.cern.ch/chronobox/

js-root:
https://m-darkside.web.cern.ch/rootana/


_________________________________

Technical details

1) We followed these instructions for creating a SSO-proxy:

https://cern.service-now.com/service-portal/article.do?n=KB0005442

We pointed the proxy to port 80 on ds-proto-daq

2) On ds-proto-daq, we needed to poke a hole through the firewall for port 80:


firewall-cmd --permanent --add-rich-rule="rule family="ipv4" source address="188.184.28.139/32" port
protocol="tcp" port="80" accept"
firewall-cmd --reload

[root@ds-proto-daq ~]# firewall-cmd --list-all
public (active)
...
	rule family="ipv4" source address="188.184.28.139/32" port port="80" protocol="tcp" accept

This firewall rule is pointing to some particular IP that seems to be the proxy side of the server:

[root@ds-proto-daq ~]# host 188.184.28.139
139.28.184.188.in-addr.arpa domain name pointer oostandardprod-7b34bdf1f3.cern.ch.

It is not clear if this particular IP will be stable in long term.

3) We needed to modify mhttpd so it would serve content to hosts other than localhost.  So changed mhttpd
command from 

mhttpd -a localhost -D

to 

mhttpd -D

The last elog didn't go out cleanly.  Modified the elogd.cfg to point to the proxy.  Try again.

Darkside people seem to be doing some tests at CERN next week.  It looks like they aren't going to use our DAQ (they will I think just use CAEN tools).  But we took 
opportunity to make TRIUMF DAQ work again.  There was a couple issues

1) I needed to inver the busy signal for input 0 to the chronobox in order to get any triggers out of the system.  Not sure why; I don't think I had to do that before.  But it is 
working now.

2) The CERN web proxy was not initially working.  Somehow I 'fixed' it by changing the proxy configuration variable of SERVICE_NAME from 'midas' to 'dummy'.  I don't 
understand why that fixed it.  But now you can see the DAQ here:

https://m-darkside.web.cern.ch/chronobox/

People:  Simone, Sam, Tom, Edgar

Tested IV curve python script that runs using MIDAS. Measured resistance consistant with resistor specification. elog:46/1

The resistance is attached to ch11, and we called the script (channels go from 0 to 24):
chnum=11 ; python3 iv_curve.py --no_steering --caen_chan $chnum --stop_v 3 --step_v 0.001 --filename ivcurve_`date +%s`_$chnum.txt 

Issues:

No readout of trip condiotion therefore python script overides power supply trip and attemps to bring back voltage to next value. Potentially dangerous. Script only terminates with the final voltage value. See attached plot elog:46/1

Script terminated with error message:

Traceback (most recent call last):
  File "iv_curve.py", line 287, in <module>
    iv.run()
  File "iv_curve.py", line 269, in run
    self.set_caen_and_wait_for_readback(voltage)
  File "iv_curve.py", line 223, in set_caen_and_wait_for_readback
    raise RuntimeError("CAEN HV didn't respond to request to set voltage to %s; latest readback voltage is %s" % (voltage, rdb))
RuntimeError: CAEN HV didn't respond to request to set voltage to 2.976; latest readback voltage is 0.052000001072883606