rtsystabの順番を入れ替えて確認を行った。

過去のデータを解析したところIPG glitchには２種類あることが分かった。

1. 連続した時刻順でロストするケース
2. 小数点以下が同じ時刻で間欠的にロストするケース
　
上記2のケースに於いて、mx_streamの転送順で、iopモデルとその次のモデルはエラーになっていないことが分かった。
(１のケースはiopも含めてglitchが発生する。)

その為、mx_streamの順番を変えた際にどうなるか試験を行った。
明日以降のIPC glitch時間に確認する。

変更点
1. バッアクアップを作成
 cd /diskless/root/etc/
 cp rtsystab rtsystab.20230721
 rtsystabの下記変更

 変更前
 k1omc0 k1iopomc0 k1visommt1 k1visommt2 k1visostm k1omc k1aso k1ascbeacon
 k1ex0 k1iopex0 k1vistmsx k1calex k1pemex0 k1tmsx
 変更後
 k1omc0 k1iopomc0 k1aso k1visommt1 k1visommt2 k1visostm k1omc  k1ascbeacon
 k1ex0 k1iopex0 k1pemex0 k1vistmsx k1calex  k1tmsx

 2. DAQ再起動を行い、k1omc0とk1ex0のmx_streamの引数の並びが変更されているか確認

---
The order of rtsystab was switched to confirm the results.

Analysis of past data revealed that there are two types of IPG glitches.

1. the case of lost in consecutive time order
(2) Intermittent glitches with the same decimal point at the same time.
　
In case 2 above, we found that the iop model and the next model in the transfer order of mx_stream were not in error.
(In case 1, glitch occurs including iop.)

Therefore, we tested what happens when the order of mx_stream is changed.
We will check it at IPC glitch time after tomorrow.

Changes
1. create backup
 cd /diskless/root/etc/
 cp rtsystab rtsystab.20230721
 Make the following changes to rtsystab

 Before change
 k1omc0 k1iopomc0 k1visommt1 k1visommt2 k1visostm k1omc k1aso k1ascbeacon
 k1ex0 k1iopex0 k1vistmsx k1calex k1pemex0 k1tmsx
 After change
 k1omc0 k1iopomc0 k1aso k1visommt1 k1visommt2 k1visostm k1omc k1ascbeacon
 k1ex0 k1iopex0 k1pemex0 k1vistmsx k1calex k1tmsx

 2. restart DAQ and check if the order of mx_stream arguments in k1omc0 and k1ex0 has been changed