![wireshark sum iograph wireshark sum iograph](https://i.imgur.com/KEZXwQv.jpg)
By breaking these out into two different graphs we can see the amount of data traveling in a single direction. For each graph we will apply the Sum() function with the tcp.len filter.
![wireshark sum iograph wireshark sum iograph](https://i3.read01.com/SIG=3c2c2tv/30424e735a743038.jpg)
We’ll setup two graphs, one using the client IP 192.168.1.4 as the source, and the other using the client IP as a destination. Let’s look at the TCP length example first. Two common use cases for this are to look at the amount of TCP data in a capture and to examine TCP sequence numbers. The Sum() function adds up the value of a field. The count() function is useful for graphing some of the TCP analysis flags that we looked at in the first blog post such as retransmissions. If you see relatively low average times between frames and then a sudden jump at one point in time you can click that frame and narrow in to see what happened at that point in time. This capture had latency and packet loss purposely introduced to exaggerate the types of data you might be able to gather from these graphs but apply to any type of capture you are troubleshooting. If we wanted to zoom into that specific frame and see what was going on we can just click on the point in the graph and it will jump to that frame in the window in the background, which is frame #1003 in the capture if you are looking at the capture. 7 seconds, which is pretty awful and a result of the latency and packet loss I introduced to this example. Looking at the graph we can see that at 90 seconds the MAX lta_time for traffic in the capture was almost. Set the style to ‘FBar’ because it displays the data nicely.Applied each calculation on the filter criteria ‘frame.time_delta’Set the style to ‘FBar’ because it helps display the data the best.Used three different graphs each with a different calculation – Min(),Avg(), and Max().Filtered on only the HTTP communication between two specific IP addresses using the filter ‘(ip.addr=192.168.1.4 & ip.addr=128.173.87.169) & http’.The time interval for the x-axis is 1 second, so each bar you see on the graph represents the calculations for that 1 second interval.If you don’t set this you’ll never see the option to perform calculations. Set the Y-Axis Unit to “Advanced” to make the Calculation fields visible.If you were looking at a capture that contained multiple conversations between different hosts and wanted to focus on only one pair of hosts you could combine the ‘frame.time_delta’ filter with the source and destination hosts in a filter like ‘ip.addr=x.x.x.x & ip.addr=y.y.y.y’. We can combine these functions with the filter ‘frame.time_delta’ to get a visual representation of time between frames and make increases in round trip latency more visible. This is useful to see latency between individual frames/packets. Min(), Avg(), and Max() Function Exampleįor the first example we’ll look at the minimum, average, and maximum times between frames that are sent. Let’s look at a few of these functions in action. LOAD(*) – Used for response time graphs.COUNT(*) – Counts the number of occurrences of the field seen during a tick interval.MAX(*) – Plots the maximum value seen for that field in the tick interval.AVG(*) – Plots the average value seen for that field in the tick interval.MIN(*) – Plots the minimum value seen for that field in the tick interval.SUM(*) – Adds up and plots the value of a field for all instances in the tick interval.There are 6 functions available for use in the IO Graphs:
![wireshark sum iograph wireshark sum iograph](https://www.linuxtechi.com/wp-content/uploads/2019/12/Single-UserMode-CentOS8-RHEL8-160x160.png)
In this post I’ll cover one additional feature: functions. In part 1 of this blog post I covered the basics of using IO Graphs.