The data is organized into sixteen directories, one per laptop. Each directory contains a set of log files. The first step in any analysis is to merge together the desired per-machine log files. As we proceed with the analysis, we can build up a library of merge scripts.
There are many log files in each directory. For now, I describe only the four most important, namely the position and network-statistics log files. I also describe weaknesses in the current log formats and contents that we will try to correct in time for the next demo run.
gps.log
This file is a log of the laptop's position. It is a text file with one "record" per line. There are four record types:
timestamp is the number of seconds since Midnight UST, January 1, 1970 (floating number accurate to hundreths of a second), latitude is the latitude expressed in degrees (floating point with a leading + or -), longitude is the longitude expressed in degress (floating point with a leading + or -), and fix-status is one of the three strings, no-fix, 2d-fix or 3d-fix. fix-status indicates whether the GPS unit has acquired a position lock.
BROADCAST means that the GPS agent sent the current position to the (local) broadcast system for transmission to all other laptops. BROADCAST_SKIP means that the laptop skipped this step since no position was yet available.
Weakness: In run1, three laptops (soldier09, soldier52 and soldier63) never acquired a position lock due to a bug in my startup script.
Weakness: The curly brackets in the POSITION record are annoying and will be removed.
bcast.log
This log file records when the broadcast system actually sent the GPS positions to all neighbor laptops. Transmission is accomplished with a single-hop multicast. Each transmission includes every (currently) known GPS position.
The log file is a text file with one "record" per line. There is only one record type:
where timestamp is as before, and bytes is the size of the multicast payload in bytes.
aprl2.log
This log file describes the changes the Aprl makes to the routing table. It is a text file with one "record" per line. There are three meaningful record types:
where timestamp is as before, and the IP fields are an IP address in standard dotted notation, e.g., 10.0.0.10. Note that the subdirectories match the IP addresses, e.g., the soldier10 directory contains the log files for the laptop with IP address 10.0.0.10.
APRL_START indicates that APRL has just started or has just re-started after a crash. Aprl crashed once or twice per machine during run1. Fortunately, Aprl re-establishes the routing table very quickly after a restart.
Weakness: The log file also contains APRL ADD and APRL REMOVE records, which are meant to describe the changes the Aprl makes to its own internal routing table. However, due to a coding mistake, we are only logging those changes that involve a new destination. Thus the APRL ADD and APRL REMOVE records are not particularly useful.
Weakness: We should also log the payload size of every beacon or PSVN that Aprl sends and receives.
netstats.log
This log contains a running transcript of every network statistic of which we could think. It is again a text file with one record per line. There are three record types:
The first element in each line is again the timestamp.
The WAVELAN2_SIGNAL records report the signal and noise levels for the Wavelan2 cards. However, it turns out that the Wavelan2 cards always report a signal and noise level of 0 when they are in peer-to-peer mode. Thus you can ignore the WAVELAN2_SIGNAL records.
The KERNEL_TALLIES line reports the standard counts maintained by the kernel. From left to right, we have
I do not know what Received packets compressed and Transmitted packets compressed actually measure, but they seem to always be zero.
For the WAVELAN2_TALLIES (which are statistics maintained by the Wavelan 2 card), I simply re-produce part of my logging system:
fprintf (fp,
"%lf WAVELAN2_TALLIES %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u\n",
getCurrentTime(),
pTallies.TxUnicastFrames,
pTallies.TxMulticastFrames,
pTallies.TxFragments,
pTallies.TxUnicastOctets,
pTallies.TxMulticastOctets,
pTallies.TxDeferredTransmissions,
pTallies.TxSingleRetryFrames,
pTallies.TxMultipleRetryFrames,
pTallies.TxRetryLimitExceeded,
pTallies.TxDiscards,
pTallies.RxUnicastFrames,
pTallies.RxMulticastFrames,
pTallies.RxFragments,
pTallies.RxUnicastOctets,
pTallies.RxMulticastOctets,
pTallies.RxFCSErrors,
pTallies.RxDiscards_NoBuffer,
pTallies.TxDiscardsWrongSA,
pTallies.RxWEPUndecryptable,
pTallies.RxMsgInMsgFragments,
pTallies.RxMsgInBadMsgFragments
);
Note: All counts are totals, e.g., the total number of bytes received since the machine was turned on. Many analyses might require the calculation of deltas.
Weakness: The network statistics were only recorded once every five seconds. We will record once every second on the next demo run.
The data is organized into sixteen directories, one per laptop. Each directory contains a set of log files. The first step in any analysis is to merge together the desired per-machine log files. As we proceed with the analysis, we can build up a library of merge scripts.
There are many log files in each directory. For now, I describe only the four most important, namely the position and network-statistics log files. I also describe weaknesses in the current log formats and contents that we will try to correct in time for the next demo run.
gps.log
This file is a log of the laptop's position. It is a text file with one "record" per line. There are four record types:
timestamp is the number of seconds since Midnight UST, January 1, 1970 (floating number accurate to hundreths of a second), latitude is the latitude expressed in degrees (floating point with a leading + or -), longitude is the longitude expressed in degress (floating point with a leading + or -), and fix-status is one of the three strings, no-fix, 2d-fix or 3d-fix. fix-status indicates whether the GPS unit has acquired a position lock.
BROADCAST means that the GPS agent sent the current position to the (local) broadcast system for transmission to all other laptops. BROADCAST_SKIP means that the laptop skipped this step since no position was yet available.
bcast.log
This log file records when the broadcast system actually sent the GPS positions to all neighbor laptops. Transmission is accomplished with a single-hop multicast. Each transmission includes every (currently) known GPS position.
The log file is a text file with one "record" per line. There is only one record type:
where timestamp is as before, bytes is the size of the multicast payload in bytes, and source-ip is the IP address of the machine from which the multicast was received. (Note that the MULTICAST event would be better named as MULTICAST_TX.)
aprl2.log
This log file describes the changes the Aprl makes to the routing table. It is a text file with one "record" per line. There are three meaningful record types:
where timestamp is as before, and the IP fields are an IP address in standard dotted notation, e.g., 10.0.0.10. Note that the subdirectories match the IP addresses, e.g., the soldier10 directory contains the log files for the laptop with IP address 10.0.0.10.
APRL_START indicates that APRL has just started or has just re-started after a crash. Aprl crashed two or three times per machine during run 2. Fortunately, Aprl re-establishes the routing table very quickly after a restart.
netstats.log
This log contains a running transcript of every network statistic of which we could think. It is again a text file with one record per line. There are three record types:
The first element in each line is again the timestamp.
The WAVELAN2_SIGNAL records report the signal and noise levels for the Wavelan2 cards. However, it turns out that the Wavelan2 cards always report a signal and noise level of 0 when they are in peer-to-peer mode. Thus you can ignore the WAVELAN2_SIGNAL records.
The KERNEL_TALLIES line reports the standard counts maintained by the kernel. From left to right, we have
I do not know what Received packets compressed and Transmitted packets compressed actually measure, but they seem to always be zero.
For the WAVELAN2_TALLIES (which are statistics maintained by the Wavelan 2 card), I simply re-produce part of my logging system:
fprintf (fp,
"%lf WAVELAN2_TALLIES %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u\n",
getCurrentTime(),
pTallies.TxUnicastFrames,
pTallies.TxMulticastFrames,
pTallies.TxFragments,
pTallies.TxUnicastOctets,
pTallies.TxMulticastOctets,
pTallies.TxDeferredTransmissions,
pTallies.TxSingleRetryFrames,
pTallies.TxMultipleRetryFrames,
pTallies.TxRetryLimitExceeded,
pTallies.TxDiscards,
pTallies.RxUnicastFrames,
pTallies.RxMulticastFrames,
pTallies.RxFragments,
pTallies.RxUnicastOctets,
pTallies.RxMulticastOctets,
pTallies.RxFCSErrors,
pTallies.RxDiscards_NoBuffer,
pTallies.TxDiscardsWrongSA,
pTallies.RxWEPUndecryptable,
pTallies.RxMsgInMsgFragments,
pTallies.RxMsgInBadMsgFragments
);
Note: All counts are totals, e.g., the total number of bytes received since the machine was turned on. Many analyses might require the calculation of deltas.
Note: We logged the network statistics every second during run 2.
The data is organized into sixteen directories, one per laptop. Each directory contains a set of log files. The first step in any analysis is to merge together the desired per-machine log files. As we proceed with the analysis, we can build up a library of merge scripts.
There are many log files in each directory. For now, I describe only the four most important, namely the position and network-statistics log files. I also describe weaknesses in the current log formats and contents that we will try to correct in time for the next demo run.
gps.log
This file is a log of the laptop's position. It is a text file with one "record" per line. There are four record types:
timestamp is the number of seconds since Midnight UST, January 1, 1970 (floating number accurate to hundreths of a second), latitude is the latitude expressed in degrees (floating point with a leading + or -), longitude is the longitude expressed in degress (floating point with a leading + or -), and fix-status is one of the three strings, no-fix, 2d-fix or 3d-fix. fix-status indicates whether the GPS unit has acquired a position lock.
BROADCAST means that the GPS agent sent the current position to the (local) broadcast system for transmission to all other laptops. BROADCAST_SKIP means that the laptop skipped this step since no position was yet available.
bcast.log
This log file records when the broadcast system actually sent the GPS positions to all neighbor laptops. Transmission is accomplished with a single-hop multicast. Each transmission includes every (currently) known GPS position.
The log file is a text file with one "record" per line. There is only one record type:
where timestamp is as before, bytes is the size of the multicast payload in bytes, and source-ip is the IP address of the machine from which the multicast was received. (Note that the MULTICAST event would be better named as MULTICAST_TX.)
aprl2.log
This log file describes the changes the Aprl makes to the routing table. It is a text file with one "record" per line. There are three meaningful record types:
where timestamp is as before, and the IP fields are an IP address in standard dotted notation, e.g., 10.0.0.10. Note that the subdirectories match the IP addresses, e.g., the soldier10 directory contains the log files for the laptop with IP address 10.0.0.10.
APRL_START indicates that APRL has just started or has just re-started after a crash. Aprl crashed two or three times per machine during run 3. Fortunately, Aprl re-establishes the routing table very quickly after a restart.
netstats.log
This log contains a running transcript of every network statistic of which we could think. It is again a text file with one record per line. There are three record types:
The first element in each line is again the timestamp.
The WAVELAN2_SIGNAL records report the signal and noise levels for the Wavelan2 cards. However, it turns out that the Wavelan2 cards always report a signal and noise level of 0 when they are in peer-to-peer mode. Thus you can ignore the WAVELAN2_SIGNAL records.
The KERNEL_TALLIES line reports the standard counts maintained by the kernel. From left to right, we have
I do not know what Received packets compressed and Transmitted packets compressed actually measure, but they seem to always be zero.
For the WAVELAN2_TALLIES (which are statistics maintained by the Wavelan 2 card), I simply re-produce part of my logging system:
fprintf (fp,
"%lf WAVELAN2_TALLIES %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u %u\n",
getCurrentTime(),
pTallies.TxUnicastFrames,
pTallies.TxMulticastFrames,
pTallies.TxFragments,
pTallies.TxUnicastOctets,
pTallies.TxMulticastOctets,
pTallies.TxDeferredTransmissions,
pTallies.TxSingleRetryFrames,
pTallies.TxMultipleRetryFrames,
pTallies.TxRetryLimitExceeded,
pTallies.TxDiscards,
pTallies.RxUnicastFrames,
pTallies.RxMulticastFrames,
pTallies.RxFragments,
pTallies.RxUnicastOctets,
pTallies.RxMulticastOctets,
pTallies.RxFCSErrors,
pTallies.RxDiscards_NoBuffer,
pTallies.TxDiscardsWrongSA,
pTallies.RxWEPUndecryptable,
pTallies.RxMsgInMsgFragments,
pTallies.RxMsgInBadMsgFragments
);
Note: All counts are totals, e.g., the total number of bytes received since the machine was turned on. Many analyses might require the calculation of deltas.
Note: We logged the network statistics once every 3 seconds during run 3.