1. 26 Nov, 2002 4 commits
    • Mike Hibler's avatar
      Remove hokey loss rate code · 1f897669
      Mike Hibler authored
      1f897669
    • Mike Hibler's avatar
      Commit of USENIX driven improvements: · 2ff95cee
      Mike Hibler authored
      1. Client: add "NAK avoidance."  We track our (and others, via snooping) block
         requests and avoid making re-requests unless it has been "long enough."
      
      2. Server: more aggressive merging of requests in the work queue.  For every
         new request, look for any overlap with an existing entry.
      
      3. Server: from Leigh: first cut at dynamic rate adjustment.  Can be enabled
         with -D option.
      
      4. Both: change a lot of the magic constants into runtime variables so that
         they can be adjusted on the command line or via the event interface (see
         below).
      
      5. Add code to do basic validatation of incoming packets.
      
      6. Client: randomization of block request order is now optional.
      
      7. Client: startup delay is optional and specified via a parameter N which
         says "randomly delay between 0 and N seconds before attempting to join."
      
      8. Both: add a new LEAVE message which reports back all the client stats to
         the server (which logs them).
      
      9. Both: attempt to comment some of the magic values in decls.h.
      
      10. Both: add cheezy hack to fake packet loss.  Disabled by default, see
         the GNUmakefile.  This code is coming out right after I archive it with
         this commit.
      
      11. Add tracing code.  Frisbee server/client will record a number of
         interesting events in a memory buffer and dump them at the end.  Not
         compiled in by default, see the GNUmakefile (NEVENTS) for turning this on.
      
      12. Not to be confused with the events above, also added testbed event system
         code so that frisbee clients can be remotely controlled.  This is a hack
         for measurement purposes (it requires a special rc.frisbee in the frisbee
         MFS).  Allows changing of all sorts of parameters as well as implementing
         a crude form of identification allowing you to start only a subset of
         clients.  Interface is via tevc with commands like:
      	tevc -e testbed,frisbee now frisbee start maxclients=5 readahead=5
      	tevc -e testbed,frisbee now frisbee stop exitstatus=42
         Again, this is not compiled in by default as it makes the client about
         4x bigger.  See the GNUmakefile for turning it on.
      2ff95cee
    • Mike Hibler's avatar
      Forgot this one... · e416a8cc
      Mike Hibler authored
      e416a8cc
    • Mike Hibler's avatar
      Commit of USENIX driven improvements: · dd7a05ee
      Mike Hibler authored
      1. The big one is from Leigh: multithreading the unzipper so that
         decompression overlaps with disk IO.  Also added the '-n' "no threads"
         option for comparison purposes.
      
      2. Eh...guess that's it for imagezip/unzip.  Oh wait, mike fixed a comment!
      dd7a05ee
  2. 25 Nov, 2002 2 commits
  3. 23 Nov, 2002 1 commit
  4. 22 Nov, 2002 5 commits
  5. 21 Nov, 2002 2 commits
  6. 19 Nov, 2002 6 commits
  7. 18 Nov, 2002 1 commit
  8. 17 Nov, 2002 1 commit
  9. 16 Nov, 2002 3 commits
  10. 15 Nov, 2002 3 commits
  11. 14 Nov, 2002 8 commits
    • Shashi Guruprasad's avatar
      011697a7
    • Mac Newbold's avatar
    • Leigh B. Stoller's avatar
      libdb: Add TBIPtoNodeID utility function. Also some minor jail related · bed7c3ee
      Leigh B. Stoller authored
      changes; add optinal jailflag argument to TBIsNodeVirtual, and add some
      constants for assigning port ranges to jailed nodes.
      
      newwanode: Allow reuse of existing node. So, if called with an IP that
      already exists in the DB, reuse those records (nodes, interfaces,
      reserved) rather than creating a new one. The web page makes sure that
      the calling node has a valid IP (REMOTE_ADDR equals IP it gives us),
      so it typically means an exiting node is being reinstalled (happening
      with RON nodes right now!).
      bed7c3ee
    • Mac Newbold's avatar
      Add the long-awaited check for nodes that have too many lans/links. For · 4f0c3572
      Mac Newbold authored
      now it is just hardcoded to 4, but could be done from the db too. Gives
      errors like this one, from a topo where node2 and node6 each have 5 links:
      
      *** /usr/testbed/devel/newbold/lib/ns2ir/parse.tcl:
          Too many links/LANs to node node2! Maximum is 4.
      *** /usr/testbed/devel/newbold/lib/ns2ir/parse.tcl:
          Too many links/LANs to node node6! Maximum is 4.
      *** /usr/testbed/devel/newbold/bin/batchexp:
          NS Parse failed!
      4f0c3572
    • Mac Newbold's avatar
      Finally, a check for links that want too much bandwidth. Right now it uses · 5eb5c6ed
      Mac Newbold authored
      the somewhat hacky fail-if-they-want-over-100mbps method, but could in the
      future draw the info from the database or something if it ends up being
      necessary.
      
      Setup Failure(255): Output as follows:
      
      *** /usr/testbed/devel/newbold/lib/ns2ir/parse.tcl:
          Bandwidth requested (150000) exceeds maximum of 100000 kbps!
      *** /usr/testbed/devel/newbold/lib/ns2ir/parse.tcl:
          [run] link0 has only a single node. LANs must have at least 2 nodes in them.
      *** /usr/testbed/devel/newbold/bin/batchexp:
          NS Parse failed!
      5eb5c6ed
    • Mac Newbold's avatar
      Lots of changes. · 349db7bf
      Mac Newbold authored
      First, fix up the isup generation code. When a node/OS doesn't send its
      own isups, but is pingable, we need to fork and ping it, and send ISUP
      when it pings. The code was there, but was broken. This fixes it. The one
      time that it may cause errant messages is in modes other than MINIMAL.
      When we get BOOTING, we check if it needs isup generated. If we have to
      ping it, when it pings we send ISUP. This means that if we are really in
      NORMAL mode, we might send ISUP before the node sends REBOOTED (or TBSETUP
      in NORMALv1), and it would look funny. But that case will be really rare,
      since everything that sends REBOOTED or TBSETUP has no reason not to send
      ISUP itself.
      
      Second, after mailbombing myself a couple of times, Kirk and I decided I'd
      better put some throttling in the notification code that stated uses. So
      now it throttles itself and digests the messages if they're sent too close
      together. The first message it gets will get sent immediately. If the next
      one is long enough after that, it sends it immediately too. If a message
      comes too soon after sending one, we queue it up, and send it later
      after enough time has passed. Currently it is set to wait 5 seconds
      between messages, so it will send up to 12 per second, and wait no more
      than 5 seconds before sending a message that is queued up.
      
      (Something similar to this may be a nice thing in the rest of our stuff,
      but it was made a lot easier by the fact that stated already had a polling
      loop in it. Without that, you'd have to use alarms or some other weird
      thing, which would be painful.)
      349db7bf
    • Leigh B. Stoller's avatar
      Minor changes; update the nickname when remote nodes checkin in case · a7c02305
      Leigh B. Stoller authored
      their real hostname changes.
      a7c02305
    • Leigh B. Stoller's avatar
      Change ntpinfo as per Dave's request. · 48629e9c
      Leigh B. Stoller authored
      48629e9c
  12. 13 Nov, 2002 2 commits
  13. 12 Nov, 2002 2 commits