Troubleshooting
If something is missing, don’t hesitate to open an issue at our github repo issues.
Common
1. Total Failure of Packet Delivery
- 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 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)
For Jungfrau, check if the blue sfp light is blinking rapidly (even when it is not sending data). If so, most likely the link is down and something is wrong with the board. If it connected to a switch, then you do not see it with the ethtool command if link is down. One option is to connect it directly to a pc to see if link is down.
With nc, try “nc -u -p 50001 -l” in receiving pc, and from another pc try “echo hallo | nc -u 10.1.2.172 50001” to send something to the recieving pc interface to see if the link is up and see if the other nc console receives the hallo.
- Detector is not acquiring (Not Eiger)
Take an acquisition with many images and using the following steps instead of acquire:
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 # 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
- 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.
- Power supply
Check if power supply has enough current.
For Jungfrau, refer to Jungfrau Power Supply Troubleshooting.
- Ethernet interface not configured for Jumbo frames (10Gb)
Ensure that the interfaces (on NIC and the switch) used in receiver pc have MTU 9000 (jumbo frames) enabled.
- Check if ‘rx packets’ 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
# Stop and disable firewall service firewalld stop systemctl disable firewalld # Check status service firewalld status
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
- 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).
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 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:
# arping the interface in a separate thread every minute sls_detector_put rx_arping 1
- Only the slaves get no data
Check trigger cabling and trigger configuration
When you cannot stop Jungfrau slaves in sync mode, refer to Cannot stop slaves.
Receiver PC Tuning Options
Note
- Increase maximum receive socket buffer size and socket input packet queue.
- Temporarily (until shut down)
# check size sysctl -a | grep rmem sysctl -a | grep backlog # set max and default (use 1Gb for Jungfrau and 100Mb for others) sysctl net.core.rmem_max=$((100*1024*1024)) sysctl net.core.rmem_default=$((100*1024*1024)) sysctl net.core.netdev_max_backlog=250000
- Permanently
# edit /etc/sysctl.conf file # set max and default (use 1Gb for Jungfrau and 100Mb for others) net.core.rmem_max = 104857600 net.core.rmem_default= 104857600 net.core.netdev_max_backlog = 250000 # save file and run the following sysctl -p
Note
This is the most basic setting, which is sometimes more than enough.
- For 10Gb,
MTU must be set up to 9000 for jumbo frames on detector, switch and server NIC
Set up static MAC address tables with separated VLANs
- Write to memory if not a large disk and pc not fast enough.
mount -t tmpfs none /ramdisk_folder # or mount -t tmpfs none /mnt/ramdisk -o size=10G # check how many GB memory you can allocate, to avoid swapping otherwise
- Modify ethtool settings.
- rx ring parameters
# check ethtool -g xth1 # set to max value in your pc settings ethtool -G xth1 rx 4096
- coalesce settings (might not always work)
# 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
- pause parameters
# check ethtool -a xth1 # set to max value in your pc settings ethtool -A xth1 rx on
- generic receiver offload (might not always work)
# check ethtool -k xth1 # enable generic receiver offload ethtool -K xth1 gro
- Disable power saving in CPU frequency scaling and set system to performance
- Check current policy (default might be powersave or schedutil)
# check current active governor and range of cpu freq policy cpupower frequency-info --policy # list all available governors for this kernel cpupower frequency-info --governors
- Temporarily (until shut down)
# 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
# edit /etc/sysconfig/cpupower to preference # enable or disable permanently sudo systemctl enable cpupower
- Give user speicific user scheduling privileges.
# edit /etc/security/limits.conf # add following line or similar depending on your distribution username rtprio 99
Note
This is also set if slsReceiver is run as root user.
- Some more advanced options:
Warning
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:
dd if=/dev/zero of=/testpath/testfile bs=1M count=100000
Or better fio (which needs to be installed)
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
sls_detector_put flowcontrol10g 1
- Increase slsReceiver ring buffer depth
This can be tuned depending on the number of receivers (modules) and memory available.
# 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 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.
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.
sls_detector_put fwrite 0
Cannot connect to detector
- Ensure both control and stop servers are running on the detector.
ps -ef | grep jungfrauDetectorServer*
Cannot connect to receiver
Start receiver before running a client command that needs to communicate with receiver.
Receiver: cannot bind socket
- slsReceiver or slsMultiReceiver is already open somewhere.
Kill it and restart it.
- Tcp port is in use by another application.
- Start Receiver with a different tcp port and adjust it config file
# restart receiver with different port slsReceiver -t1980 # adjust in config file rx_hostname pcxxxx:1980
Cannot get multi module data
Possible causes could be the following:
- Network
If you have a direct connection, check to see if the network cables are connected correctly to corresponding interfaces on the PC side. Check also the network configuration and that the detectors and receivers are in the corresponding subnet.
- Power Supply
Check power supply current limit.
For Jungfrau, refer to Jungfrau Power Supply Troubleshooting.
Cannot ping module (Nios)
If you executed “reboot” command on the board, you cannot ping it anymore unless you power cycle. To reboot the controller, please use the software command (“rebootcontroller”), which talks to the microcontroller.
Gotthard2
Cannot get data without a module attached
You cannot get data without a module attached as a specific pin is floating. Attach module to get data.
Gotthard
Missing first frame or next frame after a delay
Connect the data link from the Module directly to receiver pc or to a private network.
Jungfrau
Temperature event occured
This will occur only if: * temp_threshold (threshold temperature) has been set to a value * temp_control (temperature control) set to 1 * and the temperature overshooted the threshold temperature.
Consequence * sls_detector_get temp_event will give 1 # temperature event occured * the chip will be powered off
Solution * Even after fixing the cooling, any subsequent powerchip command will fail unless the temperature event has been cleared.
- Clear the temperature event
# gives the current chip power status (zero currently as chip powered off) sls_detector_get powerchip # clear temperature event sls_detector_put temp_event 0 # power on the chip sls_detector_put powerchip 1
Cannot get 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.
Cannot stop slaves in sync mode
If cabling is accessible, ensure termination board and flatband cable between the masters and the slaves are connnected properly. Then try to stop.
If cabling is inaccessible, unsync first so that the slaves can get the stop directly from the client using the command. Then, don’t use sync mode until the cabling is fixed.
# unsync, slaves command will fail as it is still in waiting state sls_detector_put sync 0 # stop should now be successful as master does not determine the stop anymore sls_detector_put stop