Changes between Version 7 and Version 8 of DSC/QandA

Timestamp:

Feb 19, 2013, 9:11:18 PM (13 years ago)

Author:

seskar

Comment:

—

DSC/QandA

@@ -1 +1 @@
 = DARPA Spectrum Challenge Q&A =
 
+== H1 ==
  1. Q: '''Is it permissible to test the ssh public key mechanism prior to the reservation time?''' [[BR]]
     A: Please feel free to test the keys against gw.orbit-lab.org
  2. Q: '''Are the resource times for our schedule in EST or in our team's local time which is MST?''' [[BR]]
     A: All the resource times in the schedule email are in EST (Eastern Standard Time).
+== H2 ==
  3. Q: '''I would like to find out the procedure to access a specific domain when I have been assigned two domains which overlap in time.''' [[BR]]
     A: All omf commands accept -t flag which specifies a set of resource (nodes). That set can be specified as either list of nodes or a path to file containing a resource set. So if you have multiple virtual domains reserved, '''system:topo:all''' would refer to all nodes contained in all domains. If you just want to work with a subset of nodes, you could simply list them on a command line. For example, if you have approved reservation for zDC01 and DCGNUR01 and wanted to say image only nodes in DCGNUR01 you would issue
@@ -19 +21 @@
  5. Q: '''Given that they don't have USRP hardware, what is the purpose of zDCXX domains?''' [[BR]]
     A: The zDCXX domains are general purpose only, and can't be used for USRP testing. However, they might be useful for other functions, such as working with images, debugging, working with omf (useful tool to get familiar with), etc.
- 1. Q: '''Are we set up for full-duplex communication, i.e., can we have a return path for ACKs, etc.?''' [[BR]]
-    A: The final evaluation for Hurdle 3 will be done on a pair of nodes with the SBX front-end. Bi-directional communications is allowed as long as it is done within the 2.5 MHz channel. Teams are advised to be aware of their schedule assignment during the development period since some USRPs have the XCVR front-end. Teams are advised to fully understand the limitations of the SBX front-end when trying to implement sophisticated protocols, as well as the limitations that might be faced when developing on the XCVR for eventual testing with the SBX.
+== H3 ==
  1. Q: '''Is there some recommended image to use which combines in some way ath5k or ath9k devices and gnuradio? Can we use exisitng WiFI radios for feedback channel?''' [[BR]]
     A: Teams are not allowed to use communication interfaces other than USRP (whether wired or wireless). In other words, you can't use !WiFi/Bluetooth/ZigBee/Ethernet devices to talk between the two nodes.
  1. Q: '''Why are we getting repeated connection timeouts when running benchmark_tx2.py?''' [[BR]]
-    A: There is a hard limit on number of sessions that the packet source can handle at a time, and when you witness connection timeouts this is due to too many teams making simultaneous requests to the packet source. 
+    A: There is a hard limit on number of sessions that the packet source can handle at a time, and when you witness connection timeouts this is due to too many teams making simultaneous requests to the packet source.
+ 1. Q: '''Is it correct that the final transmitter and receiver scripts must reside in /root/gnuradio/gr-digital/examples/narrowband/''' [[BR]]
+    A: Yes you have to keep this path - it will be used by us to run your transmitter/receiver.
+ 1. Q: '''May we modify GNURadio code on the node?''' '''Can we use C++ blocks?''' '''Can we use custom code?''' '''Can we use OFDM modules?''' '''May we encapsulate packets with FEC in the transmitter and then strip the FEC in the receiver?''' [[BR]]
+    A: You may do anything with the code as long as packet source/sink communication is maintained and command line option for setting frequency is maintained. It is experimenters responsibility to test their code against the Hurdle 3 test server Teams are reminded that they are '''NOT''' allowed to change the FPGA code.
+ 1. Q: '''Are we set up for full-duplex communication, i.e., can we have a return path for ACKs, etc.?''' [[BR]]
+    A: The final evaluation for Hurdle 3 will be done on a pair of nodes with the SBX front-end. Bi-directional communications is allowed as long as it is done within the 2.5 MHz channel. Teams are advised to be aware of their schedule assignment during the development period since some USRPs have the XCVR front-end. Teams are advised to fully understand the limitations of the SBX front-end when trying to implement sophisticated protocols, as well as the limitations that might be faced when developing on the XCVR for eventual testing with the SBX.
  1. Q: '''Are there any requirements to maintain any of the existing structure of the tx/rx modules, as long as the rx timeout and packet server source/sinks remain unchanged?''' [[BR]]
     A: The requirements are that you must retain the packet structure reading from the packet source, and the packet structure going into the packet sink. Failure to do this will mean that you will not pass the checking mechanism. You must also keep the same “center frequency” argument structure on the command-line of your program since we will use this to launch your code for evaluation (and keep corresponding logging functions).  Generally, you may do whatever else you wish with the radio (without touching the FPGA or stepping outside of the 2.5MHz baseband - we will check to make certain you stay in the band). Please note that your radio module must automatically set many of its own parameters (such as gain) since the evaluators will not try to optimize parameter selection for teams. 
  1. Q: '''For Hurdle 3, timing and evaluation are handled by the server. Should the TX/RX modules continuously until the 10 minute RX timeout is reached?''' [[BR]]
-    A: Yes, you should continuously transmit packets until the timeout. We will evaluate on a 5 minute chunk of time during your run. A performance monitoring server will be running during the Qualification Period and will send you an email with number of packets that were successfully received in the 5 minute period.
-
+    A: Yes, you should continuously transmit packets until the timeout. We will evaluate on a 5 minute chunk of time during your run. A performance monitoring server will be running during the Qualification Period and will send you an email with number of packets that were successfully received in the 5 minute period. 
+ 1. Q: '''Is the packet source an "infinite" source or is the packet source a fixed-length with known maximum number of bytes?''' '''Is it permissible to refactor the packet get/put code?''' '''Does the order of received packets matter?''' [[BR]]
+    A: The packet source/sink is a TCP based packet server that generates an infinite number of random packets on request (i.e. each packet has to be requested separately by the sending application). Packet receiver is going to compare against sent packets however, packet ordering or lost packets does not matter in calculating performance. During the Qualification Period, the test server will send a report to experimenters on one of the 3 triggers: a.) 5 min. timeout is reached, b.) transmitter closed the TCP connection or c.) receiver closed the connection. Packet get/put can be changed but has to work with the existing packet server and it is experimenters responsibility to test their code against the Hurdle 3 test server (python code in the banchmark_tx3 and banchmark_rx3 is there just as a template). 
+ 1. Q: '''Can we assume that the nodes are time synchronized (e.g., using NTP)? 'If not, is it allowed to install something like NTP on the hosts?'''
+    A: Nodes are synchronized with the NTP server at boot time. However, once the testing starts the nodes can only talk to the packet server service over the Ethernet and thus NTP synchronization can't be maintained.