troubleshooting document updated acc to jf (#596)

* doc on troubleshooting for failure of packets

* updated troubleshooting acc to jf manual

docs/src/quick_start_guide.rst

@@ -66,11 +66,15 @@ For a Single Module
         # sets destination udp ports (not needed, default is 50001)
         udp_dstport 50012
 
+        # 1g data out
         # source udp ips must be same subnet at destintaion udp ips
-        udp_srcip 192.168.1.112
-
+        # udp_srcip 192.168.1.112
         # destination udp ip picked up from rx_hostname (if auto)
-        udp_dstip auto
+        # udp_dstip auto
+
+        # 10g data out
+        udp_srcip 10.30.20.200
+        udp_dstip 10.30.20.6
 
         # set file path
         fpath /tmp

docs/src/troubleshooting.rst

@@ -8,66 +8,101 @@ open an issue at our  `github repo issues
 Common
 ------
 
-Missing Packets
-^^^^^^^^^^^^^^^
-Possible causes could be the following:
 
-#. Receiver PC is not tuned for socket buffer size and input packet queue.
-    * Refer to :ref:`Increase rmem_default, rmem_max and max_backlog<Receiver PC Tuning>`
+1. Total Failure of Packet Delivery
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-#. Wiring
-    * Faulty wiring or connecting cable to incorrect interface.
+#. Data cable plugged into the wrong interface on board (Jungfrau)
+    * Please ensure that the data cable is plugged into the rightmost interface (default for single interface). The inner one is disabled for PCB v1.0 and must be selected via command for PCB v2.0.
 
 #. Link up and speed
-    * Check to see if there is a blue LED on board to signal that the link is up. Check ethtool and find if Link Deteced:Yes and Speed is acceptable (>10k).
+    * Check ethtool and find if Link Deteced:Yes and Speed is acceptable (>10k).
+    * Check to see if the 10G link is up (blue or red LED on board, close to SFP+). If not:
+
+       * Check transeiver and fibers are compatible (all MMF 850nm or all SMF 1030nm)
+       * Check fiber
+       * Check fiber polarity (if short range, unplug the link anywhere, and look at the light/dark pattern: dark has to mate with light)
 
 #. Detector is not acquiring (Not Eiger)
     * Take an acquisition with many images and using the following steps instead of acquire:
+
         .. code-block:: bash
 
             sls_detector_put status start
             # keep executing this command to see if the number of frames left keeps decreasing,
             # which means the detector is acquiring.
             sls_detector_get framesl 
 
-    .. note ::
-    
-        If you are using multiple modules, the previous command can return -1 because each module will return different values. Then, check for a single module instead: sls_detector_get 0:framesl
+            # If you are using multiple modules, the previous command can return -1 because each module will return different values. Then, check for a single module instead: sls_detector_get 0:framesl
 
-#. Data cable plugged into the wrong interface on board (Jungfrau)
-    * Please ensure that the data cable is plugged into the rightmost interface. The middle one is disabled for PCB v1.0 and must be selected via command for PCB v2.0.
-
-#. Detector is not sending data
-    * Check the board to see if the green LED is blinking next to the data cable, which means that the detector is sending data.
 
-#. Firewall or security feature
-    * A firewall or some security feature could be blocking the reception of data.
+#. Detector is not sending data (Except Eiger)
+    * Check the board to see if the green LED close to SFP is blinking (detector is sending data). If not, detector is not operated properly (period too short/long, no trigger in trigger mode) or misconfigured and needs reboot.
 
-#. Ethernet interface not configured properly
-    * Ensure that the interfaces used are configured properly with the right mask and ip. Eg. use ifconfig and route commands to verify.
+#. Power supply
+    * Check if power supply has enough current. 
+    * For Jungfrau, refer to :ref:`Jungfrau Power Supply Troubleshooting<Jungfrau Troubleshooting Power Supply>`.
 
 #. Ethernet interface not configured for Jumbo frames (10Gb)
-    * Ensure that the interfaces used in receiver pc have MTU 9000 (jumbo frames) enabled.
+    * Ensure that the interfaces (on NIC and the switch) used in receiver pc have MTU 9000 (jumbo frames) enabled.
+
+
+#. Check if 'rx_frames' counter in 'ifconfig' do not increment for interface.
+    * If no, check switch configuration if present. Port counters of switch can also help to identify problem.
+    * If yes, but receiver software does not see it:
+
+        * Check no firewall (eg. firewalld) is present or add rules
+        * Check that selinux is disabled ( or add rules)
+
+#. Source UDP IP in config file (Not Eiger)
+    * Ensure it is valid and does not end if 0 or 255. Also ensure that the source ip 'udp_srcip' is in the same subnet as destination ip 'udp_dstip' and the masking in the interface configuration ensures this rule.
+    * Eg. If interface IP is 102.10.10.110 and mask is 255.255.255.0, udp_srcip has to be 102.10.10.xxx (same subnet)
+    * Use ifconfig and route commands to verify etheret interface configuration
 
-#. Detector IP (Not Eiger)
-    * Ensure it is valid and does not end if 0 or 255. Also ensure that the detector ip is in the same subnet as rx_udpip and the masking in the interface configuration ensures this rule.
 
-#. Tcpdump or wireshark
+#. Netstat and netcat
+    * Try with netstat to see if its really listening to the right interface. Or netcat to see if you get packets.
+
+#. Wireshark or Tcpdump
     * Use one of these to confirm that you receive packets (with the right filtering ie. source and destination ports, ip).
 
-#. Check SFP modules
-    * Check if the SFP modules on both sides of the fiber are of same type.
+
+
+2. Partial or Random Packet Loss (Performance)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. note ::
+    
+    The following suggestions are for convenience. Please do not follow blindly, research each parameter and adapt it to your system.
+
+#. Receiver PC is not tuned for socket buffer size and input packet queue or other parameters.
+    * Refer to :ref:`Receiver PC Tuning<Receiver PC Tuning>`
+
+#. Wiring
+    * Faulty wiring or connecting cable to incorrect interface.
+
 
 #. Pinging the subnet (receiving only a few number of packets each time)
     * If a switch is used between a receiver pc and detector instead of plugging the cables directly, one might have to ping any ip in the subnet of the Ethernet interface constantly so that it does not forget the ip during operation.
     * Eg. if rx_udpip is 10.2.3.100, then ping constantly 10.2.3.xxx, where xxx is any ip other than 100.
+    * Using slsReceiver, you can use a command that does this for you:
+        .. code-block:: bash
+        
+            # arping the interface in a separate thread every minute
+            sls_detector_put rx_arping 1
 
 
 
 .. _Receiver PC Tuning:
 
 Receiver PC Tuning Options
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. note ::
+
+    | xth1 is example interface name in the following examples. 
+    | These settings are lost at pc reboot.
+
 #. Increase maximum receive socket buffer size and socket input packet queue. 
     * Temporarily (until shut down)
         .. code-block:: bash
@@ -111,6 +146,7 @@ Receiver PC Tuning Options
         # check how many GB memory you can allocate, to avoid swapping otherwise    
 
 
+
 #. Modify ethtool settings. 
     * rx ring parameters
         .. code-block:: bash
@@ -127,6 +163,9 @@ Receiver PC Tuning Options
             # check 
             ethtool -c xth1
 
+            # enable adaptive xoalescence parameters
+            ethtool -C xth1 adaptive-rx on
+
             # set to max value in your pc settings
             ethtool -C xth1 rx-usecs 100 
 
@@ -138,13 +177,18 @@ Receiver PC Tuning Options
 
             # set to max value in your pc settings
             ethtool -A xth1 rx on
- 
-    .. note ::
+    
+    * generic receiver offload (might not always work)
+        .. code-block:: bash
+
+            # check
+            ethtool -k xth1
 
-        | xth1 is example interface name. 
-        | These settings are lost at pc reboot.
+            # enable generic receiver offload
+            ethtool -K xth1 gro
+        
 
-#. Disable CPU frequency scaling and set system to performance 
+#. Disable power saving in CPU frequency scaling and set system to performance 
     * Check current policy (default might be powersave or schedutil)
         .. code-block:: bash
             
@@ -159,7 +203,10 @@ Receiver PC Tuning Options
             # set to performance
             sudo cpupower frequency-set -g performance
 
-
+            # or
+            cpufreq-info
+            for i in ‘seq 0 7‘; do cpufreq-set -c $i -g performance; done
+            
     * Permanently
         .. code-block:: bash
             
@@ -179,48 +226,87 @@ Receiver PC Tuning Options
 
         This is also set if slsReceiver is run as root user.
         
+#. Some more advanced options: 
+    .. warning ::
         
-#. Disable power saving in CPU frequency 
-    .. code-block:: bash
-
-        # or similar command depending on your distribution
-        cpupower frequency-info
-        cpupower frequency-set -g performance
+        Please do not try if you do not understand
+
+    #. reduce the number of queue per NIC to the number of expected streams: ethtool -L xth0 combined 2 
+    #. assign each queue to its stream:  ethtool -U xth0 flow-type tcp4 dst-port 50004 action 1
+    #. assign to each queue (IRQ) one CPU on the right socket:  echo "3"> /proc/irq/47/smp_affinity_list    #change the numbers looking at /proc/interrupts
+    #. disable irqbalance service 
+    #. Be sure that the switch knows the receiver mac address. Most switches reset the mac lists every few minutes, and since the receiver only receives, there is not a periodic refresh of the mac list. In this case, one can set a fixed mac list in the switch, or setup some kind of script arping or pinging out from that interface (will be available in 7.0.0). 
+    #. assign the receiver numa node (also with -m) to the socket where the NIC is attached. To know it, cat /sys/class/net/ethxxx/device/numa_node
+    #. ensure file system performance can handle sustained high data rate:
+
+        * One can use dd: 
 
-        # or
-        cpufreq-info
-        for i in ‘seq 0 7‘; do cpufreq-set -c $i -g performance; done
+            .. code-block:: bash
+	            
+                dd if=/dev/zero of=/testpath/testfile bs=1M count=100000
+        * Or better fio (which needs to be installed) 
 
+            .. code-block:: bash
+	        
+                fio --name=global –directory=/testpath/ --rw=write --ioengine=libaio --direct=0 --size=200G -- 	numjobs=2 --iodepth=1 --bs=1M –name=job
 
 slsReceiver Tuning
 ^^^^^^^^^^^^^^^^^^
 
 #. Starting receiver as root to have scheduling privileges.
 
 #. For 10g, enable flow control
+
     .. code-block:: bash
 
         sls_detector_put flowcontrol10g 1
 
-#. Increase slsReceiver fifo depth between listening and processing threads.
+#. Increase slsReceiver ring buffer depth 
+    This can be tuned depending on the number of receivers (modules) and memory available.
+
     .. code-block:: bash
 
+        # sugggested not to use more than half memory of CPU socket in case of NUMA systems) for this
+
         sls_detector_get rx_fifodepth
-        # sets number of frames in fifo to 5000
-        sls_detector_put rx_fifodepth 5000
+        # sets number of frames in fifo to 1024 ~1GB per receiver. Default is 2500
+        sls_detector_put rx_fifodepth 1024
+
+#. Increase number of frames per file 
+    This can reduce time taken to open and close files.
 
-#. Increase number of frames per file to reduce time taken to open and close files.
     .. code-block:: bash
 
         sls_detector_get rx_framesperfile
         sls_detector_put rx_framesperfile 20000
         # writes all frames into a single file
         sls_detector_put rx_framesperfile 0
 
+#. Disable file write
+    This can ensure it is not the file system performance hampering high date rate.
+
+    .. code-block:: bash
+
+        sls_detector_put fwrite 0
+
 
 Shared memory error
 ^^^^^^^^^^^^^^^^^^^
-| For errors due to access or size, delete shared memory files nd try again.
+For errors due to access or size, use any of the following suggestions.
+    #. Delete shared memory files and try again
+    #. Use environment variable to use a different shared memory ending in jfxx
+
+        .. code-block:: bash
+
+            # shared memory ending in jfxx
+            export SLSDETNAME=jfxx
+
+    #. USe a different multi shared memory ID
+        .. code-block:: bash
+    
+            sls_detector_put 2-config xxxx.config
+            # or
+            sls_detector_put 2-hostname bchipxxx
 
 To list all shared memory files of sls detector package.
     .. code-block:: bash
@@ -331,6 +417,7 @@ Cannot get multi module data
 
 #. Check :ref:`Common Multi Module Troubleshooting<common troubleshooting multi module data>`
 #. Power Supply
+    * Jungfrau needs a ~4A per module for a short time at startup. If not, it reboots misconfigured.
     * Comment out this line in the config file: powerchip 1
     * Powering on the chip increases the power consumption by a considerable amount. If commenting out this line aids in getting data (strange data due to powered off chip), then it could be the power supply current limit. Fix it (possibly to 8A current limit) and uncomment the powerchip line back in config file.
 

examples/jungfrau_two.config

@@ -5,7 +5,7 @@ detsize 1024 1024
 hostname bchip048+bchip052+
 
 # 1Gb receiver pc hostname  (default tcpport: 1954)
-rx_hostname pcmoench01+pcmoench01:1955
+rx_hostname pcmoench01:1954+pcmoench01:1955+