Week Three
09 June:
Received contact from Filipo, his suggestion was to investigate a file /etc/sysctl.conf (must have super user privilege to edit). This file apparently controls allocation of space to the UDP process which governs the data transfer in the FEC. Filipo suggested the addition of the following lines:
kernel.shmmax = 751000000
kernel.shmall = 751000000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
kernel.sem = 250 3200 32 250
Then reboot or execute /sbin/sysctl -p (as super user). Even after the addition of these lines, as well as tests using different IP addressing, message flood still appears. Need to try something else, possible this could be a hardware issue.
10 June:
Researched into the UDP settings that govern data transfer. It appears that the MSU PC did not have any changes to its UDP settings, at least not visible in the /etc/sysctl.conf file. This suggests to me that it is perfectly possible to run this SRS system without UDP alterations and message flood errors. Filipo wanted to make sure the UDP changes were being properly registered by DATE during the start of run, but I am not sure how to view this information. Filipo mentioned it should be logged by infoBrowser, but I can't see any info beyond the runControl facility.
11 June:
Found the message Filipo was referring to. To display the messages in infoBrowser, simply press the "Online" button to stop incoming messages, then under the "Level" selection pick "any" (this is in the lower left hand corner of the window). To turn messages back on, simply press "Online" again. The UDP line Filipo was concerned with reads:
UDP recvbuf size: 262142 - UDP packet size: 29 <-- before changes
UDP recvbuf size: 33552000 - UDP packet size: 3728 <-- after changes
Even with confirmation of this change occurring the message flood error is still present. Going to move everything to the PC Mark gave me, and attempt a fresh install on the 2TB drive.
12 June:
Completed a fresh install of SLC5/DATE/Amore on the CNU PC. No problems experienced during installation. Interestingly, the message flood error is now replaced by a minimum byte error. DATE is receiving an event that is 4 bytes large which appears to be under the limit to qualify as a normal event. DATE is able to successfully execute the Start of Run commands and initialize the FEC, but as soon as the slow_control start command is given and the first event is received DATE throws a fatal error and halts. Never encountered this before. SUCCESS! Of course it was a hardware issue. Alexandre stopped by at the end of the day and suggested it may be worth trying the MSU net card. He was right, plugged it in, set it up, and everything works. It seems the SRS system doesn't like ethernet ports on motherboards.
13 June:
First at data taking started. Raw data looks good, except Fec Ch. 0 is displaying junk. Not sure if this is a hardware or software issue. Luckily this issue is only limited to a single APV. Taking data to attempt analysis with the amoreSRS package from FIT. Files:
Jun13Ped.raw:/HV(g):2000/HV(p):700/Cosmics/1000e
June13Run1.raw:/HV(g):4200/HV(p):700/Cosmics/1000e
Setup was constructed with help from Mitra, illustrated in my notebook. First Cosmic signal, as well as Trigger Output shown below:
