Replies: 1 comment
-
I've generally kept Tor patches in my own fork of Tor at robgjansen/tor. This change does seem a bit more specific to Shadow and less general than most of my research-based patches though. I wonder if it might make sense to merge this directly into Tor? Presumably your patch would improve performance during regular Tor operation, but maybe less safely than they prefer? Would it make sense to propose it as a feature that it is only enabled when the |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
While continuing to poke around the performance of some Tor experiments, I noticed that the rounds were often getting bottlenecked on some Tor symbols. Turns out, they were symbols for some constant-time string operations. Since Shadow simulations have "infinite" computational speed, these shouldn't affect behavior versus their libc counterparts, but do seem to make a measurable difference for the simulation performance. I tried stubbing them out, and my (non-scientific) comparison showed about a 20% overall runtime improvement. This could be because of my particular configuration, but it at least makes some sense that these would be strict overhead, especially if it's in one heavy tor process blocking everything else. I know the openssl stubbing was dropped because it didn't matter much (and yeah, I didn't see any openssl symbols high in my measurements), so I'm not really sure the best place to put this now. It probably isn't necessary for most experiments, but it could be useful for some. Inline it in the docs on running Tor experiments? Put it as a patch file in tornettools somewhere?
Patch for reference:
Beta Was this translation helpful? Give feedback.
All reactions