Changes between Version 23 and Version 24 of DSC/zdc_framework


Ignore:
Timestamp:
Aug 13, 2013, 3:14:25 AM (11 years ago)
Author:
trappe
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • DSC/zdc_framework

    v23 v24  
    44
    55== Objective ==
    6 Use an OEDL script to execute either a competitive-style or cooperative-style game for both Wildcard and Preliminary matches. Even though the use of the framework is illustrated by using 2 house bots (or 3 in the case of a cooperative game), in the actual competition, the teams will use their own radio implementations. An additional purpose of the framework is to provide certification to the images that teams submit for the Wildcard and Preliminary matches: teams must use the script in this framework to certify their image before submission.  Certification is required for both competitive and cooperative style matches.
    7 
    8 The OEDL script uses three pair of nodes: dsc-teamA, dsc-teamB, dsc-teamC (the actual topology descriptions are '''system:topo:dsc-team{A,B,C}'''). The competitive matches will use teamA and teamC nodes, while cooperative matches will use teamA, teamB and teamC nodes (contestant radios will be only on teamA nodes for the Wildcard tournament and for image certification, while house bots will be using teamB and teamC nodes); configurations should be considered to be fixed and will be changed only in the case of hardware failures.
     6Use an OEDL script to execute either a competitive-style or cooperative-style game for both Preliminary matches of the DARPA Spectrum Challenge. Even though the use of the framework is illustrated by using 2 house bots (or 3 in the case of a cooperative game), in the actual competition, the teams will use their own radio implementations. An additional purpose of the framework is to provide validation to the images that teams submit for the Preliminary matches: teams must use the script in this framework to validate their ""image"" before submission.  Validation is required for both competitive and cooperative style matches.
     7
     8The OEDL script uses three pairs of nodes: dsc-teamA, dsc-teamB, dsc-teamC (the actual topology descriptions are '''system:topo:dsc-team{A,B,C}'''). The competitive matches will use teamA and teamC nodes, while cooperative matches will use teamA, teamB and teamC nodes (contestant radios will be only on teamA nodes for image validation, while house bots will be using teamB and teamC nodes); configurations should be considered to be fixed and will be changed only in the case of hardware failures.
    99
    1010== Hardware / Software Resources Used ==
    1111 1. Four grid nodes with USRP N210s (two for each team) for competitive match and six nodes with USRP N210s for cooperative match (two for each team).
    1212 2. ''dsc-wbot1.ndz,dsc-wbot2.ndz,dsc-wbot3.ndz'': house bot disk images with the prerequisite software to configure the USRPs and execute a house radio bot.
    13  3. ''team-image.ndz'': disk image that contains the team's radio.
     13 3. ''team-image.ndz'': disk image that contains the team's radio. Please note that it is this image file that will be validated, and that once the image has been loaded for validation, no modification to the radio designs within the image prior to completion of the validation process are allowed. 
    1414 4. Scoring packet server: This is the server that resides on the infrastructure machine and is used as the source of data packets as well as the sink for teams to submit received packets for scoring.
    1515 5. The OEDL experiment script to execute the matches.
     
    6666=== Packet Server ===
    6767The packet server application running on the infrastructure machine has
    68 * a packet source at port 5123 which serves fixed (1440 bytes). Clients can request packets from server with the following handshaking process after a TCP socket connection has been established:
     68* a packet source at port 5123 which serves fixed size packets (1440 bytes). Clients can request packets from the server with the following handshaking process after a TCP socket connection has been established:
    6969    1. client sends server the request with packet size as 4 byte word ('''ignored''' for the matches).
    7070    2. server sends client a single data packet (fixed at '''1440''' bytes)
    7171
    72     The packet source sends out the first packet to each team only after it receives packet requests from all the teams (2 teams for competitive match and 3 for co-operative) and the start signal from the experiment script. It closes transmit socket on the first packet request after the end-of-file is reached or at the 180 second timeout. It will report the score via an email to whoever has a grid reservation (if at least one packet is received correctly).
     72    The packet source sends out the first packet to each team only after it receives packet requests from all the teams (2 teams for competitive match and 3 for co-operative matches) and the start signal from the experiment script. It closes the transmit socket on the first packet request after the end-of-file is reached or at the 180 second timeout. It will report the score via an email to whoever has a grid reservation (if at least one packet is received correctly).
    7373 * a packet sink at port 5125 which receive packets from client and verifies that it matches one of the sent packets. Clients can send data to server after a connection has been established:
    7474    1. server sends client a ready packet (4 byte word).
    7575    2. client sends server data for scoring.
    7676   
    77 * a control interface used by the experiment script to prepare the packet server for a match by setting its mode, duration etc., and to send a start signal so the packet source can send packets to the teams.
     77* a control interface used by the experiment script to prepare the packet server for a match by setting its mode, duration, etc., and to send a start signal so the packet source can send packets to the teams.
    7878
    7979== Image Validation and Submission ==
    8080
    81 For the image to be considered for the tournament it must be successfully validated in both the Competitive and Cooperative modes. Successful execution of the system:exp:dsc-match script (i.e. with at least one error-free packet received by the scoring server) is considered validation of the image for that match type. Please note that the email sent by the scoring server to contestants (as well as the ORBIT team) contains all the information about images that were used for the match. '''It is essential that teams validate their final image without any modifications'''. The best way to ensure that is to simply save the final image, re-image the nodes and execute the scripts (without any further login/access to the nodes). This guarantees that the image checksum will be the same with what was reported in the validation email. You may run the validation script as often as desired and on multiple images. If the team successfully validates multiple images, the ORBIT team needs to be informed of the actual image to be used, otherwise the last successfully validated image (i.e. passing both type of matches) will be used.
     81For the image to be considered for the tournament it must be successfully validated in ''both'' the Competitive and Cooperative modes. Different images for different tournament modes will not be accepted.  Successful execution of the system:exp:dsc-match script (i.e. with at least one error-free packet received by the scoring server) is considered validation of the image for that match type. Please note that the email sent by the scoring server to contestants (as well as the ORBIT team) contains all the information about images that were used for the match. '''It is essential that teams validate their final image without any modifications'''. The best way to ensure that is to simply save the final image, re-image the nodes and execute the scripts (without any further login/access to the nodes). This guarantees that the image checksum will be the same as what gets reported in the validation email. You may run the validation script as often as desired and on multiple images. If the team successfully validates multiple images, the ORBIT team needs to be informed of the actual image to be used, otherwise the last successfully validated image (i.e. passing both types of matches) will be used.
    8282
    8383Each team is also advised that the file /.orbit_image should contain the final image name (or team name) in order to facilitate proper reporting by the framework.
     
    238238[[CollapsibleEnd]]
    239239
    240 After each run, the team will receive notification email ONLY if at least one packet was successful received by the packet server. Team image will be considered for the wildcard evaluation if it was successfully verified (i.e. notification email was received) for both competitive and cooperative matches and if image filename and MD5 checksum matches the ones in the email.
     240After each run, the team will receive a notification email ONLY if at least one packet was successful received by the packet server. The team image will be considered for the tournament evaluation if it was successfully verified (i.e. notification email was received) for ""both"" competitive and cooperative matches and if image filename and MD5 checksum matches the ones in the email.
    241241
    242242[[CollapsibleStart(Competitive match notification email)]]
     
    283283== Running Matches on Sandboxes ==
    284284
    285 In order to facilitate code development, all three sanboxes (sb2,sb3 and sb7) are haveg simplified version of the OEDL script and packet server. Please do note that, since they have only one pair of nodes, these environments are really not capable of generating interference, but are rather meant for code testing. Appropriately, the actual match script is named dsc-test and the sequence of commands to execute it is somewhat simplified and consist of:
     285In order to facilitate code development, all three sandboxes (sb2,sb3 and sb7) are available and have a simplified version of the OEDL script and packet server. Please do note that, since they have only one pair of nodes, these environments are really not capable of generating interference, but are rather meant for code testing. Further, sandboxes cannot provide validation of an image. Appropriately, the actual match script is named dsc-test and the sequence of commands to execute it is somewhat simplified and consists of:
    286286 
    287287  * Loading the image: