-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Have there been any updated ETAs concerning the development/support of multi-core for the core tor workloads? If not, is there anything in particular that I could do to speed the process up? Scaling the capabilities of the Tor process would be a huge relief and help for my upcoming project so I am keen to push it through should it be possible to bring up the priority list. t T
- -- Activist, anarchist and a bit of a dreamer. Keybase: https://keybase.io/thomaswhite
PGP Keys: https://www.thecthulhu.com/pgp-keys/ Current Fingerprint: BA81 407C BD61 CD15 E5D9 ADA9 5FA2 426F F34E 0FD4 Master Fingerprint: DDEF AB9B 1962 5D09 4264 2558 1F23 39B7 EF10 09F0
Twitter: @CthulhuSec XMPP: thecthulhu at jabber.ccc.de XMPP-OTR: 77E6C8C6 95FDE863 1172A1E1 8C114C01 691398AC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
I have to agree with that, multicore support is really important and should be on the top of the priority list.
Thomas White:
Have there been any updated ETAs concerning the development/support of multi-core for the core tor workloads? If not, is there anything in particular that I could do to speed the process up? Scaling the capabilities of the Tor process would be a huge relief and help for my upcoming project so I am keen to push it through should it be possible to bring up the priority list. t T
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Improving multi-core support can allow users to saturate high bandwidth connections with cheaper processors, less setup, and just more efficient deployment of high-capacity nodes in general. Improving multi-core support should be a major priority.
-12xBTM
On 1.6.15 9:11, Tor-Admin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
I have to agree with that, multicore support is really important and should be on the top of the priority list.
Thomas White:
Have there been any updated ETAs concerning the development/support of multi-core for the core tor workloads? If not, is there anything in particular that I could do to speed the process up? Scaling the capabilities of the Tor process would be a huge relief and help for my upcoming project so I am keen to push it through should it be possible to bring up the priority list. t T
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVbFoLAAoJEHkrhgAY5jaZsI0P/0lPBlJV+mG2qq4NJP7TSk8I GW/NRoHYOfWRPmxHhOI8jB1tIAb3ha1ftUcVsdxTu6TiyQ4WDi7e+368LixDlkZ2 ipC2M9ibj7czzD+00au+HlGm/OPBwzOZNlOjTLIZfvVK8s+KiX31cBRIJUJkJNwI g3/g0HPbujeDCGHfzE/XU3Q3eIMbFJ9CYvD077DkCGy/408TO2UqCIl/GVRk/ceH qmWJ7m0rg/vIQlKraRP5qYmgDEomrJSL383DX9jVLv7yowb9DNrTD9CegVY9tF6l MBipdy4N6JjpdMtK7WOzoI3zLwq3Ef2QHXL+zUdviBwmsWZBvycijRcyLUeoZ1Dc 0ZYVbyHQFnu1vo50a57G6UZvo1TF8h5iJGMEuEy4Kpqo68KcEC95f/H2zgIllKKA TlKVx2MZOrzf/DtLsz6TWVNw0SuczehPHJNaxSkPDNFBMqLXZlLO2TUybBnDQdpb EKlF72+zplW/2lnJ6y9wzEbWmdYHJOOzmGRD1jSgxkWWYfWbuXidGZc+88pT9G4u BXLgvAxTPmsvDT4XZXDKVUBiKdFCLs5wwAMNvmdjUUbFgPLoXSCT5xH9pujVNH1z AjyOih/NTyDuV0OzuqEMLxfDNCo+c9UrLLfj5NJjDWe6aGllwUW2W7HDgtbA4Nqq HpYewE79EAyWG6rLykim =PO2v -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Tue, 02 Jun 2015 11:13:13 -0400 12xBTM 12xbtm@gmail.com wrote:
Improving multi-core support can allow users to saturate high bandwidth connections with cheaper processors, less setup, and just more efficient deployment of high-capacity nodes in general. Improving multi-core support should be a major priority.
Sure but I doubt anyone contests that it's better to have multicore support, than to not have it. However that work doesn't get automatically done.
One quick and simple stop-gap alternative that I suggested some time ago would be to stop ignoring more than two relays per IP address.
With the IPv4 shortage and abundance of multi-core CPUs, raising that limit to let's say 4, would at least allow many people to run a Tor process per core on the same single IPv4 that they have (utilizing up to four cores, not just two).
Considering that Tor is already somewhat multi-threaded (each process can use up to "120-130%" CPU), that might be just enough in most circumstances, since true 6-8-core CPUs are rare, and what's seen more often beyond 4 cores is either Intel HT or AMD's "light" core technologies.
Of course the management (and memory) overhead of multiple processes is still there, so proper multi-core scaling is the ideal final goal.
This is a little write-up on the quality of data connections involving nodes, and some thoughts on that. So, as of today, the quality of nodes is determined by their bandwidth, uptime, and not being malicious. There are two major missing factors from this, and I wanted to bounce some ideas around: Latency and Packet Loss. These are fairly simple tests that can be performed on nodes, albeit, it would increase the resource load on the bwauths. However, nodes with high latency or packet loss should be identified, and nodes should be measured with these two important factors.
High latency will increase the delay of the circuit, but will not appear in the consesus at all. A node can have enormous latency and hamper that circuit without anyone knowing. The same could be said for a node that drops a lot of packets, or drops a lot of packets at a certain time of day (peak usage).
Mostly, latency and packet loss in nodes will negatively impact Tor's usability, but not it's security. However, bwauth testing of node latency can create a foundation of data in which we can disrupt Timing Attacks on the network. Also, as of the moment, node operators should just briefly look into these numbers for their nodes. Ensuring their nodes don't have a high latency or packet loss problem when connecting to, for example, google.com.
tor-relays@lists.torproject.org
-
12xBTM -
Roman Mamedov -
Thomas White -
Tor-Admin