No, dont use tcptrace, dont know what xpl format is.
Does this solve your problem?
Assuming you want the throughput in 3 second intervals for the TCP session
from 65.208.228.222:80 to 10.1.1.101:1271 :
tethereal -r <capture file> -R "not frame" -z
"io,stat,3,ip.src==65.208.228.222 and ip.dst==10.1.1.101 and tcp.src==80 and
tcp.dst==1271"
==>
===================================================================
IO Statistics
Interval: 3 secs
Column #0: ip.src==65.208.228.222 and ip.dst==10.1.1.101 and tcp.srcport==80
and
tcp.dstport==1271
| Column #0
Time |frames| bytes
0- 3 71 101814
3- 6 87 124758
6- 9 67 96078
9- 12 80 114720
12- 15 14 20076
===================================================================
this measures the amount of bytes transfered in total in each 3 second
interval in this direction of the session.
it would be trivial with head,tail,grep and sed to convert this table into
whatever format you want it in.
see man tethereal for desription on how to use -z arguments.
-R "not frame" is a simple trick to make tethereal not output any summary
lines and only print the stats table.
it would be trivial to encapsulate this inside a loop that first scans the
capture for every tcp session in there, and then call tethereal to calculate
the
stats for each individual direction of each session.
Or provide a second filter string to the option and get another column for
the amount of data in the other direction:
==>
$ ./tethereal.exe -r test.cap -R "not frame" -z
"io,stat,3,ip.src==65.208.228.2
22 and ip.dst==10.1.1.101 and tcp.srcport==80 and
tcp.dstport==1271,ip.src==10.
1.1.101 and ip.dst==65.208.228.222 and tcp.srcport==1271 and
tcp.dstport==80"
===================================================================
IO Statistics
Interval: 3 secs
Column #0: ip.src==65.208.228.222 and ip.dst==10.1.1.101 and tcp.srcport==80
and
tcp.dstport==1271
Column #1: ip.src==10.1.1.101 and ip.dst==65.208.228.222 and
tcp.srcport==1271 a
nd tcp.dstport==80
| Column #0 | Column #1
Time |frames| bytes |frames| bytes
0- 3 71 101814 48 2628
3- 6 87 124758 58 3132
6- 9 67 96078 48 2724
9- 12 80 114720 53 2862
12- 15 14 20076 8 432
===================================================================
tethereal is your friend.
----- Original Message -----
From: victor.lee
Sent: Tuesday, April 01, 2003 8:17 PM
Subject: RE: [Ethereal-users] TCP performance measurment in csv format
Hi Ronnie,
Thanks for your reply.
Could someone has used the tcptrace output file (in xpl format) to obtain a
csv file which has the throughput value in different time intervals (say
time interval of 5s) ?
Thanks for your help first.
BR
Victor
-----Original Message-----
From: ext Ronnie Sahlberg
Sent: Tuesday, April 01, 2003 5:16 PM
To: Lee Victor (NET/HongKong); ethereal-users@xxxxxxxxxxxx
Subject: Re: [Ethereal-users] TCP performance measurment in csv format
You should be able to do some tethereal + perl magic to do that.
Something similar is already available in ethereal if you just want to
verify that
bulk tcp transfers are behaving properly:
The 5 second method to verify if the tcp layer is a-ok or not for optimal
throughput for bulk transfers:
==================================================
Select one packet in the direction of the tcp bulk transfer performane
analysis.
Select Tools/TCP Stream Analysis
Apply eyeball to graph:
* If after zooming in looks like a straight line from bottom left to top
right corner
everything is a-ok on the tcp layer.
* If you get a staircase where the height of each step is approximately the
same height
you have a problem with tcp window size being too small.
The width of each step should only vary a little and is the RTT for the
flow.
This effect is caused by having the tcp window smaller than what can be
transmitted end-to-end during one RTT and this small tcp window size is
capping throughput.
Increase the tcp window size to compensate for the end to end latency.
* If you get a staircase with different heights of the steps and also widely
varying lengths of the steps, with some steps being very long/wide. Then
what you see is normal (i.e. non-fast) tcp
retransmissions which kills your performance.
Ivestigate what is causing the congestion/packet-loss and reduce it and
performance will
be enhanced.
This often means that the tcp window size is too high and that this causes
bursts that will overflow
a buffer somewhere.
----- Original Message -----
From: victor.lee
Sent: Tuesday, April 01, 2003 12:12 AM
Subject: [Ethereal-users] TCP performance measurment in csv format
Hi,
I would like to know if there is a good method to calculate the end-to-end
TCP throughput against time and converted the result into a csv file in
other for further Excel post-processing.
Cheers,
Victor Lee
_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users
