The testing tools outlined on this page allow to test the server and client-server connection in various ways.

• General Connection Testing Tool
  • Features
  • Usage
• Latency Testing Tool
  • Usage
  • Configuration
  • Collected Data
  • Performance Notes

This tool is targeted towards general usage testing.

It was used to confirm the implementation of both the server as well as the connection implementation for the frontend.

• Configurable user authentication: user type, experimenter password or participant id and session id can be configured before starting the connection
• Local & Remote Peer Streams: ability to see the own and other users streams
• API Testing: test a selection of API endpoints to confirm their functionality. Can easily be expanded to test new endpoints
  • Focused on API endpoints for managing experiments. Allows conducting experiments with multiple experimenters & participants within only this tool
• Filter Presets: pre-configured SET_FILTERS requests to test filters. Also easily expandable to test new filters or filter configurations and combinations
• Server Responses: View message history for messages received from server (bottom of page)

API buttons and Filter Presets are both visible for all user types. This allows testing of access restrictions, like testing the server behavior if a API endpoint is called that is not accessible to the current user type (request is ignored)

1. Open the frontend and navigate to /connectionTest (e.g. localhost:8080/connectionTest).

   • Tip (optional): Add sessionId, participantId or experimenterPassword to the url to avoid reentering the information when reloading (e.g.: localhost:8080/connectionTest?participantId=<abc>&sessionId=<123>)

2. Enter or confirm User Type, Session and Participant ID or Experimenter Password on top of the page (inside orange bar)

3. Click START CONNECTION to connect to the server

Take a look at the browser console. The UI of the testing page is not designed to display everything that happens regarding the connection, only to interact with it.

The latency testing tool was designed to test the end-to-end video latency and the API RTT.

The end-to-end video latency is tested by adding a QR-Code with a timestamp to to the local video feed before sending it. For each incoming frame, the QR-Code is then analyzed and the time difference calculated.

Unless you want to just conduct a quick test, please take a look at Performance Notes before testing.

1. Open the frontend and navigate to /connectionLatencyTest (e.g. localhost:8080/connectionLatencyTest).
   • Tip (optional): Add sessionId and participantId to the url to avoid reentering the information when reloading (e.g.: localhost:8080/connectionLatencyTest?participantId=<abc>&sessionId=<123>)
2. Configure the experiment, see configuration for details
3. Click START EXPERIMENT to start the experiment
   • In case noting happens, take a look at the browser console. The configured framerate or video dimensions might not be possible with you input device
4. Let the experiment run. Real-time information including the runtime can be seen on top
5. To stop the experiment, click STOP EXPERIMENT
   • Wait a few seconds for the results to be collected. The page might be unresponsive during this time (depends on the length of the experiment / data size)
6. Finish experiment & analyze results
   • Download & save the results by clicking the DOWNLOAD RAW DATASET button bellow the video. See collected data to see what data was collected
   • Take a look at the overview and graphs on the lower part of the page
   • To focus on a specific section of the measurements, change the Data Interval. This will change the data in Overview and the graphs

• Session ID: session ID used for the connection
• Participant ID: participant ID used for the connection
• Frames per Second: frame rate for input video. Must be supported by the input device (camera)
• Background Video: if false, no background video will be used (blank background). If true, the feed from the webcam will be used as a background.
• Video width (px): input video width. Must be supported by the input device (camera)
  • WebRTC might temporarily decrease the video dimensions
• Video height (px): input video height. Must be supported by the input device (camera)
  • WebRTC might temporarily decrease the video dimensions
• QR Code Size (px): size (width & height) for the QR-Code. Smaller QR-Codes reduce the time required to parse them and lower the load on the CPU. Too small and parsing might be a problem, resulting in "invalid Data Points".
  • WebRTC might temporarily decrease the video dimensions, which will affect the QR-Code size and can lead to "invalid Data Points" if QR Code Size (px) is too small
  • The optimal value depends on the video width and height. Increase if the results show "invalid Data Points", decrease to improve general performance
  • If the latency value shown on top of the config during an measurement is "0.00ms", the QR-Code is likely too small to be parsed. In general, latency: 0.00ms means that the tool failed to parse the incoming frame
• Print Time: If true, the timestamp will additionally be printed on the input video
• Ping API (once per frame): En-/Disable API RTT testing. If true, a ping message will be sent with every frame. Therefore the interval depends on the Frames per Second option
• Optional Ping Data Size (bytes): Amount of random additional ping data that should be added to each request.
  • Note that WebRTC will likely close the datachannel if messages with more than ~64Kib are send. See this article
• Outline QR Code (Debug): Debugging option, outlines the area in the input video that the QR-Code is expected in. Only this area is parsed to reduce parsing time. Leave unchecked / false
• Connection Log (Debug): En-/Disable connection logging in the frontend (browser console)

• latency number: time difference between time received from incoming frame with QR-code and time it was received
• fps number: frame rate of remote (incoming) stream
• timestamp number: time the latency measurement was taken in time since the document's time origin, see time-origin
• qrCodeTimestamp number: timestamp contained in the incoming frame's QR-code
• frame number: recorded frame number
• latencyMethodRuntime number: runtime of latency detection, including QR-code parsing. Can be used for debugging
• dimensions {width: number; height: number;}: dimensions of incoming frame
• qrCodeGenerationTime number: runtime of QR-code generation, which happens after taking the timestamp for the QR-code was taken, and before it sent to the server
• trueLatency number: trueLatency = latency - qrCodeGenerationTime error corrected latency
• ping.rtt number: API RTT
• ping.timeToServer number: API ping time the message needed to the server.
  • Note that the server time used for this measurement is not as accurate as the browser time. This can lead to measurements of 0ms. Therefore this measurement should be taken with a grain of salt
• ping.timeBack number: API ping time the message needed from the server back.
  • Note that the server time used for this measurement is not as accurate as the browser time. This can lead to measurements of 0ms. Therefore this measurement should be taken with a grain of salt

Important notes for conducting measurements:

• To improve consistency between tests, disable any CPU boost feature and set it to a fixed frequency. This has shown to notably impact result consistency.
• Avoid other background tasks and close all other browser tabs and instances
• Disable logging or set it to WARNING (log and log_dependencies in backend/config.json). Otherwise each ping message will be logged

General notes regarding the tools performance compared to the main UI and General Connection Testing Tool:

• The usage of the QR-Code seems to increase the probability of WebRTC reducing the video dimensions. This could be caused by a high load on the encoders and decoders. Choosing a small QR-Code size is recommended, see: Configuration -> QR Code Size (px)