Changes between Initial Version and Version 1 of Ticket #29427, comment 2


Ignore:
Timestamp:
Feb 12, 2019, 8:16:45 PM (4 months ago)
Author:
dgoulet
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #29427, comment 2

    initial v1  
    1 # More intuition about the problem:
     1== More intuition about the problem:
    22
    33KIST tries not to overload the kernel when there are many sockets, and so it only runs every 10 msec. On high performance relays with lots of sockets, this is a good thing.
     
    99-----
    1010
    11 # What to do:
     11= What to do:
    1212
    13 ## Clients:
     13== Clients:
    1414
    1515KIST was designed for relays. Clients don't need to prioritize traffic the same way relays do, so they don't really need KIST. Clients can simply run the vanilla scheduler so that they read/write ASAP (rather than deferring I/O like KIST does). Or clients can run KIST with a 1 msec scheduling frequency.
    1616
    17 ## Relays:
     17== Relays:
    1818
    1919For relays, we could guess how long it would take the kernel to send out all of the notsent bytes sitting in kernel buffers plus all outbuf bytes sitting in Tor outbufs. If the time we guess is less than 10 msec, then we could run KIST sooner. This guess would probably involve knowing or estimating the NIC speed.
     
    2727Then also, KIST will never let itself write more than b bytes across all sockets, because it knows that its network card can't possibly write more than b bytes.
    2828
    29 -----
    30 
    31 # Issues:
     29== Issues:
    3230
    3331I don't know how each relay can reliably compute the value of b. Maybe we start with the "observed bandwidth" as an estimate? But then we need to allow b to grow in case the relay suddenly got faster, or for new relays?