Editing NTAF.cfg


Adding new test entries to the configuration is easy. This page will walk you through the global variables NTAF uses to communicate as well define, line by line,  each configuration option used in a test entry.
  1. [NTAF]
  2. lockfile = /tmp/ntaf.lock
  3. hostlist = 160.91.192.165 128.55.128.74 192.88.115.178
  4. DATA_DEST = x-netlog://localhost:14830
  5. REPORTER_DEST = x-netlog://bazbar.lbl.gov:14840
  6. STATUS_DEST = x-netlog://dpsslx03.lbl.gov
  7. #STATUS_DEST = /tmp/NTAF_status.log
  8. DATABASE_DEST = NTAF

  10. [DEFAULT]
  11. command =
  12. interval = 3600
  13. default_run = no
  14. net_characterization=UNDEF

  16. [Ping]
  17. command = nlping.py %s %s %s
  18. frequency = 900
  19. jitter = .25
  20. arguments = /bin/ping -q -w 10 -c 10 -s 1400 %s
  21. resource = ICMP
  22. run=yes
  23. run_time = 15

The global variables are all defined in the [NTAF] section. Each option is required. Failing to difine them will result in NTAF operating incorrectly, or not at all.

  1. A semaphore like file to handle concurrent access to the internal NTAF db. This can be any filename you want, assuming you have write priveleges to the directory you are defining.
  2. The list of remote hosts you want NTAF to run to. If this host is un-responsive, the tests to it will fail and an error condition will be recorded (Refer to the later discussion on Internal accounting for further information)
  3. Where NetLogger harneseed tests should send their results to. This address may look a bit un-familiar to you. Do not worry, this is the format NetLogger uses to declare a remote (or local) TCP connection. The 'recording' component of NTAF will automatically create a NetLogger pipe listening on this port. Your only responsibility here is to verify that port you define is not in use when NTAF is started. By default, we use port 14830.
  4. Where NTAF should send all of its managed tests results to. This is similar to the DATA_DEST except we are now explicitly sending results in NetLogger format out to a remote host that has a NetLogger pipe listening on port 14840. See the NetLogger documentation for Netarchd on how to set up this NetLogger connection. If you do not want to send out results, simply set the location to /dev/null. I.e.,
    REPORTER_DEST = /dev/null

  5. Where NTAF should send its internal accounting information to. Again, the same format as the two previous locations, This address however will log all the test invocation and error accounting that NTAF generates. If NTAF is working smoothly for you, setting the location to /dev/null will work fine.
  6. If NTAF is not running tests correctly, or something seems hung, you can forward the accounting to a local file. Beware that this will fill up the directories partition if you are running a lot of tests generating a lot of errors.
  7. The name of the internal db NTAF will use to store results. This db will not grow too large. If disk space is truly at a premium, you can locate this file to some other writable directory. We advise leaving the filename as NTAF.
  1. This default section should not be modified. It is provided as a convenience for other test entries that are not completely defined.
  1. The name of the test class. This entry should match exactly as the python test class. Refer to the README.tests to see how the test class defines what test entry it uses.
  2. The file which houses the business logic of the test class. Again, an in-depth discussion of how to build a proper test is in the README.tests. The %s %s %s is required. These act as placeholders for the arguments to run the test.
  3. How often to run the test, in seconds. If a test takes a long time to run and utilizes a great deal of CPU and/or network resources, its better to make the frequency larger. Some heuristics on a good timing interval is in the Operational Doc and the README.tests.
  4. In order to keep the test running at exactly the same interval, a small jitter value is used to randomize the frequency time a bit. Any value greater than 1 will cause scheduling conflicts. Experiment with what works best. Some heuristics on determining good jitter is in the Operational Doc.
  5. This is the raw command that your test class will invoke. It is defined here to allow the same business logic in the test class to run with different args/commands. Examine the supplied nlping.py test class to see how the %s is resolved by the getCommand() method.
  6. When running network measurements, you do not want multiple tests using the same network resource. This would cause both tests to be skewed, or in the case of UDP utilization, neither would finish! By defining a resource(s) NTAF will suspend 1 or more scheduled tests (who all want the same resource) until a running test finishes, thus releasing the resource. Defining multiple resources will cause NTAF to wait until it can get all the resources for that test. Be careful, too many resource requirements, and a test may never run.
  7. Should the test run? You can define a test entry and simply have it not run in a 'production' mode until you have debugged it or perhaps the underlying raw command has been broken.
  8. If a raw command crashes, aborts, or runs longer than designed, NTAF will take care of the killing of the test. It is recomennded that you run  the raw command, with the required args a few times outside of NTAF to get a feel for how long it runs normally. Selecting a value that is 110% of that average works good.