Hi,
Once upon a time, siv.sunet.se helped measuring the performance of the Tor network [0]. The hardware siv is running on was also hosting one of the bandwidth authoritites [1] for many years. Now that computer has grown old and tired so I thought I'd just take it offline and let it rest for a bit.
However, judging from its web server logs, several systems on the internet are pulling bwauth files form siv. If you are running one of these systems, please let me know how badly you need to continue doing this and for how long.
[0] https://metrics.torproject.org/torperf.html [1] https://metrics.torproject.org/totalcw.html
Hey Linus,
If I can't migrate to another server in the next couple of hours, I will need it online until Monday, or until someone gives me a new server to pull from - whichever is later.
-tom On Tue, 20 Nov 2018 at 18:26, Linus Nordberg linus@sunet.se wrote:
Hi,
Once upon a time, siv.sunet.se helped measuring the performance of the Tor network [0]. The hardware siv is running on was also hosting one of the bandwidth authoritites [1] for many years. Now that computer has grown old and tired so I thought I'd just take it offline and let it rest for a bit.
However, judging from its web server logs, several systems on the internet are pulling bwauth files form siv. If you are running one of these systems, please let me know how badly you need to continue doing this and for how long.
[0] https://metrics.torproject.org/torperf.html [1] https://metrics.torproject.org/totalcw.html _______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
I think I'm using this url. I'll check and remove it if that's the case.
On Tue, Nov 20, 2018, 10:44 AM Tom Ritter <tom@ritter.vg wrote:
Hey Linus,
If I can't migrate to another server in the next couple of hours, I will need it online until Monday, or until someone gives me a new server to pull from - whichever is later.
-tom On Tue, 20 Nov 2018 at 18:26, Linus Nordberg linus@sunet.se wrote:
Hi,
Once upon a time, siv.sunet.se helped measuring the performance of the Tor network [0]. The hardware siv is running on was also hosting one of the bandwidth authoritites [1] for many years. Now that computer has grown old and tired so I thought I'd just take it offline and let it rest for a bit.
However, judging from its web server logs, several systems on the internet are pulling bwauth files form siv. If you are running one of these systems, please let me know how badly you need to continue doing this and for how long.
[0] https://metrics.torproject.org/torperf.html [1] https://metrics.torproject.org/totalcw.html _______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
On Tue, Nov 20, 2018 at 06:43:48PM +0000, Tom Ritter wrote:
Hey Linus,
If I can't migrate to another server in the next couple of hours, I will need it online until Monday, or until someone gives me a new server to pull from - whichever is later.
Hi Tom,
If you don't find another, you can use
urls = ["https://www.seul.org/~bwauth/"]
like moria1's bwauth uses.
Or you can just stick your own copy of the files up somewhere and use that. They're easy to generate and it just needs any sort of webserver.
--Roger
Dear bandwidth authority operators,
On 20 Nov 2018, at 23:37, Linus Nordberg linus@sunet.se wrote:
However, judging from its web server logs, several systems on the internet are pulling bwauth files form siv. If you are running one of these systems, please let me know how badly you need to continue doing this and for how long.
If you can, please use different servers for your bandwidth files.
If multiple operators are using the same server, then it becomes a single point of failure for the bandwidth measurement system.
Similarly, try not to use servers that depend on torproject.org, because then the tor project DNS becomes a single point of failure.
Thanks for your hard work!
T
On Wed, 21 Nov 2018 at 04:15, teor teor@riseup.net wrote:
Dear bandwidth authority operators,
On 20 Nov 2018, at 23:37, Linus Nordberg linus@sunet.se wrote:
However, judging from its web server logs, several systems on the internet are pulling bwauth files form siv. If you are running one of these systems, please let me know how badly you need to continue doing this and for how long.
If you can, please use different servers for your bandwidth files.
If multiple operators are using the same server, then it becomes a single point of failure for the bandwidth measurement system.
Similarly, try not to use servers that depend on torproject.org, because then the tor project DNS becomes a single point of failure.
Thanks for your hard work!
So what's the best choice here? I don't think I have the capacity (neither speed or bandwidth cap) to self-host this on ritter.vg. I can use https://www.seul.org/ like moria. Or I can use fastly. Or something else?
-tom
On 27 Nov 2018, at 07:21, Tom Ritter tom@ritter.vg wrote:
On Wed, 21 Nov 2018 at 04:15, teor teor@riseup.net wrote:
Dear bandwidth authority operators,
On 20 Nov 2018, at 23:37, Linus Nordberg linus@sunet.se wrote:
However, judging from its web server logs, several systems on the internet are pulling bwauth files form siv. If you are running one of these systems, please let me know how badly you need to continue doing this and for how long.
If you can, please use different servers for your bandwidth files.
If multiple operators are using the same server, then it becomes a single point of failure for the bandwidth measurement system.
Similarly, try not to use servers that depend on torproject.org, because then the tor project DNS becomes a single point of failure.
Thanks for your hard work!
So what's the best choice here? I don't think I have the capacity (neither speed or bandwidth cap) to self-host this on ritter.vg. I can use https://www.seul.org/ like moria. Or I can use fastly. Or something else?
If no-one can run a server, I think your best option is to use fastly and seul.org. (Torflow can download from multiple servers.)
Here's my analysis:
seul.org: + doesn't depend on torproject.org DNS ? shared with moria1, might cause bias or bandwidth issues - shared with moria1, reducing redundancy
Fastly: + built-in redundancy ? does it depend on torproject.org DNS? ? CDN servers near exits might cause bias
Both: + built-in redundancy + doesn't depend on torproject.org DNS ? some potential bias, but not as much as a single server
T
Hi,
teor:
If no-one can run a server, I think your best option is to use fastly and seul.org. (Torflow can download from multiple servers.)
What are the requirements for this server?
Cheers, ~Vasilis
On 28 Nov 2018, at 19:57, juga juga@riseup.net wrote:
teor:
On 27 Nov 2018, at 07:21, Tom Ritter tom@ritter.vg wrote:
So what's the best choice here? I don't think I have the capacity (neither speed or bandwidth cap) to self-host this on ritter.vg. I can use https://www.seul.org/ like moria. Or I can use fastly. Or something else?
If no-one can run a server,
Maybe because very few people knows that these type of servers exist and are needed. What if we request for volunteers in the next meeting?.
On 28 Nov 2018, at 09:14, Vasilis andz@torproject.org wrote:
What are the requirements for this server?
The trust requirements are:
Bandwidth download servers are a critical part of Tor's infrastructure. If they break or are malicious, relay weights can change dramatically. So we need trusted volunteers to run them.
Each directory authority operator decides what trust means to them. Many operators run the servers themselves.
But if we can find a volunteer that the directory authority operator trusts, we can deploy a server now. Why wait until the next meeting?
The technical requirements are:
For Torflow (possibly outdated): * A HTTPS server with 500Mbit-1Gbit upstream (but other Torflow docs say 100Mbits+) * A fixed IP * 12-15Gbytes/day * Some files using the script at: https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/R...
For sbws: * A HTTP or HTTPS server that supports GET, HEAD, and Range (for example, Apache or Nginx) * A 1 GB file https://gitweb.torproject.org/sbws.git/tree/DEPLOY.rst#n16
We plan on replacing Torflow with sbws. So any new servers should be able to support both.
T
teor:
The technical requirements are: For sbws:
- A HTTP or HTTPS server that supports GET, HEAD, and Range (for example, Apache or Nginx)
- A 1 GB file
What are the upstream/downstream link requirements for sbws?
~Vasilis
Vasilis:
teor:
The technical requirements are: For sbws:
- A HTTP or HTTPS server that supports GET, HEAD, and Range (for example, Apache or Nginx)
- A 1 GB file
What are the upstream/downstream link requirements for sbws
Are the requirements in https://gitweb.torproject.org/sbws.git/tree/INSTALL.rst#n57 still accurate?
~Vasilis
Hi,
On 28 Nov 2018, at 10:26, Vasilis andz@torproject.org wrote:
Vasilis:
teor:
The technical requirements are: For sbws:
- A HTTP or HTTPS server that supports GET, HEAD, and Range
(for example, Apache or Nginx)
- A 1 GB file
What are the upstream/downstream link requirements for sbws
Are the requirements in https://gitweb.torproject.org/sbws.git/tree/INSTALL.rst#n57 still accurate?
The bandwidth requirements are slightly less than they used to be, because we turned off some optional features, and changed the scaling algorithm.
You could probably use a 100 Mbits connection.
T
teor:
On 28 Nov 2018, at 10:26, Vasilis andz@torproject.org wrote:
Vasilis:
teor:
The technical requirements are: For sbws:
- A HTTP or HTTPS server that supports GET, HEAD, and Range
(for example, Apache or Nginx)
- A 1 GB file
What are the upstream/downstream link requirements for sbws
Are the requirements in https://gitweb.torproject.org/sbws.git/tree/INSTALL.rst#n57 still accurate?
The bandwidth requirements are slightly less than they used to be, because we turned off some optional features, and changed the scaling algorithm.
You could probably use a 100 Mbits connection.
I can provide a dedicated server with these requirements in a university environment. I can roll a test version and maintain it if we decide that is useful.
~Vasilis
On Thu, 29 Nov 2018 at 03:49, Vasilis andz@torproject.org wrote:
teor:
On 28 Nov 2018, at 10:26, Vasilis andz@torproject.org wrote:
Vasilis:
teor:
The technical requirements are: For sbws:
- A HTTP or HTTPS server that supports GET, HEAD, and Range
(for example, Apache or Nginx)
- A 1 GB file
What are the upstream/downstream link requirements for sbws
Are the requirements in https://gitweb.torproject.org/sbws.git/tree/INSTALL.rst#n57 still accurate?
The bandwidth requirements are slightly less than they used to be, because we turned off some optional features, and changed the scaling algorithm.
You could probably use a 100 Mbits connection.
I can provide a dedicated server with these requirements in a university environment. I can roll a test version and maintain it if we decide that is useful.
That would be awesome. A HTTPS webserver with a self-signed certificate is sufficient, serving files generated like so:
for i in 64 32 16 8 4 2 1; do dd if=/dev/urandom of=./${i}M bs=1k count=`expr $i * 1024` done
for i in 512 256 128 64 32 16; do dd if=/dev/urandom of=./${i}k bs=1k count=$i done
Let me know the IP or hostname and I will switch over to it. (If you have an ETA on when it would be available, that would be great too; so Linus can decide if he wants to decommission before then and I can temporarily use fastly or something.)
-tom
Tom Ritter tom@ritter.vg wrote Thu, 29 Nov 2018 05:54:04 +0000:
Let me know the IP or hostname and I will switch over to it. (If you have an ETA on when it would be available, that would be great too; so Linus can decide if he wants to decommission before then and I can temporarily use fastly or something.)
My hard stop is Dec 21 but please let's try to make it possible to turn it off earlier.
On Thu 2018-11-29 05:54:04 +0000, Tom Ritter wrote:
On Thu, 29 Nov 2018 at 03:49, Vasilis andz@torproject.org wrote:
I can provide a dedicated server with these requirements in a university environment. I can roll a test version and maintain it if we decide that is useful.
That would be awesome. A HTTPS webserver with a self-signed certificate is sufficient, serving files generated like so:
that looks to be the formula to create files for use by torflow, taken from:
https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/R...
for use by sbws, it's not clear what we need the name of the 1GB file to be:
https://gitweb.torproject.org/sbws.git/tree/DEPLOY.rst#n16
perhaps the filename doesn't matter for sbws as long as it's known?
Anyway, in case it's useful, i've put the torflow files on a (non-dedicated) server i control as well. You are welcome to point your torflow scanner at:
(This is for Tom specifically so that Linus' machine can be retired, but anyone else in the Project who runs a bandwidth scanner and wants to pull from me should just let me know and i'm happy.)
Please let me know if there's any problem using it.
I'm happy to set it up for serving the 1GB file for sbws too, i just don't know what that should be called.
--dkg
On 11/29/2018 11:35 AM, Daniel Kahn Gillmor wrote:
On Thu 2018-11-29 05:54:04 +0000, Tom Ritter wrote:
On Thu, 29 Nov 2018 at 03:49, Vasilis andz@torproject.org wrote:
I can provide a dedicated server with these requirements in a university environment. I can roll a test version and maintain it if we decide that is useful.
That would be awesome. A HTTPS webserver with a self-signed certificate is sufficient, serving files generated like so:
that looks to be the formula to create files for use by torflow, taken from:
https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/R...
for use by sbws, it's not clear what we need the name of the 1GB file to be:
https://gitweb.torproject.org/sbws.git/tree/DEPLOY.rst#n16
perhaps the filename doesn't matter for sbws as long as it's known?
Anyway, in case it's useful, i've put the torflow files on a (non-dedicated) server i control as well. You are welcome to point your torflow scanner at:
https://bw.cmrg.net/(This is for Tom specifically so that Linus' machine can be retired, but anyone else in the Project who runs a bandwidth scanner and wants to pull from me should just let me know and i'm happy.)
Please let me know if there's any problem using it.
I'm happy to set it up for serving the 1GB file for sbws too, i just don't know what that should be called.
--dkg
dkg:
for sbws, the sbws config file needs to know the name. as long as you tell us the name and path / url to the file, we can add it in our sbws config and that is good enough.
sb
On Thu 2018-11-29 11:39:33 -0800, S. Banerian wrote:
for sbws, the sbws config file needs to know the name. as long as you tell us the name and path / url to the file, we can add it in our sbws config and that is good enough.
Gotcha!
A 1GiB file for sbws folks is available at:
BTW, the bandwidth for this service is coming from May First/People Link (https://mayfirst.org/), who are happy to help out Tor like this. Good to have long-standing allies. :)
--dkg
On Thu, 29 Nov 2018 at 19:35, Daniel Kahn Gillmor dkg@fifthhorseman.net wrote:
Anyway, in case it's useful, i've put the torflow files on a (non-dedicated) server i control as well. You are welcome to point your torflow scanner at:
https://bw.cmrg.net/(This is for Tom specifically so that Linus' machine can be retired, but anyone else in the Project who runs a bandwidth scanner and wants to pull from me should just let me know and i'm happy.)
Please let me know if there's any problem using it.
As of this timestamp maatuska's bwauth is using this server exclusively. Thanks dkg!
It sounds like I was the last user of siv, so Linus, feel free to decommission!
-tom
Tom Ritter tom@ritter.vg wrote Tue, 4 Dec 2018 14:44:04 +0000:
As of this timestamp maatuska's bwauth is using this server exclusively. Thanks dkg!
It sounds like I was the last user of siv, so Linus, feel free to decommission!
Thanks Tom, thanks dkg!
I see a ~40% decline in incoming requests the last 15h. Seems likely that there's another bandwidth scanner using siv.
I'm shutting down the web server now to see if anyone reacts. Can bring it up again within short notice, for yet some time.
On 6 Dec 2018, at 00:07, Linus Nordberg linus@torproject.org wrote:
Tom Ritter tom@ritter.vg wrote Tue, 4 Dec 2018 14:44:04 +0000:
As of this timestamp maatuska's bwauth is using this server exclusively. Thanks dkg!
It sounds like I was the last user of siv, so Linus, feel free to decommission!
Thanks Tom, thanks dkg!
I see a ~40% decline in incoming requests the last 15h. Seems likely that there's another bandwidth scanner using siv.
I'm shutting down the web server now to see if anyone reacts. Can bring it up again within short notice, for yet some time.
Tor ignores stale bandwidth files after 3 days: https://github.com/torproject/tor/blob/master/src/feature/dirauth/bwauth.h#L...
So we'll be able to see who is still using siv on Saturday: https://consensus-health.torproject.org/#bwauthstatus
I don't think torflow sends scanner info in its requests. But sbws will soon: https://trac.torproject.org/projects/tor/ticket/28741#ticket
T
Hi,
I have deployed a sbws instance that be found on the following URL: https://sbws.lavafeld.org/sbws.bin
It runs on a dedicated hardware with sufficient enough resources to handle a bunch of connections and load.
I also made an ansible role that deploys sbws running as a user and uses Caddy as its webserver, the role can be found here: https://github.com/anadahz/sbws-ansible
Feel free to use it.
Cheers, ~Vasilis
Hi Vasilis,
Vasilis:
Hi,
I have deployed a sbws instance that be found on the following URL: https://sbws.lavafeld.org/sbws.bin
It runs on a dedicated hardware with sufficient enough resources to handle a bunch of connections and load.
I also made an ansible role that deploys sbws running as a user and uses Caddy as its webserver, the role can be found here: https://github.com/anadahz/sbws-ansible
Thanks for this work. The ansible role can be useful for installing test servers. The recommended way to install sbws to be used by a directory authority is the Debian package [0]. That was the decision after discussing it months ago in IRC #tor-dev, in trac.tpo tickets and with the directory authorities. sbws is already being used by a directory authority, but we think it's still not ready to be deployed in more directory authorities.
juga.
Hi juga,
juga:
Vasilis:
I also made an ansible role that deploys sbws running as a user and uses Caddy as its webserver, the role can be found here: https://github.com/anadahz/sbws-ansible
Thanks for this work. The ansible role can be useful for installing test servers. The recommended way to install sbws to be used by a directory authority is the Debian package [0].
In fact when I started building this role I was installing sbws from the Debian package but then I realized that a number of developments where not in the package. The role can be adjusted to install sbws from the Debian package and I can add support to install it from the Debian package if there is interest.
Cheers, ~Vasilis
On 5 Dec 2018, at 10:30, Vasilis andz@torproject.org wrote:
juga:
Vasilis:
I also made an ansible role that deploys sbws running as a user and uses Caddy as its webserver, the role can be found here: https://github.com/anadahz/sbws-ansible
Thanks for this work. The ansible role can be useful for installing test servers. The recommended way to install sbws to be used by a directory authority is the Debian package [0].
Hmm, that's not quite true.
Some directory authority operators don't run Debian, so they can't install Debian packages. (alien might work for some other Linuxes.)
More precisely, the existing bandwidth authorities run on Debian, because Torflow needs to be patched to run on non-Linux OSes.
In fact when I started building this role I was installing sbws from the Debian package but then I realized that a number of developments where not in the package.
sbws 1.0.2 is in Debian.
We've delayed 1.0.3 until we fix some critical sbws bugs that are blocking deployment on more bandwidth authorities.
The role can be adjusted to install sbws from the Debian package and I can add support to install it from the Debian package if there is interest.
Sounds like a good idea.
T
teor:
On 5 Dec 2018, at 10:30, Vasilis andz@torproject.org wrote:
The role can be adjusted to install sbws from the Debian package and I can add support to install it from the Debian package if there is interest.
Sounds like a good idea.
The role now supports installing sbws from the Debian testing repository.
I also added support to generate lightweight network stats (~ every 15 minutes) using vnstat and expose them on the landing page. The result can be seen here: https://sbws.lavafeld.org
Cheers, ~Vasilis
Hi juga,
On 29 Nov 2018, at 13:48, Vasilis andz@torproject.org wrote:
Signed PGP part teor:
On 28 Nov 2018, at 10:26, Vasilis andz@torproject.org wrote:
Vasilis:
teor:
The technical requirements are: For sbws:
- A HTTP or HTTPS server that supports GET, HEAD, and Range
(for example, Apache or Nginx)
- A 1 GB file
What are the upstream/downstream link requirements for sbws
Are the requirements in https://gitweb.torproject.org/sbws.git/tree/INSTALL.rst#n57 still accurate?
The bandwidth requirements are slightly less than they used to be, because we turned off some optional features, and changed the scaling algorithm.
You could probably use a 100 Mbits connection.
I can provide a dedicated server with these requirements in a university environment. I can roll a test version and maintain it if we decide that is useful.
Do we need another test sbws server?
Do we want to have one spare for the next bandwidth authority?
T
teor:
Hi juga,
On 29 Nov 2018, at 13:48, Vasilis andz@torproject.org wrote:
Signed PGP part teor:
On 28 Nov 2018, at 10:26, Vasilis andz@torproject.org wrote:
Vasilis:
teor:
The technical requirements are: For sbws:
- A HTTP or HTTPS server that supports GET, HEAD, and Range
(for example, Apache or Nginx)
- A 1 GB file
What are the upstream/downstream link requirements for sbws
Are the requirements in https://gitweb.torproject.org/sbws.git/tree/INSTALL.rst#n57 still accurate?
The bandwidth requirements are slightly less than they used to be, because we turned off some optional features, and changed the scaling algorithm.
You could probably use a 100 Mbits connection.
I can provide a dedicated server with these requirements in a university environment. I can roll a test version and maintain it if we decide that is useful.
Do we need another test sbws server?
While so far only the person that have access to the server can see the problems running it, the raw measurements and the bandwidth files produced, i'm not sure how useful it can be.
Do we want to have one spare for the next bandwidth authority?
I think this should be a question for the directory authorities, is up to them to decide where to run the bandwidth authority.
juga.
teor:
Hi,
On 28 Nov 2018, at 10:26, Vasilis andz@torproject.org wrote:
Vasilis:
teor:
The technical requirements are: For sbws:
- A HTTP or HTTPS server that supports GET, HEAD, and Range
(for example, Apache or Nginx)
- A 1 GB file
What are the upstream/downstream link requirements for sbws
Are the requirements in https://gitweb.torproject.org/sbws.git/tree/INSTALL.rst#n57 still accurate?
The bandwidth requirements are slightly less than they used to be, because we turned off some optional features, and changed the scaling algorithm.
You could probably use a 100 Mbits connection.
Should the file server have the same upstream that the scanner?. Which upstream have other bwauths?. longclaw's scanner is 1Gbit/s.
juga.
On 29 Nov 2018, at 23:56, juga juga@riseup.net wrote:
teor:
On 28 Nov 2018, at 10:26, Vasilis andz@torproject.org wrote:
Vasilis:
teor:
The technical requirements are: For sbws:
- A HTTP or HTTPS server that supports GET, HEAD, and Range
(for example, Apache or Nginx)
- A 1 GB file
What are the upstream/downstream link requirements for sbws
Are the requirements in https://gitweb.torproject.org/sbws.git/tree/INSTALL.rst#n57 still accurate?
The bandwidth requirements are slightly less than they used to be, because we turned off some optional features, and changed the scaling algorithm.
You could probably use a 100 Mbits connection.
Should the file server have the same upstream that the scanner?.
The file server should be able to serve at the peak capacity of all the scanner threads using it.
If there is one file sever and one scanner, then the file server's upload should be about the same as the scanner's download.
If multiple scanners use the same server, split the server's bandwidth between them.
If a scanner uses multiple servers, add the servers' bandwidths.
Which upstream have other bwauths?. longclaw's scanner is 1Gbit/s.
I don't know. I don't have a list of all the bandwidth scanner configs.
T
teor:
On 27 Nov 2018, at 07:21, Tom Ritter tom@ritter.vg wrote:
On Wed, 21 Nov 2018 at 04:15, teor teor@riseup.net wrote:
Dear bandwidth authority operators,
On 20 Nov 2018, at 23:37, Linus Nordberg linus@sunet.se wrote:
However, judging from its web server logs, several systems on the internet are pulling bwauth files form siv. If you are running one of these systems, please let me know how badly you need to continue doing this and for how long.
If you can, please use different servers for your bandwidth files.
If multiple operators are using the same server, then it becomes a single point of failure for the bandwidth measurement system.
Similarly, try not to use servers that depend on torproject.org, because then the tor project DNS becomes a single point of failure.
Thanks for your hard work!
So what's the best choice here? I don't think I have the capacity (neither speed or bandwidth cap) to self-host this on ritter.vg. I can use https://www.seul.org/ like moria. Or I can use fastly. Or something else?
If no-one can run a server,
Maybe because very few people knows that these type of servers exist and are needed. What if we request for volunteers in the next meeting?.
I think your best option is to use fastly and seul.org. (Torflow can download from multiple servers.)
Here's my analysis:
seul.org:
- doesn't depend on torproject.org DNS
? shared with moria1, might cause bias or bandwidth issues
- shared with moria1, reducing redundancy
Fastly:
- built-in redundancy
? does it depend on torproject.org DNS? ? CDN servers near exits might cause bias
Both:
- built-in redundancy
- doesn't depend on torproject.org DNS
? some potential bias, but not as much as a single server
T
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
Hi Linus,
On 20/11/18 13:37, Linus Nordberg wrote:
Once upon a time, siv.sunet.se helped measuring the performance of the Tor network [0]. The hardware siv is running on was also hosting one of the bandwidth authoritites [1] for many years. Now that computer has grown old and tired so I thought I'd just take it offline and let it rest for a bit.
While Metrics no longer collects Torperf data, we do have a diversity issue with vantage points for OnionPerf (they are all in the same AS). If it were possible to get another host in sunet for running the OnionPerf measurements that we could pull into Metrics then that would be awesome.
Thanks, Iain.
Hi Iain,
Iain Learmonth irl@torproject.org wrote Wed, 21 Nov 2018 08:46:25 +0000:
While Metrics no longer collects Torperf data, we do have a diversity issue with vantage points for OnionPerf (they are all in the same AS). If it were possible to get another host in sunet for running the OnionPerf measurements that we could pull into Metrics then that would be awesome.
Running an OnionPerf instance on Sunet space is something that I've had on my list for ages and I'm sorry that it's been ignored for so long. Seems like I can't find my notes on what that'd require in terms of CPU, RAM, storage, expected amount and type of traffic. Can you help?
Hi Linus,
On 21/11/18 09:43, Linus Nordberg wrote:
Running an OnionPerf instance on Sunet space is something that I've had on my list for ages and I'm sorry that it's been ignored for so long. Seems like I can't find my notes on what that'd require in terms of CPU, RAM, storage, expected amount and type of traffic. Can you help?
Awesome!
Our VMs one CPU core with 2GB of RAM. This seems to work well.
It transmits about 173 MiB and receives 193 MiB for a total of 366 MiB daily, on average. There were a few days in these measurements when it was down, so these estimates might be skewed a bit lower than what you should expect.
Thanks, Iain.
Hi Linus,
On 21/11/18 10:34, Iain Learmonth wrote:
storage
Forgot this one, we'd want to keep around 200MB of results handy. We'd need room for a Debian system, plus the installation of OnionPerf itself. A 20GB disk would probably comfortably fit everything.
Thanks, Iain.
tor-project@lists.torproject.org
-
Daniel Kahn Gillmor -
Iain Learmonth -
juga -
Linus Nordberg -
Linus Nordberg -
Roger Dingledine -
S. Banerian -
Sina Rabbani -
teor -
Tom Ritter -
Vasilis