1. 06 Feb, 2003 7 commits
  2. 05 Feb, 2003 8 commits
  3. 04 Feb, 2003 1 commit
  4. 03 Feb, 2003 7 commits
  5. 02 Feb, 2003 1 commit
  6. 01 Feb, 2003 1 commit
  7. 31 Jan, 2003 12 commits
  8. 30 Jan, 2003 3 commits
    • Mike Hibler's avatar
      Make sure -n truly makes it impotent. As it was, it would not add routes · 667ffd4c
      Mike Hibler authored
      to the virt_routes table, but it would delete them!
      667ffd4c
    • Shashi Guruprasad's avatar
      Fixed an error made by ISI during last year's rewriting of the RTSched code · cbe7fc8b
      Shashi Guruprasad authored
      that although appeared to be right was actually causing errors to be
      accumalated. This fixes the high error rates in the bandwidth and loss rate
      numbers reported in OSDI. There are also code optimizations after profiling
      it that reduces the RTSched overhead.
      
      Another source of error was send/consume/request/reply which used to be
      given a very rough estimate of the CPU speed (600 instead of 601.37 Mhz for
      example). The latter comes from the boot up calibration in FreeBSD which
      is supposed to be accurate up to 10 microsecs on a 486.  Using
      600 instead of 601.37 causes an error of 0.22 % in the measurement. That is
      about 1.3 ms for an RTT of 600 ms. This error is worse when send/consume
      are used to calculate throughputs. The longer the period of measurement,
      the worse it becomes.  I have committed changes in them as well. Defining
      the macro CPU_SPEED_IN_KHZ will get you kernels that take CPU_SPEED
      parameters in Khz instead of Mhz. So, you can specify 851940 instead of
      850 for a pc850.
      
      boss:/tftpboot/x86/{send,consume,request,reply}.cpuinkhz lets you specify
      CPU_SPEED in Khz
      cbe7fc8b
    • Robert Ricci's avatar
      Add an index for nodes.phys_nodeid, since there are some queries and · 08d544d2
      Robert Ricci authored
      updates that use it.
      08d544d2