doc/dynamic_sockets.txt

   1 Dynamic Active/Passive sockets for etorrent.
   2
   3 ***
   4
   5 Introduction:
   6
   7 When I originally built the socket system for etorrent I opted for the
   8 simple solution. This was to use active sockets and use the socket
   9 option {packet, 4} on the wire-protocol. This is extremely fast an
  10 simple, yet it gave rather bad speeds. The reason for this is that we
  11 need to do rate calculations to choose the fastest peers and when a
  12 peer sends 16k packets he may not even get a rate calculation in the
  13 interval of 10 seconds due to this.
  14
  15 So I opted for using passive sockets and queue the data myself. This
  16 gives many more rate calculations but it also uses a lot of CPU-time.
  17
  18 The next thing that was the rate calculation itself. It used a simple
  19 scheme where we counted bytes for 10 seconds and then resat all
  20 counters. This is very unfair to some peers that enters late in the
  21 cycle (ie, gets unchoked late in the 10 second cycle) even if they
  22 produce really good speeds. So we now use a running average over an
  23 interval which periodically gets updated. This is much more fair since
  24 a peer which has only moved data for 3 seconds but has a good rate
  25 will get unchoked.
  26
  27 But the problem with passive sockets remain in the code, even with
  28 this change.
  29
  30 Goal:
  31
  32 Minimize CPU usage.
  33
  34 Methodology:
  35
  36 It is clear that if a socket has a rate beyond a certain limit, we
  37 should just use [active, {packet, 4}] encoding on the socket. For
  38 slower sockets, you will have to do some measurements and
  39 thinking. Maybe [active, {packet, 4}] is best. Or you can use [active]
  40 only or maybe keep running with the passive socket. It depends on how
  41 much it hurts the rate calculation on slower lines.
  42
  43 The idea is to dynamically shift between 2 modes, should it prove to
  44 be most efficient. When the speed jumps over a hi-mark then it goes
  45 [active, {packet, 4}] and when the speed falls below a certain lo-mark
  46 it changes to a more precise measurement that may eat more CPU-power.
  47
  48 It is probably best if you measure what is best. You can also profile
  49 the rating code (think Amdahls law) and see if an improvement of that
  50 will yield significant speedup.