On 3/20/16, Mike Perry <mikepe...@torproject.org> 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. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
