On 3/20/16, Mike Perry <[email protected]> wrote: > It could also be due to the fact that Tor is effectively > single-threaded. If something on the user's guard node, intermediate > node, or hidden service is taking large amounts of CPU time, this will > prevent traffic from flowing while that operation is happening. See: > https://trac.torproject.org/projects/tor/ticket/16585 (though that > ticket could use some help with clarity).
Related... why a traffic fill solution may need to reclock and transmit new own random jitter and self limit to processable / expected bandwidth contracts to mask network induced computation and provide for CPU headroom therein. As with [John Gilmore's?] IEEE fill layer suggestion, there should be a group establish outside just Tor calling for participants to look at various crypted network fill models against now known / surmised G[P]A methods.
