On 3/20/16, Mike Perry <mikeperry@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.