Recording only certain Vectors

[David van Wyk]

I am running a massive simulation that needs to record Round Trip times, queuing times and lengths, end-to-end delays and throughput (from a throughput meter).

The problem is that these are taking up huge amounts of space (~50GB per simulation) because I cannot figure out how to ONLY enable recording of those vectors. 

At the moment I have the following declared in my .ini file (pretty much straight from the user manual) but it does not seem to work.

#**.vector-recording = true

sim-time-limit = 160s

# Vectors to Turn on for Recording

**.tcp.cwnd.vector-recording = true

**.queueLength.vector-recording = true

**.pingApp[*].rtt.vector-recording = true

**.tcpApp[1].endToEndDelay.vector-recording = true

**.tcpApp[1].numActiveSessions.vector-recording = true

#Vectors to Turn off for Recording

**.ppp.**.vector-recording = false

**.tcp.**.scalar-recording = false

**.txState.vector-recording = false

**.rcvdPk.vector-recording = false

**.txPk.vector-recording = false

**.tcp.**.vector-recording = false

**.pingApp[*].**.vector-recording = false

**.tcpApp[1].**.vector-recording = false

Could anybody please tell me what I am doing wrong and how I can go about fixing it?

[Rudolf Hornig]

The ptatern matcher in INI file always applies the first pattern matching in the file starting from the top. This means that the order of patterns are important. First enable the recording on all vectors you need and then disable the rest with 

**.vector-recording = false

which will disable ALL vectors not explicitly enabled before the line.

[David van Wyk]

Alright I will give that a try! Thanks for the quick response. Can you tell me if what I am doing by trying to record the RTT times and end-to-end delays correct? Is it as simple as making sure that the spelling is just the same as the vector being recorded?

Like this?

**.endToEndDelay.vector-recording = true

[elif.c...@gmail.com]

Hello,
   Prevously I was using UDP and everything was good. Now I use TCP with below configuration
**.endToEndDelay.scalar-recording = true

It does not give the endToEndDelay value. All entries are 0 except count. PFB a sample value:
field count 881
field mean 0
field stddev 0
field sum 0
field sqrsum 0
 
 Why is it not giving any value for TCP?

Note: Other parameters are properly recorded. Problem is only with endToEndDelay

[Michael Kirsche]

Maybe your TCP application does not record the end-to-end delay like it was done in the UDP application.

Check the source code of the actual TCP application and compare it to the UDP application to see where and how the endToEndDelay scalar was recorded and (if necessary) port it into the TCP application.
Also, be mindful of the "calculation" in TCP, as transmissions are acknowledged in TCP, so your end-to-end delay could be calculated with the acknowledgments included or without. Depends on what you actually require.