Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of pa011 Sent: Tuesday, December 06, 2016 1:24 AM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
I would like to hear about ONE Raspi Tor operator who was allowed by DirAuths (or bwauths or whatever) to come even near 1 mbit/s bandwidth utilization
let me tell: https://atlas.torproject.org/#details/AA44C4BE3C90DCAAC09E5CD26150710AAA80D5... https://atlas.torproject.org/#details/CA9A5D5C4688F04EEC1AF810B0FD348109FA17... are sharing the same dynamic IP on a Rasp2 -cut every 24 hours day rx | tx | total | avg. rate ------------------------+-------------+-------------+--------------- 05.12.2016 27,20 GiB | 28,39 GiB | 55,59 GiB | 5,40 Mbit/s that is slight above 1 Mbit/s :-) Best regards Paul ---------------------------- Wow nice bandwidth you are pushing through Paul! You mean two Raspi 2's sharing an Internet connection, each relaying 27 Gbytes per day at 5.4 Mbit/s on the average?? Total 10.8 Mbit/s?? Or 2.7 Mbit/s each? Definitely refutes the previously claimed 1 Mbit/s Tor limit on Raspi, and means that Raspi has nothing to do with the ridiculously low utilization of my relay, just as I thought. As a matter of fact this means that whoever is NOT running a relay on a Raspi (or two, or four of them) is wasting money, unless he has a computer lying about with nothing better to do. Also, what's the max memory and CPU utilization on your Raspi (I have read somewhere that Tor is only capable of utilizing 2 of the 4 CPU cores), and what kind of Internet connection do you have? BTW the $35 Raspi 3 has 33% more CPU power than your Raspi 2 and the same amount of memory. Rana
Again, bits or bytes. I can't believe I'm repeating myself, don't you people read? The ORIGINAL (version 1) Raspberry Pi had a max of 1 MegaBYTE. 1 MegaBYTE = 8 megaBITS Obviously other factors limit performance, but looking at just the maximum network capacity of a Raspberry Pi 1, it could handle 8Mbit/s. On Dec 6, 2016 11:16 AM, "Rana" <ranaventures@gmail.com> wrote: -----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of pa011 Sent: Tuesday, December 06, 2016 1:24 AM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
I would like to hear about ONE Raspi Tor operator who was allowed by DirAuths (or bwauths or whatever) to come even near 1 mbit/s bandwidth utilization
let me tell: https://atlas.torproject.org/#details/AA44C4BE3C90DCAAC09E5CD2615071 0AAA80D58B https://atlas.torproject.org/#details/CA9A5D5C4688F04EEC1AF810B0FD34 8109FA17FB are sharing the same dynamic IP on a Rasp2 -cut every 24 hours day rx | tx | total | avg. rate ------------------------+-------------+-------------+--------------- 05.12.2016 27,20 GiB | 28,39 GiB | 55,59 GiB | 5,40 Mbit/s that is slight above 1 Mbit/s :-) Best regards Paul ---------------------------- Wow nice bandwidth you are pushing through Paul! You mean two Raspi 2's sharing an Internet connection, each relaying 27 Gbytes per day at 5.4 Mbit/s on the average?? Total 10.8 Mbit/s?? Or 2.7 Mbit/s each? Definitely refutes the previously claimed 1 Mbit/s Tor limit on Raspi, and means that Raspi has nothing to do with the ridiculously low utilization of my relay, just as I thought. As a matter of fact this means that whoever is NOT running a relay on a Raspi (or two, or four of them) is wasting money, unless he has a computer lying about with nothing better to do. Also, what's the max memory and CPU utilization on your Raspi (I have read somewhere that Tor is only capable of utilizing 2 of the 4 CPU cores), and what kind of Internet connection do you have? BTW the $35 Raspi 3 has 33% more CPU power than your Raspi 2 and the same amount of memory. Rana _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Well, I can read and also now the translation from Bits to Bytes. But I am not sure about your value of the maximum network capacity. That's the iperf3 measurement of a Raspberry Pi 1 Model B+: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 83.6 MBytes 8.36 MBytes/sec 141 sender [ 4] 0.00-10.00 sec 83.1 MBytes 8.31 MBytes/sec receiver Also arm shows me an average of 9 MB/s. Maybe they have change the USB LAN chip? Regards, On 06.12.2016 19:20, Tristan wrote:
Again, bits or bytes. I can't believe I'm repeating myself, don't you people read?
The ORIGINAL (version 1) Raspberry Pi had a max of 1 MegaBYTE.
1 MegaBYTE = 8 megaBITS
Obviously other factors limit performance, but looking at just the maximum network capacity of a Raspberry Pi 1, it could handle 8Mbit/s.
On Dec 6, 2016 11:16 AM, "Rana" <ranaventures@gmail.com <mailto:ranaventures@gmail.com>> wrote:
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org <mailto:tor-relays-bounces@lists.torproject.org>] On Behalf Of pa011 Sent: Tuesday, December 06, 2016 1:24 AM To: tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
> I would like to hear about ONE Raspi Tor operator who was allowed by DirAuths (or bwauths or whatever) to come even near 1 mbit/s bandwidth utilization >
let me tell: https://atlas.torproject.org/#details/AA44C4BE3C90DCAAC09E5CD26150710AAA80D5... <https://atlas.torproject.org/#details/AA44C4BE3C90DCAAC09E5CD26150710AAA80D58B> https://atlas.torproject.org/#details/CA9A5D5C4688F04EEC1AF810B0FD348109FA17... <https://atlas.torproject.org/#details/CA9A5D5C4688F04EEC1AF810B0FD348109FA17FB>
are sharing the same dynamic IP on a Rasp2 -cut every 24 hours
day rx | tx | total | avg. rate
------------------------+-------------+-------------+--------------- 05.12.2016 27,20 GiB | 28,39 GiB | 55,59 GiB | 5,40 Mbit/s
that is slight above 1 Mbit/s :-)
Best regards
Paul ----------------------------
Wow nice bandwidth you are pushing through Paul! You mean two Raspi 2's sharing an Internet connection, each relaying 27 Gbytes per day at 5.4 Mbit/s on the average?? Total 10.8 Mbit/s?? Or 2.7 Mbit/s each?
Definitely refutes the previously claimed 1 Mbit/s Tor limit on Raspi, and means that Raspi has nothing to do with the ridiculously low utilization of my relay, just as I thought. As a matter of fact this means that whoever is NOT running a relay on a Raspi (or two, or four of them) is wasting money, unless he has a computer lying about with nothing better to do.
Also, what's the max memory and CPU utilization on your Raspi (I have read somewhere that Tor is only capable of utilizing 2 of the 4 CPU cores), and what kind of Internet connection do you have?
BTW the $35 Raspi 3 has 33% more CPU power than your Raspi 2 and the same amount of memory.
Rana
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays>
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I don't know the actual numbers for the Raspberry Pi 1, I was just quoting from Duncan: https://lists.torproject.org/pipermail/tor-relays/2016-December/011182.html On 12/06/2016 03:00 PM, diffusae wrote:
Well, I can read and also now the translation from Bits to Bytes. But I am not sure about your value of the maximum network capacity.
That's the iperf3 measurement of a Raspberry Pi 1 Model B+:
[ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 83.6 MBytes 8.36 MBytes/sec 141 sender [ 4] 0.00-10.00 sec 83.1 MBytes 8.31 MBytes/sec receiver
Also arm shows me an average of 9 MB/s.
Maybe they have change the USB LAN chip?
Regards,
On 06.12.2016 19:20, Tristan wrote:
Again, bits or bytes. I can't believe I'm repeating myself, don't you people read?
The ORIGINAL (version 1) Raspberry Pi had a max of 1 MegaBYTE.
1 MegaBYTE = 8 megaBITS
Obviously other factors limit performance, but looking at just the maximum network capacity of a Raspberry Pi 1, it could handle 8Mbit/s.
On Dec 6, 2016 11:16 AM, "Rana" <ranaventures@gmail.com <mailto:ranaventures@gmail.com>> wrote:
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org <mailto:tor-relays-bounces@lists.torproject.org>] On Behalf Of pa011 Sent: Tuesday, December 06, 2016 1:24 AM To: tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
> I would like to hear about ONE Raspi Tor operator who was allowed by DirAuths (or bwauths or whatever) to come even near 1 mbit/s bandwidth utilization >
let me tell: https://atlas.torproject.org/#details/AA44C4BE3C90DCAAC09E5CD26150710AAA80D5... <https://atlas.torproject.org/#details/AA44C4BE3C90DCAAC09E5CD26150710AAA80D58B> https://atlas.torproject.org/#details/CA9A5D5C4688F04EEC1AF810B0FD348109FA17... <https://atlas.torproject.org/#details/CA9A5D5C4688F04EEC1AF810B0FD348109FA17FB>
are sharing the same dynamic IP on a Rasp2 -cut every 24 hours
day rx | tx | total | avg. rate
------------------------+-------------+-------------+--------------- 05.12.2016 27,20 GiB | 28,39 GiB | 55,59 GiB | 5,40 Mbit/s
that is slight above 1 Mbit/s :-)
Best regards
Paul ----------------------------
Wow nice bandwidth you are pushing through Paul! You mean two Raspi 2's sharing an Internet connection, each relaying 27 Gbytes per day at 5.4 Mbit/s on the average?? Total 10.8 Mbit/s?? Or 2.7 Mbit/s each?
Definitely refutes the previously claimed 1 Mbit/s Tor limit on Raspi, and means that Raspi has nothing to do with the ridiculously low utilization of my relay, just as I thought. As a matter of fact this means that whoever is NOT running a relay on a Raspi (or two, or four of them) is wasting money, unless he has a computer lying about with nothing better to do.
Also, what's the max memory and CPU utilization on your Raspi (I have read somewhere that Tor is only capable of utilizing 2 of the 4 CPU cores), and what kind of Internet connection do you have?
BTW the $35 Raspi 3 has 33% more CPU power than your Raspi 2 and the same amount of memory.
Rana
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays>
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Ahh, ok. It looks like, that should be a bit more that 1 MB/s. Regards, On 06.12.2016 22:10, SuperSluether wrote:
I don't know the actual numbers for the Raspberry Pi 1, I was just quoting from Duncan: https://lists.torproject.org/pipermail/tor-relays/2016-December/011182.html
On 12/06/2016 03:00 PM, diffusae wrote:
Well, I can read and also now the translation from Bits to Bytes. But I am not sure about your value of the maximum network capacity.
That's the iperf3 measurement of a Raspberry Pi 1 Model B+:
[ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 83.6 MBytes 8.36 MBytes/sec 141 sender [ 4] 0.00-10.00 sec 83.1 MBytes 8.31 MBytes/sec receiver
Also arm shows me an average of 9 MB/s.
Maybe they have change the USB LAN chip?
Regards,
On 06.12.2016 19:20, Tristan wrote:
Again, bits or bytes. I can't believe I'm repeating myself, don't you people read?
The ORIGINAL (version 1) Raspberry Pi had a max of 1 MegaBYTE.
1 MegaBYTE = 8 megaBITS
Obviously other factors limit performance, but looking at just the maximum network capacity of a Raspberry Pi 1, it could handle 8Mbit/s.
On Dec 6, 2016 11:16 AM, "Rana" <ranaventures@gmail.com <mailto:ranaventures@gmail.com>> wrote:
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org <mailto:tor-relays-bounces@lists.torproject.org>] On Behalf Of pa011 Sent: Tuesday, December 06, 2016 1:24 AM To: tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
> I would like to hear about ONE Raspi Tor operator who was allowed by DirAuths (or bwauths or whatever) to come even near 1 mbit/s bandwidth utilization >
let me tell:
https://atlas.torproject.org/#details/AA44C4BE3C90DCAAC09E5CD26150710AAA80D5...
<https://atlas.torproject.org/#details/AA44C4BE3C90DCAAC09E5CD26150710AAA80D58B>
https://atlas.torproject.org/#details/CA9A5D5C4688F04EEC1AF810B0FD348109FA17...
<https://atlas.torproject.org/#details/CA9A5D5C4688F04EEC1AF810B0FD348109FA17FB>
are sharing the same dynamic IP on a Rasp2 -cut every 24 hours
day rx | tx | total | avg. rate
------------------------+-------------+-------------+--------------- 05.12.2016 27,20 GiB | 28,39 GiB | 55,59 GiB | 5,40 Mbit/s
that is slight above 1 Mbit/s :-)
Best regards
Paul ----------------------------
Wow nice bandwidth you are pushing through Paul! You mean two Raspi 2's sharing an Internet connection, each relaying 27 Gbytes per day at 5.4 Mbit/s on the average?? Total 10.8 Mbit/s?? Or 2.7 Mbit/s each?
Definitely refutes the previously claimed 1 Mbit/s Tor limit on Raspi, and means that Raspi has nothing to do with the ridiculously low utilization of my relay, just as I thought. As a matter of fact this means that whoever is NOT running a relay on a Raspi (or two, or four of them) is wasting money, unless he has a computer lying about with nothing better to do.
Also, what's the max memory and CPU utilization on your Raspi (I have read somewhere that Tor is only capable of utilizing 2 of the 4 CPU cores), and what kind of Internet connection do you have?
BTW the $35 Raspi 3 has 33% more CPU power than your Raspi 2 and the same amount of memory.
Rana
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays>
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 06/12/16 21:10, SuperSluether wrote:
I don't know the actual numbers for the Raspberry Pi 1, I was just quoting from Duncan: https://lists.torproject.org/pipermail/tor-relays/2016-December/011182.html
I was told this figure by a friend who tried networking "stuff" on a Pi.
From personal experience also, I have found they are just a bit rubbish, other than for using a probe for OONI, and for a short time using it to try out NetBSD and various other operating systems.
My original figure may have been... somewhat off. With different models they may have updated the network hardware. Certainly on the new ones they are better, but there are deeper flaws with the Raspberry Pi's hardware, e.g. the omnipotent GPU blob and various other proprietary parts that make supporting it non-trivial compared to say, the BeagleBone Black. A more general point is that old desktop computers still offer better performance than a Raspberry Pi. You can easily get one for considerably less than the cost of a Pi, and there are also issues of network diversity with the Raspberry Pi - if some flaw was exploited in the various nasty proprietary bits that make up the Pi, much of the network might be compromised - due to large similarities across the different models, this would affect considerable numbers of devices. So using many different computer models with a large variety of operating systems is ideal for the network as a whole. Duncan
On Wed, 7 Dec 2016 00:36:15 +0000 Duncan Guthrie <dguthrie@posteo.net> wrote:
My original figure may have been... somewhat off. With different models they may have updated the network hardware.
They did not. All models with Ethernet use the same SMSC LAN9514 chip.
A more general point is that old desktop computers still offer better performance than a Raspberry Pi. You can easily get one for considerably less than the cost of a Pi
And pay more than the cost of a Pi in electricity. -- With respect, Roman
I can just imagine someone panting while dragging a sub-$35 old desktop computer up the stairs after physically searching for it in a nearby junkyard. A considerable level of destitution and a commendable commitment to the cause of Tor would be required. -----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Roman Mamedov Sent: Wednesday, December 07, 2016 7:08 AM To: Duncan Guthrie Cc: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP On Wed, 7 Dec 2016 00:36:15 +0000 Duncan Guthrie <dguthrie@posteo.net> wrote:
My original figure may have been... somewhat off. With different models they may have updated the network hardware.
They did not. All models with Ethernet use the same SMSC LAN9514 chip.
A more general point is that old desktop computers still offer better performance than a Raspberry Pi. You can easily get one for considerably less than the cost of a Pi
And pay more than the cost of a Pi in electricity. -- With respect, Roman _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 07/12/16 05:32, Rana wrote:
I can just imagine someone panting while dragging a sub-$35 old desktop computer up the stairs after physically searching for it in a nearby junkyard. A considerable level of destitution and a commendable commitment to the cause of Tor would be required. This is hardly the case. Computers are so widespread that an old desktop system with even twice the power of the Pi can be had for buttons. There is no need to be rude about the suggestions that people on this list make.
Duncan
Calling "rude" people who, to make a point, use a bit of obvious and harmless humor, is rude. -----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Duncan Guthrie Sent: Wednesday, December 07, 2016 11:41 AM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP On 07/12/16 05:32, Rana wrote:
I can just imagine someone panting while dragging a sub-$35 old desktop computer up the stairs after physically searching for it in a nearby junkyard. A considerable level of destitution and a commendable commitment to the cause of Tor would be required. This is hardly the case. Computers are so widespread that an old desktop system with even twice the power of the Pi can be had for buttons. There is no need to be rude about the suggestions that people on this list make.
Duncan _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 07.12.2016 10:56, Rana wrote:
Calling "rude" people who, to make a point, use a bit of obvious and harmless humor, is rude.
Your getting on other people's nerves must *obviously* be the fault of other people. Welcome to Trump World. :-) -Ralph
There's an alternative interpretation but mentioning in reply to your message would be... rude :-) -----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Ralph Seichter Sent: Wednesday, December 07, 2016 12:59 PM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP On 07.12.2016 10:56, Rana wrote:
Calling "rude" people who, to make a point, use a bit of obvious and harmless humor, is rude.
Your getting on other people's nerves must *obviously* be the fault of other people. Welcome to Trump World. :-) -Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
:-) Does anyone needs a P4 with 300 Watts power supply. In idle mode it's only 100 ... On 07.12.2016 06:32, Rana wrote:
I can just imagine someone panting while dragging a sub-$35 old desktop computer up the stairs after physically searching for it in a nearby junkyard. A considerable level of destitution and a commendable commitment to the cause of Tor would be required.
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Roman Mamedov Sent: Wednesday, December 07, 2016 7:08 AM To: Duncan Guthrie Cc: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
On Wed, 7 Dec 2016 00:36:15 +0000 Duncan Guthrie <dguthrie@posteo.net> wrote:
My original figure may have been... somewhat off. With different models they may have updated the network hardware.
They did not. All models with Ethernet use the same SMSC LAN9514 chip.
A more general point is that old desktop computers still offer better performance than a Raspberry Pi. You can easily get one for considerably less than the cost of a Pi
And pay more than the cost of a Pi in electricity.
-- With respect, Roman _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 07.12.2016 01:36, Duncan Guthrie wrote:
if some flaw was exploited in the various nasty proprietary bits that make up the Pi, much of the network might be compromised - due to large similarities across the different models, this would affect considerable numbers of devices. So using many different computer models with a large variety of operating systems is ideal for the network as a whole.
Yes, there proprietary parts in the firmware, but also this firmware is free and open source. And there are a lot of people who keep care on it. It's especially very easy to rewrite the boot partition. Regards,
Subject seems to have changed a bit, so not hijacking it. When thinking of any exploitation of firmware - should there be concerns of Intel's Management Engine in the CPU of any relays running on "home hardware" in any common unused pc or laptop? Should that be a concern on ANY newer Intel hardware? Gumby On 12/07/2016 02:35 PM, diffusae wrote:
On 07.12.2016 01:36, Duncan Guthrie wrote:
if some flaw was exploited in the various nasty proprietary bits that make up the Pi, much of the network might be compromised - due to large similarities across the different models, this would affect considerable numbers of devices. So using many different computer models with a large variety of operating systems is ideal for the network as a whole.
Yes, there proprietary parts in the firmware, but also this firmware is free and open source. And there are a lot of people who keep care on it.
It's especially very easy to rewrite the boot partition.
Regards, _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hmm, interesting subject ... On 07.12.2016 21:35, Gumby wrote:
Subject seems to have changed a bit, so not hijacking it. When thinking of any exploitation of firmware - should there be concerns of Intel's Management Engine in the CPU of any relays running on "home hardware" in any common unused pc or laptop? Should that be a concern on ANY newer Intel hardware?
Gumby
What do you think about Intel AMT, it's a part of the most modern PCs?
On 12/07/2016 02:35 PM, diffusae wrote:
On 07.12.2016 01:36, Duncan Guthrie wrote:
if some flaw was exploited in the various nasty proprietary bits that make up the Pi, much of the network might be compromised - due to large similarities across the different models, this would affect considerable numbers of devices. So using many different computer models with a large variety of operating systems is ideal for the network as a whole.
Yes, there proprietary parts in the firmware, but also this firmware is free and open source. And there are a lot of people who keep care on it.
It's especially very easy to rewrite the boot partition.
Regards, _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 07/12/16 21:45, diffusae wrote:
Hmm, interesting subject ...
On 07.12.2016 21:35, Gumby wrote:
Subject seems to have changed a bit, so not hijacking it. When thinking of any exploitation of firmware - should there be concerns of Intel's Management Engine in the CPU of any relays running on "home hardware" in any common unused pc or laptop? Should that be a concern on ANY newer Intel hardware?
Gumby What do you think about Intel AMT, it's a part of the most modern PCs?
Intel ME/AMT concerns me too, especially how unavoidable it seems to be on modern CPUs (AMD is no escape, as they have an equivalent in the form of their "Platform Security Processor"). Though I this probably concerns me less than the fact that only the fastest relays are going to be deployed on colocated and fully owner-controlled hardware or under their own ASNs. The rest are probably going to be VPS nodes or at least connected to some out-of-band network management interface for quick deployment and monitoring at the ISP-level. This can provide low-level access in a similar way to ME/AMT. I've seen many providers allowing access to management TTYs, or even raw disk management tools via HTTP web interfaces. Abusing the ME/AMT would require some sort of co-operation on Intel's part, or stolen signing keys, but imagine if you could get access to some sort of administration panel for OVH/DigitalOcean etc. Co-opting a large number of relays/exits through that process might be a lot easier, so if I was going to worry about out-of-band management interfaces, I'd probably worry about those first.
On 07.12.2016 23:50, Alex Haydock wrote:
On 07/12/16 21:45, diffusae wrote:
Hmm, interesting subject ...
On 07.12.2016 21:35, Gumby wrote:
Subject seems to have changed a bit, so not hijacking it. When thinking of any exploitation of firmware - should there be concerns of Intel's Management Engine in the CPU of any relays running on "home hardware" in any common unused pc or laptop? Should that be a concern on ANY newer Intel hardware?
Gumby What do you think about Intel AMT, it's a part of the most modern PCs?
Intel ME/AMT concerns me too, especially how unavoidable it seems to be on modern CPUs (AMD is no escape, as they have an equivalent in the form of their "Platform Security Processor").
Though I this probably concerns me less than the fact that only the fastest relays are going to be deployed on colocated and fully owner-controlled hardware or under their own ASNs.
The rest are probably going to be VPS nodes or at least connected to some out-of-band network management interface for quick deployment and monitoring at the ISP-level. This can provide low-level access in a similar way to ME/AMT. I've seen many providers allowing access to management TTYs, or even raw disk management tools via HTTP web interfaces.
Abusing the ME/AMT would require some sort of co-operation on Intel's part, or stolen signing keys, but imagine if you could get access to some sort of administration panel for OVH/DigitalOcean etc. Co-opting a large number of relays/exits through that process might be a lot easier, so if I was going to worry about out-of-band management interfaces, I'd probably worry about those first.
I am totally agree with you. One alternative would be to use coreboot on your machine. If you are good, than you will put your kernel into the flash chip and make it write protected.
On 07/12/16 23:15, diffusae wrote
I am totally agree with you.
One alternative would be to use coreboot on your machine. If you are good, than you will put your kernel into the flash chip and make it write protected. As far as I know, Coreboot is merely an open source BIOS replacement and doesn't act to disable the management engine as many Intel chips simply won't boot without the ME firmware present and correct.
Libreboot might be the project you're thinking of, but it only works on the small subset of (sadly usually quite old) CPUs that will actually boot without Intel's firmware being present. They are both fantastic projects, and I do have some Libreboot machines at home, but the main concern I was raising was that: firstly, unless you are colocating your own hardware or running your relay at home, flashing a new BIOS to your relay's hardware is out of the question as the hardware is under the control of your service provider. The other thing I was noting was that the fact the hardware is under control of your service provider is probably more of a threat than just the ME would be. The service provider obviously needs access to the machine, but they often expose quite low-level access either through web consoles of unknown security, or to helpdesk techs working at the provider. As a side note, there is one VPS provider I know of that are currently in the preparation stages before launch, and who are intending to run their entire infrastructure on Libreboot machines: https://www.vikings.net/index.html
As long as CPU hardware is closed source, perfect privacy does not exist, full stop. Conspiracy theories are futile, the probability of microcode backdoor is 1. So there is no need to "worry" about hardware blobs. There is NO way that processors made by US chip manufacturers do NOT contain a backdoor. The same goes for Raspberry Pi which is based on a Broadcom chip. Privacy is a therefore probabilistic entity. Instead of worrying about hardware blobs, you should is try to estimate the cost of intrusion, collection and analysis, divided by the probability of yourself being a target. This yields a weighted cost of spying on you. If the result is high enough, no problem, as the adversary's budget s always limited. Otherwise you are toast, Tor or no Tor, VM or no VM. What Tor hopefully does is raise the cost and thus minimize the probability of the Tor user being targeted, collected and analyzed, due to purely budgetary reasons. I am happily using hardware based on Intel chips. If I were an ISIS ringleader, I wouldn't. Allahu Akbar but my ass is valuable, too.
Op 07-12-16 om 23:50 schreef Alex Haydock:
AMD is no escape, as they have an equivalent in the form of their "Platform Security Processor"
I believe[1] the Athlon 5370 that AMD released this year is without PSP. Suits small form factors and has good performance for the mere 25 Watt that it uses. [1] https://notabug.org/vimuser/libreboot-website/issues/10
On Wed, 7 Dec 2016 22:50:39 +0000 Alex Haydock <alex@alexhaydock.co.uk> wrote:
Intel ME/AMT concerns me too, especially how unavoidable it seems to be on modern CPUs (AMD is no escape, as they have an equivalent in the form of their "Platform Security Processor").
On AMD that's been implemented only after "Family 15h" https://libreboot.org/faq/#amdbastards https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures Family 15h itself is safe. It includes FX-series 8-core CPUs at up to 5 GHz supporting DDR3-2133 RAM: https://en.wikipedia.org/wiki/Piledriver_%28microarchitecture%29 So don't handwave-away AMD with "they are doing that too", today you CAN have a non-backdoored modern high-performance CPU -- from AMD. -- With respect, Roman
On Thu, Dec 08, 2016 at 10:41:46AM +0500, Roman Mamedov wrote:
On AMD that's been implemented only after "Family 15h" https://libreboot.org/faq/#amdbastards https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures
Family 15h itself is safe.
It includes FX-series 8-core CPUs at up to 5 GHz supporting DDR3-2133 RAM: https://en.wikipedia.org/wiki/Piledriver_%28microarchitecture%29
So don't handwave-away AMD with "they are doing that too", today you CAN have a non-backdoored modern high-performance CPU -- from AMD.
Interesting, but this microarchitecture entered the market in 2012 and is probably being phased out now, I guess? As far as modular, open hardware is concerned, I set my hopes on the new EOMA68 architecture. This is a draft standard for computer cards in the PCMCIA form factor: http://elinux.org/Embedded_Open_Modular_Architecture/EOMA68 Crowdfunding for the first implementation of this specification (EOMA68-A20) has been successful: https://www.crowdsupply.com/eoma68/micro-desktop I ordered one, and I convinced Digitalcourage e.V. to order three more that will be used for trustworthy computing – maybe Tor relays. The performance of this first implementation will probably be comparable to the CubieTruck which is based on the same SoC, the Allwinner A20, which is an ARM Cortex-A8 design. So CPU-wise, it will be between the Raspberry Pi 2 and 3. Network throughput might be better because it does not use Raspi's peculiar design. New implementations with more powerful hardware are in preparation (see the latest updates on CrowdSupply), but we are still talking about smartphone-like systems. Last time I checked, Tor did not support the hardware AES acceleration of the A20 SoC called Security System (SS) <http://sunxi.montjoie.ovh>. Is this still the case? Greetings from Bielefeld, Germany! Christian -- Christian Pietsch · volunteering for Digitalcourage e.V., Bielefeld, Germany https://digitalcourage.de | https://bigbrotherawards.de Vorratsdatenspeicherung? Nicht schon wieder! Unterstützt unsere Verfassungsbeschwerde: https://digitalcourage.de/weg-mit-vds Rettet den Datenschutz – der aktuelle Entwurf für ein neues Datenschutzgesetz ist eine Katastrophe: https://digitalcourage.de/rettet-den-datenschutz
Can you please move these discussions to a more appropriate mailing list (i.e. tor-talk or maybe tor-dev)? Thank you, Alexander --- PGP Key: https://dietrich.cx/pgp | 0x52FA4EE1722D54EB On 2016-12-08 12:11, Christian Pietsch wrote:
On Thu, Dec 08, 2016 at 10:41:46AM +0500, Roman Mamedov wrote:
On AMD that's been implemented only after "Family 15h" https://libreboot.org/faq/#amdbastards https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures
Family 15h itself is safe.
It includes FX-series 8-core CPUs at up to 5 GHz supporting DDR3-2133 RAM: https://en.wikipedia.org/wiki/Piledriver_%28microarchitecture%29
So don't handwave-away AMD with "they are doing that too", today you CAN have a non-backdoored modern high-performance CPU -- from AMD.
Interesting, but this microarchitecture entered the market in 2012 and is probably being phased out now, I guess?
As far as modular, open hardware is concerned, I set my hopes on the new EOMA68 architecture. This is a draft standard for computer cards in the PCMCIA form factor: http://elinux.org/Embedded_Open_Modular_Architecture/EOMA68
Crowdfunding for the first implementation of this specification (EOMA68-A20) has been successful: https://www.crowdsupply.com/eoma68/micro-desktop I ordered one, and I convinced Digitalcourage e.V. to order three more that will be used for trustworthy computing – maybe Tor relays.
The performance of this first implementation will probably be comparable to the CubieTruck which is based on the same SoC, the Allwinner A20, which is an ARM Cortex-A8 design. So CPU-wise, it will be between the Raspberry Pi 2 and 3. Network throughput might be better because it does not use Raspi's peculiar design.
New implementations with more powerful hardware are in preparation (see the latest updates on CrowdSupply), but we are still talking about smartphone-like systems.
Last time I checked, Tor did not support the hardware AES acceleration of the A20 SoC called Security System (SS) <http://sunxi.montjoie.ovh>. Is this still the case?
Greetings from Bielefeld, Germany! Christian
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Thu, 8 Dec 2016 12:11:48 +0100 Christian Pietsch <christian.pietsch@digitalcourage.de> wrote:
On Thu, Dec 08, 2016 at 10:41:46AM +0500, Roman Mamedov wrote:
On AMD that's been implemented only after "Family 15h" https://libreboot.org/faq/#amdbastards https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures
Family 15h itself is safe.
It includes FX-series 8-core CPUs at up to 5 GHz supporting DDR3-2133 RAM: https://en.wikipedia.org/wiki/Piledriver_%28microarchitecture%29
So don't handwave-away AMD with "they are doing that too", today you CAN have a non-backdoored modern high-performance CPU -- from AMD.
Interesting, but this microarchitecture entered the market in 2012 and is probably being phased out now, I guess?
It is still their current desktop/server performance offer today, the next generation ("AMD Zen", also making the switch to DDR4, and likely adding that PSP) is planned to be released some time in 2017 and is mostly at the stage of announcements and rumors right now. -- With respect, Roman
[Leaving stuff out that is not directly relevant for tor-relays.] As far as modular, low power, open hardware is concerned, I set my hopes on the new EOMA68 architecture. This is a draft standard for computer cards in the PCMCIA form factor: http://elinux.org/Embedded_Open_Modular_Architecture/EOMA68 Crowdfunding for the first implementation of this specification (EOMA68-A20) has been successful: https://www.crowdsupply.com/eoma68/micro-desktop I ordered one, and I convinced Digitalcourage e.V. to order three more that will be used for trustworthy computing – maybe Tor relays. The performance of this first implementation will probably be comparable to the CubieTruck which is based on the same SoC, the Allwinner A20, which is an ARM Cortex-A8 design. So CPU-wise, it will be between the Raspberry Pi 2 and 3. Network throughput might be better because it does not use Raspi's peculiar design. New implementations with more powerful hardware are in preparation (see the latest updates on CrowdSupply), but these will still be smartphone-like systems, not high performance servers. Last time I checked, Tor did not support the hardware AES acceleration of the A20 SoC called Security System (SS) <http://sunxi.montjoie.ovh>. Is this still the case? Would it be a good idea to encourage Tor relay operators to get one of these cheap headless computer cards to run secure non-exit relays that can be left running without consuming a lot of power? Greetings from Bielefeld, Germany! Christian -- Christian Pietsch · volunteering for Digitalcourage e.V., Bielefeld, Germany https://digitalcourage.de | https://bigbrotherawards.de Vorratsdatenspeicherung? Nicht schon wieder! Unterstützt unsere Verfassungsbeschwerde: https://digitalcourage.de/weg-mit-vds Rettet den Datenschutz – der aktuelle Entwurf für ein neues Datenschutzgesetz ist eine Katastrophe: https://digitalcourage.de/rettet-den-datenschutz
Intel ME/AMT concerns me too
AMD Family 15h itself is safe.
No one has any proof of that for any modern cpu from any maker, featureset irrelavant. They all accept microcode updates, which btw are all encrypted closed binary blobs. And the chips themselves are fully closed source containing billions of transistors. You simply have no idea what's in there and no way to economically and publicly test or negotiate to find out and openly publish it all. Talking about known shit like advertised ME/AMT + LM-NIC's corp management platform is fine, you might be able to mitigate. But it's the unknown that will kill you. Billions of secret transistors... billions. Not good, and not necessary. #OpenFabs printing #OpenDesigns
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of grarpamp Sent: Friday, December 09, 2016 11:18 AM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Exploiting firmware
Intel ME/AMT concerns me too
AMD Family 15h itself is safe.
No one has any proof of that for any modern cpu from any maker, featureset irrelavant. They all accept microcode updates, which btw are all encrypted closed binary blobs. And the chips themselves are fully closed >source containing billions of transistors. You simply have no idea what's in there and no way to economically and publicly test or negotiate to find out and openly publish it all.
Talking about known shit like advertised ME/AMT + LM-NIC's corp management platform is fine, you might be able to mitigate. But it's the unknown that will kill you.
Billions of secret transistors... billions. Not good, and not necessary.
Agreed. Effort spent on guessing which closed source processor is safe is a wasted effort, and any conclusion that a certain processor is "safe" is a dangerous delusion resulting in flawed threat models. Just modify your threat model with the compromised processor assumption, calculate the risk of your specific computer being targeted, mitigate to the extent possible and get on with your life. Rana
On Fri, 9 Dec 2016 04:17:49 -0500 grarpamp <grarpamp@gmail.com> wrote:
Intel ME/AMT concerns me too
AMD Family 15h itself is safe.
No one has any proof of that for any modern cpu from any maker, featureset irrelavant.
Sure, to clarify what's meant here is "it does not implement the actual backdoor-like feature (separate CPU-within-CPU running proprietary code and having super-user rights over the rest of the system and full access to everything) in the form of 'Platform Security Processor' or 'Intel Management Engine'". Point is if you wanted a desktop CPU without such feature, there's an option available today, and you don't have to go back to Pentium 200 to avoid it.
They all accept microcode updates, which btw are all encrypted closed binary blobs.
Those are applied by your BIOS or your OS. https://packages.debian.org/jessie/amd64-microcode https://packages.debian.org/jessie/intel-microcode You don't HAVE to install those. It's not like they are auto-downloaded from the Internet directly by your CPU (at least if your CPU doesn't have those AMT/PSP things :).
And the chips themselves are fully closed source containing billions of transistors. You simply have no idea what's in there and no way to economically and publicly test or negotiate to find out and openly publish it all.
Sure there still can be subtle bugs and backdoors, but those will need to be subtle, well hidden, likely more difficult to exploit, and likely having much less of a "feature set" when exploited. Not to mention the devastating reputation effect on the vendor if uncovered.
Billions of secret transistors... billions. Not good, and not necessary.
#OpenFabs printing #OpenDesigns
As far as I know there's no fully free and open chip right now which provides performance expected of a modern desktop or server. There is the TALOS project[1], but for most people it'll be a non-starter due to price. And even there from what I see you don't get it made on an open fab. So we need to choose the least evil option from what we have available, and to me the AMD FX appears to be a win in that regard. [1] https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstatio... -- With respect, Roman
On Fri, Dec 9, 2016 at 4:53 AM, Roman Mamedov <rm@romanrm.net> wrote:
option available today, and you don't have to go back to Pentium 200 to avoid
Using such a relic as a scrub firewall might protect you from magic packets launched by your adversaries towards one of those listening transistors in your shiny new Skylake you'd otherwise have directly connected to the net.
It's not like they are auto-downloaded from the Internet directly by your CPU
Billions of transistors, billions of packets, billions of bits, billions of broadcast internet 'scans', who's watching...
Sure there still can be subtle bugs and backdoors, but those will need to be subtle, well hidden, likely more difficult to exploit, and likely having much less of a "feature set" when exploited. Not to mention the devastating reputation effect on the vendor if uncovered.
There may not be any evil silicon code, perhaps just an agnostic monitor vm, external pushed codeload then exec trigger, they'll call it an undoc engineering feature, AMT precursor, not meant for public use, tie it to some other legit thing, whatever, no problem.
#OpenFabs printing #OpenDesigns As far as I know there's no fully free and open chip right now which provides
That's because no one's giving any significant their free time / money / research to figure out how to do it, let alone develop talk about it as a serious global concept and goal and get it done. Always 'fab and open too costly' end convo. Bullshit, not costly per interested capita. What saying is in environment of secret HW no point in betting hardware trust right now... for tor relays or anything else. Lot of HW is proving to be so buggy, if not evil, that it's exploited and exec'd to become evil. So buy whatever's interesting, put opensource OS on it and pray neither of them are fucked. And hedge your future bet by figuring out #OpenFabs hardware just like you figured out OpenSource software.
What I was originally getting at was that the parts of the Raspberry Pi that are completely proprietary - while there is a free software implementation of the GPU blob, most people don't use that, as they are on stock Rasbian, which includes all the nasty "other parts" - are a great possibility for hijacking, perhaps through malicious code running on the GPU, which controls the CPU in several ways. The problem with this isn't that this is unique (Intel computers having so much more attack surface) but that a flaw in lots of these small computers that power a portion of the network means that an exploit in them due to lack of diversity would be much more serious. The management engine blob is also very serious. One possible mitigation might be to run the relays in VMs with good isolation, e.g. Xen on recent hardware which has good IOMMU. This makes it much harder to exploit the actual software that runs on the ME since the VMs would, in theory, have no access to hardware. It should be of concern on any hardware that is being used for related purposes, I think. However, whether it works out in practice as a backdoor that is worth exploiting vs other methods is debatable. Regardless, diversity is good. On 07/12/16 20:35, Gumby wrote:
Subject seems to have changed a bit, so not hijacking it. When thinking of any exploitation of firmware - should there be concerns of Intel's Management Engine in the CPU of any relays running on "home hardware" in any common unused pc or laptop? Should that be a concern on ANY newer Intel hardware?
Gumby
Which "other parts" do you mean? The GPU blob or Raspbian? You don't need to use the stock distribution. On 07.12.2016 23:10, Duncan Guthrie wrote:
What I was originally getting at was that the parts of the Raspberry Pi that are completely proprietary - while there is a free software implementation of the GPU blob, most people don't use that, as they are on stock Rasbian, which includes all the nasty "other parts" - are a great possibility for hijacking, perhaps through malicious code running on the GPU, which controls the CPU in several ways. The problem with this isn't that this is unique (Intel computers having so much more attack surface) but that a flaw in lots of these small computers that power a portion of the network means that an exploit in them due to lack of diversity would be much more serious.
Better a lots of these small computers than none ...
The management engine blob is also very serious. One possible mitigation might be to run the relays in VMs with good isolation, e.g. Xen on recent hardware which has good IOMMU. This makes it much harder to exploit the actual software that runs on the ME since the VMs would, in theory, have no access to hardware.
It should be of concern on any hardware that is being used for related purposes, I think. However, whether it works out in practice as a backdoor that is worth exploiting vs other methods is debatable.
Regardless, diversity is good.
That's true! Regards,
On 07/12/16 20:35, Gumby wrote:
Subject seems to have changed a bit, so not hijacking it. When thinking of any exploitation of firmware - should there be concerns of Intel's Management Engine in the CPU of any relays running on "home hardware" in any common unused pc or laptop? Should that be a concern on ANY newer Intel hardware?
Gumby
On Tue, 6 Dec 2016 22:00:20 +0100 diffusae <punasipuli@t-online.de> wrote:
Well, I can read and also now the translation from Bits to Bytes. But I am not sure about your value of the maximum network capacity.
That's the iperf3 measurement of a Raspberry Pi 1 Model B+:
[ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 83.6 MBytes 8.36 MBytes/sec 141 sender [ 4] 0.00-10.00 sec 83.1 MBytes 8.31 MBytes/sec receiver
It's no problem to push close to 100 Mbit on any Raspberry Pi with just plain iperf. [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 111 MBytes 93.1 Mbits/sec Tor is entirely another story though, with all its encryption/decryption and the need to keep track of a few thousands of connections at the same time. I suppose the "1 MB/sec" figure mentioned was about Tor specifically. -- With respect, Roman
Am 06.12.2016 um 18:16 schrieb Rana:
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of pa011 Sent: Tuesday, December 06, 2016 1:24 AM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
I would like to hear about ONE Raspi Tor operator who was allowed by DirAuths (or bwauths or whatever) to come even near 1 mbit/s bandwidth utilization
let me tell: https://atlas.torproject.org/#details/AA44C4BE3C90DCAAC09E5CD26150710AAA80D5... https://atlas.torproject.org/#details/CA9A5D5C4688F04EEC1AF810B0FD348109FA17...
are sharing the same dynamic IP on a Rasp2 -cut every 24 hours
day rx | tx | total | avg. rate ------------------------+-------------+-------------+--------------- 05.12.2016 27,20 GiB | 28,39 GiB | 55,59 GiB | 5,40 Mbit/s
that is slight above 1 Mbit/s :-)
Best regards
Paul ----------------------------
Wow nice bandwidth you are pushing through Paul! You mean two Raspi 2's sharing an Internet connection, each relaying 27 Gbytes per day at 5.4 Mbit/s on the average?? Total 10.8 Mbit/s?? Or 2.7 Mbit/s each?
It is just 1 single Rasp2 - running 2 tor instances on 1 IP, details here https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create...
Definitely refutes the previously claimed 1 Mbit/s Tor limit on Raspi, and means that Raspi has nothing to do with the ridiculously low utilization of my relay, just as I thought. As a matter of fact this means that whoever is NOT running a relay on a Raspi (or two, or four of them) is wasting money, unless he has a computer lying about with nothing better to do.
Also, what's the max memory and CPU utilization on your Raspi (I have read somewhere that Tor is only capable of utilizing 2 of the 4 CPU cores), and what kind of Internet connection do you have?
The Rasp2 is fairly unused, in memory and CPU - running on a German DSL - giving tested max. 7Mbit/s upload top - 19:15:15 up 47 days, 1:11, 2 users, load average: 0,37, 0,26, 0,24 Tasks: 118 total, 2 running, 116 sleeping, 0 stopped, 0 zombie %Cpu(s): 10,3 us, 1,9 sy, 0,0 ni, 86,4 id, 0,0 wa, 0,0 hi, 1,4 si, 0,0 st KiB Mem: 947756 total, 831368 used, 116388 free, 147964 buffers KiB Swap: 102396 total, 0 used, 102396 free. 426736 cached Mem
BTW the $35 Raspi 3 has 33% more CPU power than your Raspi 2 and the same amount of memory.
There is no need for a Rasp3 under given condition - not even the Rasp2 is getting warm :-)
Rana
Hi! That's from today: rx | tx | total | avg. rate ------------------------+-------------+-------------+--------------- today 6,26 GiB | 5,21 GiB | 11,47 GiB | 1,27 Mbit/s It's just a "low" bandwidth, but this depends on the ISP. It's a RPi-B plus and it can't handle more than around 2000 TCP connections simultaneously unless you are not using the normal CPU speed (700 MHz). If there would be more bandwidth, than it should be higher. Regards, On 06.12.2016 19:25, pa011 wrote:
Am 06.12.2016 um 18:16 schrieb Rana:
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of pa011 Sent: Tuesday, December 06, 2016 1:24 AM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
I would like to hear about ONE Raspi Tor operator who was allowed by DirAuths (or bwauths or whatever) to come even near 1 mbit/s bandwidth utilization
let me tell: https://atlas.torproject.org/#details/AA44C4BE3C90DCAAC09E5CD26150710AAA80D5... https://atlas.torproject.org/#details/CA9A5D5C4688F04EEC1AF810B0FD348109FA17...
are sharing the same dynamic IP on a Rasp2 -cut every 24 hours
day rx | tx | total | avg. rate ------------------------+-------------+-------------+--------------- 05.12.2016 27,20 GiB | 28,39 GiB | 55,59 GiB | 5,40 Mbit/s
that is slight above 1 Mbit/s :-)
Best regards
Paul ----------------------------
Wow nice bandwidth you are pushing through Paul! You mean two Raspi 2's sharing an Internet connection, each relaying 27 Gbytes per day at 5.4 Mbit/s on the average?? Total 10.8 Mbit/s?? Or 2.7 Mbit/s each?
It is just 1 single Rasp2 - running 2 tor instances on 1 IP, details here https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create...
Definitely refutes the previously claimed 1 Mbit/s Tor limit on Raspi, and means that Raspi has nothing to do with the ridiculously low utilization of my relay, just as I thought. As a matter of fact this means that whoever is NOT running a relay on a Raspi (or two, or four of them) is wasting money, unless he has a computer lying about with nothing better to do.
Also, what's the max memory and CPU utilization on your Raspi (I have read somewhere that Tor is only capable of utilizing 2 of the 4 CPU cores), and what kind of Internet connection do you have?
The Rasp2 is fairly unused, in memory and CPU - running on a German DSL - giving tested max. 7Mbit/s upload
top - 19:15:15 up 47 days, 1:11, 2 users, load average: 0,37, 0,26, 0,24 Tasks: 118 total, 2 running, 116 sleeping, 0 stopped, 0 zombie %Cpu(s): 10,3 us, 1,9 sy, 0,0 ni, 86,4 id, 0,0 wa, 0,0 hi, 1,4 si, 0,0 st KiB Mem: 947756 total, 831368 used, 116388 free, 147964 buffers KiB Swap: 102396 total, 0 used, 102396 free. 426736 cached Mem
BTW the $35 Raspi 3 has 33% more CPU power than your Raspi 2 and the same amount of memory.
There is no need for a Rasp3 under given condition - not even the Rasp2 is getting warm :-)
Rana
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Wow nice bandwidth you are pushing through Paul! You mean two Raspi 2's sharing an Internet connection, each relaying 27 Gbytes per day at 5.4 Mbit/s on the average?? Total 10.8 Mbit/s?? Or 2.7 Mbit/s each?
It is just 1 single Rasp2 - running 2 tor instances on 1 IP, details here https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create...
Any specific reason you have for running 2 instances of Tor on the same Raspi instead of one?
On Wed, 7 Dec 2016 11:02:59 +0200 "Rana" <ranaventures@gmail.com> wrote:
Wow nice bandwidth you are pushing through Paul! You mean two Raspi 2's sharing an Internet connection, each relaying 27 Gbytes per day at 5.4 Mbit/s on the average?? Total 10.8 Mbit/s?? Or 2.7 Mbit/s each?
It is just 1 single Rasp2 - running 2 tor instances on 1 IP, details here https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create...
Any specific reason you have for running 2 instances of Tor on the same Raspi instead of one?
It has 4 cores, and a single instance of Tor cannot utilize all of them. It only uses one core and maybe 20-30% at most of another. Ideally you would run 3-4 Tor instances on a 4-core machine (if RAM allows), but the maximum allowed by the Tor authority servers is 2 per IPv4. -- With respect, Roman
participants (14)
-
Alex Haydock -
Alexander Dietrich -
Christian Pietsch -
diffusae -
Duncan Guthrie -
grarpamp -
Gumby -
pa011 -
Ralph Seichter -
Rana -
Roman Mamedov -
SuperSluether -
Tim Kuijsten -
Tristan