home *** CD-ROM | disk | FTP | other *** search
/ Shareware 1 2 the Maxx / sw_1.zip / sw_1 / DISK_CHK / BENCH60.ZIP / BENCH6DB.TXT < prev    next >
Text File  |  1992-02-07  |  19KB  |  427 lines
  1. PC Magazine Labs
  2. Benchmark Series - Release 6.0
  3.  
  4.  
  5.                      Database Definition
  6.                      ===================
  7.  
  8. INTRODUCTION
  9.  
  10. The heart of the PC Labs Benchmark Series - Release 6 (Bench6)
  11. is its database. This set of four dBase compatible files and
  12. their associated indexes contain information about the various
  13. tests as well as descriptions of machines and the results they
  14. generated.
  15.  
  16. Bench 6.0 was designed to have a "soft" menu structure. That
  17. is, the menus are generated from information in the database
  18. each time the program is run. If a test is added to the
  19. database it will appear on the menu the next time you use the
  20. program. At this time only the Performance menu choice is soft
  21. but future releases will expand this concept into the
  22. Compatibility and Quality menu areas as well. What you see
  23. when you pull down the Performance menu are the test groups
  24. entered into the TSTGROUP.DBF file. The specific tests listed
  25. in the test selection window come from the TEST.DBF file.
  26. The MACHINE.DBF file contains the description of each machine
  27. tested. References to these machines appear in the RESULTS.DBF
  28. file.
  29.  
  30. The fourth database file is the RESULTS.DBF file. This file
  31. stores the results from the various tests in a one test per
  32. record format. References to the test group, test and machine
  33. information are established via the key fields from the other
  34. three files. The Bench6 database is, therefore, relational in
  35. its structure. If the database was simply a flat file the
  36. information about machines and tests would have to be repeated
  37. in each of the result records. The result file is shortened
  38. considerably by putting this repetitive data in separate
  39. files. The drawback of this technique is that some database
  40. programs are not designed to look-up data in related files. If
  41. you are going to attempt to access the files using a database
  42. package, you should be sure it can look-up related data on
  43. secondary files and that it can process .MDX index files.
  44.  
  45. The following sections describe the layout of data records in
  46. each file and their individual fields. The last section
  47. discusses our future plans for this database. Please feel free
  48. to offer suggestions either on the Bench 6.0 registration form
  49. or through PC MagNet. Compuserve EasyPlex mail or messages on
  50. PC MagNet may be sent to Stuart R. Greenberg, ppn# 72241,64.
  51.  
  52.  
  53. THE TEST DESCRIPTION FILE (TEST.DBF)
  54.  
  55. Each of the PC Labs benchmark tests is described in the Test
  56. Description File. Bench6's user interface component uses this
  57. data to build a list of tests to choose from as well as format
  58. the test results. The key for this file is the three part Test
  59. Id.
  60.  
  61. The first part of the Test Id is a code indicating the
  62. originator of the test (MFGCODE). Future releases of the user
  63. interface may allow you to switch to another test manufacturer
  64. so each of our Test Ids start with "PCMAG " as the MFGCODE.
  65.  
  66. The second part is a code which is used to group related tests
  67. together (GROUPID). This is actually a link to the Test Group
  68. File and will be described shortly.
  69.  
  70. The final part is a sequence number (TESTNUM) that is used to
  71. make the test unique within the first two parts. For example,
  72. the 8088 Instruction Mix Test in the Processor Test Group is
  73. called "PCMAG PROCSR001" which is saying that this is the
  74. first processor test from PC Magazine Labs.
  75.  
  76. The Test Group is identified by the same key structure with
  77. the TESTNUM equal to "000". Therefore, if you know the Test Id
  78. for a particular test you can find the data related to the
  79. group in the Test Group File by looking for a record with a
  80. key for the same MFGCODE and GROUPID but with a "000" TESTNUM.
  81.  
  82. The record layout is as follows:
  83.  
  84.      FIELD NAME  TYPE  LENGTH  DESCRIPTION
  85.      ==========  ====  ======  ===============================
  86.      TEST        Char    15    Test ID (See above)
  87.      NAME        Char    30    Name of test
  88.      UNITS       Char    15    Units of measure (e.g. Ops/Sec)
  89.      DEC         Num      2    Number of decimal places in
  90.                                result. The test programs
  91.                                cannot do floating point
  92.                                calculations so all numeric
  93.                                results are given as integers
  94.                                with the number of decimal
  95.                                places entered here.
  96.      SELECT      Num      1    Used internally to indicate
  97.                                that the test can be selected.
  98.                                For example, many of the DOS
  99.                                File Access Tests cannot be
  100.                                selected individually. You have
  101.                                to select a test that includes
  102.                                lower level tests in its
  103.                                execution.
  104.      CPU         Num      1    The minimum CPU level required
  105.                                to run the test. (See CPU table
  106.                                below)
  107.      FPC         Num      1    The Floating Point Coprocessor
  108.                                level required to run the test.
  109.                                At present, 0 = none required
  110.                                and 1 = FPC required.
  111.      INDENT      Num      1    Used internally to indicate the
  112.                                level of indentation to use
  113.                                when displaying this test in a
  114.                                list. For example, the DOS File
  115.                                Access tests allow you to
  116.                                select the Large Record Tests
  117.                                and display the individual
  118.                                tests that make up that
  119.                                selection indented below it.
  120.      MODE        Num      1    The minimum video mode
  121.                                necessary to run the test. The
  122.                                currently used modes are:
  123.                                0 = Text, 1 = EGA and 2 = VGA.
  124.  
  125. The CPU codes are as follows:
  126.  
  127.      CODE        COVERS CPU TYPES
  128.      ====        ===================
  129.        0                8086
  130.        0                8088
  131.        0               NEC V30
  132.        0               NEC V20
  133.        0               80186
  134.        0               80188
  135.        6               80286
  136.        7               80386
  137.        7               80386SX
  138.        9          80486 and 80486SX
  139.  
  140. The CPU code numbers are not consecutive because the program
  141. actually uses the numbers in between to indicate the CPU type
  142. of the machine under test. The numbers here actually represent
  143. the upper limit on the range for which a particular test is
  144. valid. For example, the 386 Instruction Mix must be run
  145. on a CPU with at least a code of 7. Therefore, it will run on
  146. a 80386, 80386SX, 80486, or 80486SX.
  147.  
  148.  
  149. THE TEST GROUP FILE (TSTGROUP.DBF)
  150.  
  151. As mentioned above, the various PC Labs benchmark tests are
  152. gathered together in logical groups. Each group represents a
  153. separate .EXE file containing the test code for that group.
  154. The menu items that appear under the Performance,
  155. Compatibility and Quality categories represent the test
  156. groups. For example, the conventional, expanded and extended
  157. memory tests are all in a group called Memory Tests. The
  158. Memory Test Group appears on the menu as "Memory..." and
  159. resides in the file MEMTEST.EXE. The Test Group File contains
  160. this data for each of the test groups.
  161.  
  162. The record layout is as follows:
  163.  
  164.      FIELD NAME  TYPE  LENGTH  DESCRIPTION
  165.      ==========  ====  ======  ===============================
  166.      TEST        Char    15    Test ID with the TESTNUM part
  167.                                equal to "000"
  168.      CATEGORY    Char    10    Category to use when placing      
  169.                                the test on a menu. Currently,
  170.                                all records have a value of
  171.                                "Performanc". In the future
  172.                                this will be changed to the
  173.                                following:
  174.                                "Perform   " = Performance
  175.                                "Quality   " = Quality
  176.                                "Compat    " = Compatibility
  177.      NAME        Char    30    Long name of test
  178.      SHORTNAME   Char    30    Short name as abbreviated as
  179.                                possible
  180.      EXENAME     Char    13    Name of .EXE file containing
  181.                                the code for this test group
  182.  
  183.  
  184. THE MACHINE ID FILE
  185.  
  186.  
  187. The Machine Id File contains data on all machines that have
  188. been tested. The key field for this file is broken down into
  189. two fields. The first, MACHINE, is an eight character
  190. identification for the machine. At PC Labs we use an
  191. internally generated number for this part of the key. This
  192. number is generated for each item as it is received to enable
  193. or inventory personnel to keep track of the thousands of
  194. products that pass through PC Labs in a given year.
  195.  
  196. Special consideration had to be given to the possibility that
  197. the same machine could be tested with any or all of several
  198. options enabled or disabled. For example, a machine may be
  199. tested with its disk cache enabled and then tested again
  200. without the cache. The inventory number cannot be changed
  201. without causing confusion, so instead we added a field to the
  202. key called VARIANT. The variant is simply an arbitrarily
  203. chosen one character value. A variant of "1" for one machine
  204. does not necessarily correspond to a variant of "1" for
  205. another machine. It is simply a tag to differentiate various
  206. configurations of the same machine.
  207.  
  208. The Machine Id is used as a link between the Machine Id File
  209. and the Test Results File. One Machine Id will typically point
  210. to several results records in the Test Results File. The
  211. description of the Test Results File explains how results from
  212. multiple sessions for the same machine are stored.
  213.  
  214. There are some fields allocated to keep track of some standard
  215. information such as CPU type and speed and FPC type. While
  216. other fields may be added in the future, for now, any
  217. additional data is entered into the Description Field. It is
  218. 225 characters long and should hold enough information to
  219. identify the machine being tested.
  220.  
  221. The layout of the Machine Id File is as follows:
  222.  
  223.      FIELD NAME  TYPE  LENGTH  DESCRIPTION
  224.      ==========  ====  ======  ===============================
  225.      MACHINE     Char     8    Unique identifier for a machine
  226.      VARIANT     Char     1    Indicator to differentiate
  227.                                various configurations of a
  228.                                machine (See discussion above)
  229.      MACHNAME    Char    12    Name of machine
  230.      DESCRIPT    Char   225    Description of machine
  231.      CPU         Num      1    CPU type used in machine (See
  232.                                CPU table below)
  233.      FPC         Num      1    Floating Point Coprocessor
  234.                                type used in machine (See
  235.                                FPC table below)
  236.      CPUSPEED    Num      3    Clock speed of machine
  237.  
  238. The CPU type codes are:
  239.  
  240.      CODE             CPU TYPES
  241.      ====        ===================
  242.        0                8086
  243.        1                8088
  244.        2               NEC V30
  245.        3               NEC V20
  246.        4               80186
  247.        5               80188
  248.        6               80286
  249.        7               80386
  250.        8               80386SX
  251.        9          80486 and 80486SX
  252.  
  253. The FPC type codes are:
  254.  
  255.      CODE             FPC TYPES
  256.      ====        ===================
  257.        0                None
  258.        1                8087
  259.        2               80287
  260.        3               80387
  261.  
  262.  
  263. THE TEST RESULTS FILE
  264.  
  265. This file is the repository of the results for all tests run
  266. on a machine. The key for the Test Results File is made up of
  267. the concatenation of the Machine Id, Variant, Commit Date, and
  268. Test Id.
  269.  
  270. As described in the Machine Id File discussion above, the
  271. Variant identifies a particular configuration of a machine.
  272. The Commit Date is used in a similar manner to differentiate
  273. individual runs of a particular test. For example, let's say
  274. you test a machine on Monday and discover on Tuesday that you
  275. may have had a glitch in the hard drive. You install a new
  276. hard drive on Wednesday and retest the machine. If you
  277. committed Monday's data (Commitment of results will be
  278. explained soon.) the data from both runs will be saved and
  279. their keys will differentiate them by having different Commit
  280. Dates. The Bench6 user interface even allows you to compare
  281. results from the same machine with different Commit Dates.
  282.  
  283. So, what does it mean to commit the data? During a run,
  284. Bench6 tests are executed and the results are stored in the
  285. database. A physical write to the database is performed after
  286. each test is executed. This result record is considered to be
  287. temporary and one such record is written for each test that is
  288. run. If a test is re-run in a single session its result will
  289. be overwritten. In the event the system crashes for any reason
  290. the results logged prior to the crash should still exist as
  291. temporary records in the database.
  292.  
  293. When you feel that you have collected all the results you want
  294. you can commit the results when you exit Bench6. If any
  295. temporary results were still pending when Bench6 is started
  296. you can commit them at that time.
  297.  
  298. When results are committed the current date and time are set
  299. in the TIME field. All committed records are stamped with the
  300. same date and time and that is what allows them to be grouped
  301. by run. At this time the stamp is in a format used by Borland
  302. C++. In the future the date and time will be in separate
  303. fields and will be stored as year-month-day and hour-minute-
  304. second ASCII strings.
  305.  
  306. The result itself is always stored as a character string. We
  307. currently use numeric results for all of our tests. Future
  308. tests may have results such as "Pass" or "Fail" or contain
  309. other character based information. Any programs written to
  310. process this value should use the Test Id to look-up the Units
  311. used for the test and the Number of Decimal Places in the Test
  312. Description File to properly format a numeric result.
  313.  
  314. At this time neither the CHECK nor the COMMIT fields in this
  315. file are being used. In the future they may be enabled or
  316. deleted. Don't store any of your own data in these unused
  317. fields.
  318.  
  319. The layout of the Results File is as follows:
  320.  
  321.      FIELD NAME  TYPE  LENGTH  DESCRIPTION
  322.      ==========  ====  ======  ===============================
  323.      MACHINE     Char     8    Machine ID (See Machine Id
  324.                                File)
  325.      VARIANT     Char     1    Machine variant (See Machine Id
  326.                                File)
  327.      TIME        Num      9    Time record was committed or 0
  328.                                if record is temporary. This
  329.                                field is stored in the Borland
  330.                                C++ internal format - the
  331.                                number of seconds elapsed since
  332.                                January 1, 1970.
  333.      TEST        Char    15    Test Id (See Test Description
  334.                                File)
  335.      RESULT      Char    10    Result of test. Numeric results
  336.                                are converted to ASCII strings.
  337.      CHECK       Num      1    Not used at this time
  338.      COMMIT      Num      1    Not used at this time
  339.  
  340.  
  341. ACCESSING THE DATABASE
  342.  
  343. Experienced database programmers will find that the design of
  344. the PC Labs Benchmark Results Database is a fairly standard
  345. implementation of a relational database. As utility programs
  346. to access the database are written in-house they will be made
  347. available to the public. For now, I will give a couple of
  348. examples of how the files may be accessed to obtain certain
  349. data for reports. I leave it up to you to code the actual
  350. program.
  351.  
  352. Let's start by developing a report that lists the machine name
  353. and results for a given test. You would start by accessing the
  354. Test Description File and select the test you are interested
  355. in. Using the Test Id as a link to the Results File you would
  356. read all the records with a matching Test Id. As the records
  357. are being processed you would use the Machine Id and Variant
  358. to look-up the Machine Name and Description in the Machine Id
  359. file. Each record in the Results File would then be printed as
  360. a line on the report with the Result formatted according to
  361. the data in the Test Description File record for that test.
  362.  
  363. Another common process is to list all the tests and results
  364. for a single run on a single machine. In this case you would
  365. start in the Machine Id File and find the Machine Id and
  366. Variant you want. In a similar manner to the one above you
  367. would then read through the Results File and list out the
  368. Results for all records with matching Date and Time Stamps.
  369. The information about each test is extracted from the Test
  370. Description File by using the Test Id to establish the link
  371. between the files.
  372.  
  373. There are many other ways to access the files but they all
  374. boil down to essentially the same type of linking between the
  375. files. In some cases you may need to program an intermediate
  376. sort to get the records into the desired order but all of the
  377. data should be easily accessible from one or more of the
  378. files.
  379.  
  380.  
  381. FUTURE PLANS
  382.  
  383. Throughout this document I have been hinting at plans for the
  384. future. Once you start working with the database you will see
  385. the power waiting to be unleashed.
  386.  
  387. We are currently working on export and import programs to
  388. allow you to extract data about a machine from one set of
  389. database files and merge them into another. This capability is
  390. needed in-house to combine data collected by different
  391. reviewers on different machines. It will also allow PC MagNet
  392. to supply updates to the data we now circulate with Bench6 as
  393. files to be imported into your own database.
  394.  
  395. Also in the works is the ability to delete unused or outdated
  396. machines and their data from the database. Currently there is
  397. no way to delete a machine from the database.
  398.  
  399. Field names have caused problems for some database packages
  400. when they tried to access a Bench6 file. For example, COMMIT
  401. is often a reserved word and cannot be used in a field name.
  402. We will be changing all the field names to have a prefix in
  403. front of them to avoid this problem. A conversion program will
  404. be supplied to copy data in the existing files over to files
  405. with the new field names. This is necessary because dBase
  406. stores the filed names in the header of each database file.
  407.  
  408. New fields may be added and fields like the Date and Time
  409. Stamp (TIME) mentioned previously will be made easier to
  410. access. Again, conversion programs will be supplied as needed.
  411.  
  412.  
  413. CONCLUSION
  414.  
  415. I hope this document has helped you to understand the design
  416. and mechanics of the PC Labs Benchmark Database. Once again,
  417. if you have any questions, comments or suggestions please
  418. contact me via the Lab Notes section of the Utility Forum on
  419. PC Magnet (ppn# 72241,64) or by mail at PC Magazine Labs, One
  420. Park Avenue, New York, NY, 10016. No phone calls please.
  421.  
  422.  
  423.  
  424.  
  425. Stuart R. Greenberg,
  426. Sr. Programmer - PC Magazine Labs
  427.