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/AA44C4BE3C90DCAAC09E5CD26150710AAA80D58B
<https://atlas.torproject.org/#details/AA44C4BE3C90DCAAC09E5CD26150710AAA80D58B>
https://atlas.torproject.org/#details/CA9A5D5C4688F04EEC1AF810B0FD348109FA17FB
<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

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 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.

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

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

:-)

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

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

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/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

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 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

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.

...

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

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...

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

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.

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

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.