Re: [tor-relays] Second relay on same ESX

[Patrick DERWAEL]

Hi,
No, they will be 2 almost identical VMs: clone, change IP, host & nick, get
the FP, update the family on both VMs and reload configs

BTW: thank you all for the feedback!

P.

2016-12-12 7:08 GMT+01:00 balbea16 :

> Hi
> Are you actually talking about identical relays, i.e. with the same
> fingerprint? That would be interessting for me, as I'd like to run a second
> Rasp Pi in parallel for redundency reasons.
> Mike
>
>
>  Ursprüngliche Nachricht 
> Von: Patrick DERWAEL 
> Datum: 12.12.16 06:41 (GMT+01:00)
> An: tor-relays@lists.torproject.org
> Betreff: Re: [tor-relays] Second relay on same ESX
>
> John,
> The host has 32GB RAM& 4 CPUs
> I have allocated 2GB & 2CPUs to my VM
> As the VM CPU usage is +/-40%, I'm not sure if I should reduce to 1CPU
> (would it then be used at 80% average?)
>
> P.
>
> 2016-12-11 18:22 GMT+01:00 John Ricketts :
>
>> Patrick,
>>
>> I run all of my relays under VMware  and I don't have any issues at all.
>>
>> How many CPUs do you have in the physical server and how many virtual
>> CPUs do you have assigned to the VM?
>>
>> John
>>
>> On Dec 11, 2016, at 11:19, Patrick DERWAEL  wrote:
>>
>> Hi guys,
>>
>> I'm running a relay in a VM on a physical server which is largely under
>> used
>> Current advertised bandwidth 26MB, consensus 76500
>> I'm considering running a second relay (2nd VM) on the very same
>> hardware, but this brings a few questions:
>>
>> - is there any issue running it at the same geographical place?
>> - would the current total BW effectively consumed (26MB) be divided in 2
>> (i.e. no added value in BW)?
>> - basically, would it have any significant added value to the network?
>>
>> Thanks
>>
>>
>>
>> ___
>> 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
>
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Second relay on same ESX

[balbea16]

Hi Tim,TNX for your fast response. That was more or less what I thought 
already. Mike

 Ursprüngliche Nachricht 
Von: teor  
Datum: 12.12.16  07:28  (GMT+01:00) 
An: tor-relays@lists.torproject.org 
Betreff: Re: [tor-relays] Second relay on same ESX 


> On 12 Dec. 2016, at 17:08, balbea16  wrote:
> 
> Hi 
> Are you actually talking about identical relays, i.e. with the same 
> fingerprint? That would be interessting for me, as I'd like to run a second 
> Rasp Pi in parallel for redundency reasons.
> Mike

Please don't run a second relay on the same fingerprint.
Your relay won't get much traffic, because it will look like
its address and ports are changing all the time.

Instead, run two relays with different keys, and let the
network load-balance between them.

Tim

>  Ursprüngliche Nachricht 
> Von: Patrick DERWAEL  
> Datum: 12.12.16 06:41 (GMT+01:00) 
> An: tor-relays@lists.torproject.org 
> Betreff: Re: [tor-relays] Second relay on same ESX 
> 
> John,
> The host has 32GB RAM& 4 CPUs
> I have allocated 2GB & 2CPUs to my VM
> As the VM CPU usage is +/-40%, I'm not sure if I should reduce to 1CPU (would 
> it then be used at 80% average?)
> 
> P.
> 
> 2016-12-11 18:22 GMT+01:00 John Ricketts :
> Patrick,
> 
> I run all of my relays under VMware  and I don't have any issues at all.
> 
> How many CPUs do you have in the physical server and how many virtual CPUs do 
> you have assigned to the VM?
> 
> John
> 
> On Dec 11, 2016, at 11:19, Patrick DERWAEL  wrote:
> 
>> Hi guys,
>> 
>> I'm running a relay in a VM on a physical server which is largely under used
>> Current advertised bandwidth 26MB, consensus 76500
>> I'm considering running a second relay (2nd VM) on the very same hardware, 
>> but this brings a few questions:
>> 
>> - is there any issue running it at the same geographical place?
>> - would the current total BW effectively consumed (26MB) be divided in 2 
>> (i.e. no added value in BW)?
>> - basically, would it have any significant added value to the network?
>> 
>> Thanks
>>  
>> ___
>> 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
> 
> 
> 
> 
> -- 
> Patrick Derwael
> Rue de la fontaine, 3
> 4210 Burdinne
> G:0479.80.50.79
> 
>  
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
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

Re: [tor-relays] Second relay on same ESX

[teor]

> On 12 Dec. 2016, at 17:08, balbea16  wrote:
> 
> Hi 
> Are you actually talking about identical relays, i.e. with the same 
> fingerprint? That would be interessting for me, as I'd like to run a second 
> Rasp Pi in parallel for redundency reasons.
> Mike

Please don't run a second relay on the same fingerprint.
Your relay won't get much traffic, because it will look like
its address and ports are changing all the time.

Instead, run two relays with different keys, and let the
network load-balance between them.

Tim

>  Ursprüngliche Nachricht 
> Von: Patrick DERWAEL  
> Datum: 12.12.16 06:41 (GMT+01:00) 
> An: tor-relays@lists.torproject.org 
> Betreff: Re: [tor-relays] Second relay on same ESX 
> 
> John,
> The host has 32GB RAM& 4 CPUs
> I have allocated 2GB & 2CPUs to my VM
> As the VM CPU usage is +/-40%, I'm not sure if I should reduce to 1CPU (would 
> it then be used at 80% average?)
> 
> P.
> 
> 2016-12-11 18:22 GMT+01:00 John Ricketts :
> Patrick,
> 
> I run all of my relays under VMware  and I don't have any issues at all.
> 
> How many CPUs do you have in the physical server and how many virtual CPUs do 
> you have assigned to the VM?
> 
> John
> 
> On Dec 11, 2016, at 11:19, Patrick DERWAEL  wrote:
> 
>> Hi guys,
>> 
>> I'm running a relay in a VM on a physical server which is largely under used
>> Current advertised bandwidth 26MB, consensus 76500
>> I'm considering running a second relay (2nd VM) on the very same hardware, 
>> but this brings a few questions:
>> 
>> - is there any issue running it at the same geographical place?
>> - would the current total BW effectively consumed (26MB) be divided in 2 
>> (i.e. no added value in BW)?
>> - basically, would it have any significant added value to the network?
>> 
>> Thanks
>>  
>> ___
>> 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
> 
> 
> 
> 
> -- 
> Patrick Derwael
> Rue de la fontaine, 3
> 4210 Burdinne
> G:0479.80.50.79
> 
>  
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Second relay on same ESX

[balbea16]

Hi Are you actually talking about identical relays, i.e. with the same 
fingerprint? That would be interessting for me, as I'd like to run a second 
Rasp Pi in parallel for redundency reasons.Mike

 Ursprüngliche Nachricht 
Von: Patrick DERWAEL  
Datum: 12.12.16  06:41  (GMT+01:00) 
An: tor-relays@lists.torproject.org 
Betreff: Re: [tor-relays] Second relay on same ESX 

John,
The host has 32GB RAM& 4 CPUs
I have allocated 2GB & 2CPUs to my VM
As the VM CPU usage is +/-40%, I'm not sure if I should reduce to 1CPU (would 
it then be used at 80% average?)

P.

2016-12-11 18:22 GMT+01:00 John Ricketts :






Patrick,



I run all of my relays under VMware  and I don't have any issues at all.



How many CPUs do you have in the physical server and how many virtual CPUs do 
you have assigned to the VM?



John


On Dec 11, 2016, at 11:19, Patrick DERWAEL  wrote:






Hi guys,



I'm running a relay in a VM on a physical server which is largely under used

Current advertised bandwidth 26MB, consensus 76500

I'm considering running a second relay (2nd VM) on the very same hardware, but 
this brings a few questions:



- is there any issue running it at the same geographical place?

- would the current total BW effectively consumed (26MB) be divided in 2 (i.e. 
no added value in BW)?

- basically, would it have any significant added value to the network?



Thanks



 







___

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





-- 

Patrick Derwael
Rue de la fontaine, 3
4210 Burdinne
G:0479.80.50.79
 

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Second relay on same ESX

[Matthias Fetzer]

Hi Patrick,

I recommend that you just try it. Many people run several instances on
the same hardware (even on same VMs) to saturate their line. You can
just try if running a second relay will consume more bw.

>> - basically, would it have any significant added value to the network?

I can stress what s7r said: If it increases overall bandwidth, it is
definately added value to the network.

Regards,

Matthias

On 12/11/2016 06:18 PM, Patrick DERWAEL wrote:
> Hi guys,
> 
> I'm running a relay in a VM on a physical server which is largely under used
> Current advertised bandwidth 26MB, consensus 76500
> I'm considering running a second relay (2nd VM) on the very same
> hardware, but this brings a few questions:
> 
> - is there any issue running it at the same geographical place?
> - would the current total BW effectively consumed (26MB) be divided in 2
> (i.e. no added value in BW)?
> - basically, would it have any significant added value to the network?
> 
> Thanks
> 
>  
> 
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Second relay on same ESX

[Patrick DERWAEL]

Well, I have 100MB guaranteed to the internet and a 1 GIG NIC, the VM CPU
is used at 40% (average)
I guess I will fire a second VM and see what the total bandwidth result
is...

2016-12-11 18:27 GMT+01:00 s7r :

> Hello,
>
> Thanks for running relays.
>
>
> Patrick DERWAEL wrote:
> > Hi guys,
> >
> > I'm running a relay in a VM on a physical server which is largely under
> used
> > Current advertised bandwidth 26MB, consensus 76500
> > I'm considering running a second relay (2nd VM) on the very same
> > hardware, but this brings a few questions:
> >
> > - is there any issue running it at the same geographical place?
>
> It desirable to have geographical diversity of course, but running two
> in the same place to increase capacity doesn't do any harm. Just don't
> forget to configure MyFamily in both torrcs so that the relays are
> linked together as belonging to the same family.
>
> > - would the current total BW effectively consumed (26MB) be divided in 2
> > (i.e. no added value in BW)?
>
> This depends on a lot of things. If your network port can handle more
> than 26MB, and the limit of 26 MB observed on the first relay comes from
> CPU/RAM, the 26 MB will not be divided but increased. If the first relay
> has underused CPU / RAM this means the 26 MB is a limitation that comes
> from the network port speed, and in this case it will be obviously divided.
>
> > - basically, would it have any significant added value to the network?
> >
> > Thanks
> >
>
> Yes, if the bandwidth grows. If the 26 MB is divided in two, it's easier
> and better to run a single one of 26 MB (save space in descriptors
> distributed network wide, have a single box to maintain and keep up to
> date, etc.)
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>


-- 

Patrick Derwael
Rue de la fontaine, 3
4210 Burdinne
G:0479.80.50.79
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Second relay on same ESX

[Patrick DERWAEL]

John,
The host has 32GB RAM& 4 CPUs
I have allocated 2GB & 2CPUs to my VM
As the VM CPU usage is +/-40%, I'm not sure if I should reduce to 1CPU
(would it then be used at 80% average?)

P.

2016-12-11 18:22 GMT+01:00 John Ricketts :

> Patrick,
>
> I run all of my relays under VMware  and I don't have any issues at all.
>
> How many CPUs do you have in the physical server and how many virtual CPUs
> do you have assigned to the VM?
>
> John
>
> On Dec 11, 2016, at 11:19, Patrick DERWAEL  wrote:
>
> Hi guys,
>
> I'm running a relay in a VM on a physical server which is largely under
> used
> Current advertised bandwidth 26MB, consensus 76500
> I'm considering running a second relay (2nd VM) on the very same hardware,
> but this brings a few questions:
>
> - is there any issue running it at the same geographical place?
> - would the current total BW effectively consumed (26MB) be divided in 2
> (i.e. no added value in BW)?
> - basically, would it have any significant added value to the network?
>
> Thanks
>
>
>
> ___
> 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
>
>


-- 

Patrick Derwael
Rue de la fontaine, 3
4210 Burdinne
G:0479.80.50.79
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] All I want for Chrismas is a bloody t-shirt

[I]

All,

>
We learnt a lot from doing it last year, and we have plans to make it
more efficient this year. (And get more people on it.)

We have already gone from having 0 paid people on it, to having 1
paid person on it (and they do many other tasks as well). I think we
are getting more to help over the next few months.

This should hopefully help relay operators get t-shirts as well.<<

One thing which seemed a silly time consumer was that when I put in a claim to 
the tshirt address forwarding the message that told to me I could claim a 
tshirt, my legitimacy was doubted because they didn't accept the reply was from 
the relay operator despite their initiating it!

What about simplifying that to one automated congratulation message with the 
request for the size and address in the answer?

Robert


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[teor]

> On 12 Dec. 2016, at 09:46, niftybunny  wrote:
> 
> Playing devils advocate here.
> 
> People want the T-Shirts. Its free advertisement for Tor. Perhaps it would be 
> great if people could get T-Shirts in
> exchange for other goods. Like this:
> 
> http://i.imgur.com/9Y8p7.gif
> 
> A long time ago this was possible: 
> https://www.torservers.net/wiki/tshirt/index#order
> 
> Perhaps we should do this again and #MAKETORGREATAGAIN
> 
> Markus

It is possible to donate and get a t-shirt:

https://donate.torproject.org/

We learnt a lot from doing it last year, and we have plans to make it
more efficient this year. (And get more people on it.)

We have already gone from having 0 paid people on it, to having 1
paid person on it (and they do many other tasks as well). I think we
are getting more to help over the next few months.

This should hopefully help relay operators get t-shirts as well.

Get back to us in early March if it hasn't worked out by then, and I'll
make sure I follow it up at the next Tor Meeting.

Tim

>> On 11 Dec 2016, at 22:50, Moritz Bartl  wrote:
>> On 12/10/2016 09:52 PM, pa011 wrote:
 btw, it would be awesome to give away t-shirts or something for running
 diverse relays.
>>> that was a least a promise the year ago (its not any more)
>>> - and I believe one should stand to his promises
>> 
>> I don't know where this idea is coming from that it's not any more the
>> case. I have not heard of any changes in that respect, the instructions
>> are still the same: https://www.torproject.org/getinvolved/tshirt.html
>> 
>> You need to email tshirts@, include your fingerprints, and then wait
>> weeks or months until the one poor person that is processing all the
>> requests and all the requests from the campaign and also has other hats
>> to get to it.
>> 
>> It's a thank you gift. I don't mean you, pa011, when I say this, but in
>> general I would expect a bit more gratitude and understanding what it
>> means to run a small understaffed organization. :(
>> 
>> Moritz
>> ___
>> 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

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Inconsistent BW measurements of unused relay

[Kurt Besig]

On 12/11/2016 1:43 PM, Rana wrote:
>> On 12 Dec. 2016, at 01:56, Rana  wrote:
>>
>> OK Tim thanks for the answers, I appreciate your patience with me 
>> [even though I "lack programming skills" :) ]
>>
>> The one answer of yours that still does not make sense to me is that 
>> arm actually means Kbytes/sec and not kbits/sec  when it writes Kb/s
>>
>> I have arm reporting average  of at least several tens of Kb/s all the time, 
>> and about 100 Kb/s most of the time,  and then I wind up with almost 
>> constant 200 bit/sec actual average rate over 6 hours, based on the total 
>> number of Mbytes sent that Tor reports in its log file. 
>>
>> Even if the 200 bit/sec figure is somehow rounded to 8000 bit/ sec or 
>> even 8000 bytes/sec as you suggested , this does not make sense…
> 
> Ok, so you didn't say that to start with, you seemed to be saying that it was 
> constantly showing 100 kb/s.
> 
> Perhaps arm is displaying your maximum bandwidth over a certain time?
> (I really don't now what bandwidth arm measures.)
> 
> T
> 
> I do not have a slightest freaking idea and this arm thing seems to have been 
> written by anarchists who thought that documentation was too bourgeois
> 
> Rana
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
When I first began running  Tor relays I felt a dependency regarding arm
and it's output as well. However, over the years I weened myself off arm
and just let the relay run without constant worries. I believe this is
the feeling of most operators. When I feel the need I run nload and
Vnstat is handy for analysis. Command line lsof and many others do a
good job as well.
Again, just offering my 2 cents worthno attack intended..



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[niftybunny]

Playing devils advocate here.

People want the T-Shirts. Its free advertisement for Tor. Perhaps it would be 
great if people could get T-Shirts in
exchange for other goods. Like this:

http://i.imgur.com/9Y8p7.gif 

A long time ago this was possible: 
https://www.torservers.net/wiki/tshirt/index#order 


Perhaps we should do this again and #MAKETORGREATAGAIN

Markus


> On 11 Dec 2016, at 22:50, Moritz Bartl  wrote:
> On 12/10/2016 09:52 PM, pa011 wrote:
>>> btw, it would be awesome to give away t-shirts or something for running
>>> diverse relays.
>> that was a least a promise the year ago (its not any more)
>> - and I believe one should stand to his promises
> 
> I don't know where this idea is coming from that it's not any more the
> case. I have not heard of any changes in that respect, the instructions
> are still the same: https://www.torproject.org/getinvolved/tshirt.html
> 
> You need to email tshirts@, include your fingerprints, and then wait
> weeks or months until the one poor person that is processing all the
> requests and all the requests from the campaign and also has other hats
> to get to it.
> 
> It's a thank you gift. I don't mean you, pa011, when I say this, but in
> general I would expect a bit more gratitude and understanding what it
> means to run a small understaffed organization. :(
> 
> Moritz
> ___
> 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

Re: [tor-relays] The t-shirt organization thingy

[pa011]

> Hi Moritz,
> 
> I do understand that it's hard to run an organization with too few
> people, it's my daily life working for staff at my university (I am the
> only administrator for 16 tablets, 34 laptops, 3 servers and 7
> thinclients, and we are not allowed to use centralized tools, I have to
> administrate all of these devices manually), so there are definitely all
> my "thank you"s I can give.
> 
> But I, for example, didn't even get an answer first, I would even love
> to get an automated email saying "Sorry if it takes a very long time, we
> are overwhelmed by the work we currently have to do" (waiting for almost
> 7 months now by the way). After 2-3 months I got an answer when we
> talked about that topic via this list in summer (though nothing official
> besides the mailing list talk). The problem is that only one person
> handles the shirts and it's ok even if I have to wait another 7 months
> or so (it's a gift at all, as you already said).
> 
> It's just that you/we/they should change something about the handling of
> the situation. It was (and for others most probably still is) the lack
> of communication that frustrates eligible relay operators so much.
> 
> But to conclude, thanks for all the work towards Tor and everything.
> Everybody has to give his work and support, so we can stand for free
> Internet (free as in freedom, not as in free beer). This was not meant
> to be against you, it was only in response to your mail because you got
> to this topic :)
> 
> Best,
> Michael


I agree with what you already expressed Michael.

On top of that I just want to remind on two mails back from June this year 
-obviously a time when the project was more focused on other issues - even 
there is and was volunteer help around:

>Date: Mon, 13 Jun 2016 22:07:26 +0200

>I would offer 2 helping hands and possibly more as well to get this and
>my own shirt out - please contact me

>Paul

>Am 08.06.2016 um 18:05 schrieb l3thal.inject...@gmail.com:
>> If tor weather isn't running, and tshirt emails aren't being sent out,
>> is someone doing this manually then? How can I help get the show on
>> the road? Not gonna lie, I was really looking forward to the tshirt
>> email as my relay definitely should have earned one about 2 weeks ago.
>> haha. Actually I just donated $100... maybe now I can get a tshirt?
>>
>> https://atlas.torproject.org/#details/1F45542A24A61BF9408F1C05E0DCE4E29F2CBA11
>> ___
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] The t-shirt organization thingy (was: Network scan results for CVE-2016-5696 / RFC5961)

[Michael Armbruster]

On 2016-12-11 at 22:50, Moritz Bartl wrote:
> You need to email tshirts@, include your fingerprints, and then wait
> weeks or months until the one poor person that is processing all the
> requests and all the requests from the campaign and also has other hats
> to get to it.
> 
> It's a thank you gift. I don't mean you, pa011, when I say this, but in
> general I would expect a bit more gratitude and understanding what it
> means to run a small understaffed organization. :(
> 
> Moritz

Hi Moritz,

I do understand that it's hard to run an organization with too few
people, it's my daily life working for staff at my university (I am the
only administrator for 16 tablets, 34 laptops, 3 servers and 7
thinclients, and we are not allowed to use centralized tools, I have to
administrate all of these devices manually), so there are definitely all
my "thank you"s I can give.

But I, for example, didn't even get an answer first, I would even love
to get an automated email saying "Sorry if it takes a very long time, we
are overwhelmed by the work we currently have to do" (waiting for almost
7 months now by the way). After 2-3 months I got an answer when we
talked about that topic via this list in summer (though nothing official
besides the mailing list talk). The problem is that only one person
handles the shirts and it's ok even if I have to wait another 7 months
or so (it's a gift at all, as you already said).

It's just that you/we/they should change something about the handling of
the situation. It was (and for others most probably still is) the lack
of communication that frustrates eligible relay operators so much.

But to conclude, thanks for all the work towards Tor and everything.
Everybody has to give his work and support, so we can stand for free
Internet (free as in freedom, not as in free beer). This was not meant
to be against you, it was only in response to your mail because you got
to this topic :)

Best,
Michael



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] ansible for tor relay ops

[pa011]

> 
>> Isn’t it somehow dangerous in the area we operate, to rely on a piece
>> of software created more or less by a single person?
> 
> Thanks for this question. Can you give a few examples for "dangerous" in
> the context of your question so I might be able to address your concerns
> more specifically?

That is exactly the point, if you know the danger in advance, there might be a 
change you can address and possibly handle it.

In this case, somebody like me would rely on a piece of software that he 
possible cant judge, or totally understand and there are not several people who 
might have had an eye on it,checked it and agreed, that there is no 
misbehaviour? Who are trusted people in this group, who are not and why? Who is 
giving a service for what reason? I don’t want to go more down is road ending 
up in paranoia but I am sure some of those thoughts get shared.

Yes one argument might be, there is a long track record, reputation for a 
person - difficult for newcomers to judge.

I cant be more specific and please don’t take it personally - these are just 
general thoughts...and every single question (if and when it may arise) could 
be cleared..

Thank you and regards
Paul



0xC8C330E7.asc
Description: application/pgp-keys
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Inconsistent BW measurements of unused relay

[teor]

> On 12 Dec. 2016, at 08:43, Rana  wrote:
> 
>>> 
>>> On 12 Dec. 2016, at 01:56, Rana  wrote:
>>> 
>>> OK Tim thanks for the answers, I appreciate your patience with me 
>>> [even though I "lack programming skills" :) ]
>>> 
>>> The one answer of yours that still does not make sense to me is that 
>>> arm actually means Kbytes/sec and not kbits/sec  when it writes Kb/s
>>> 
>>> I have arm reporting average  of at least several tens of Kb/s all the 
>>> time, and about 100 Kb/s most of the time,  and then I wind up with almost 
>>> constant 200 bit/sec actual average rate over 6 hours, based on the total 
>>> number of Mbytes sent that Tor reports in its log file. 
>>> 
>>> Even if the 200 bit/sec figure is somehow rounded to 8000 bit/ sec or 
>>> even 8000 bytes/sec as you suggested , this does not make sense…
>> 
>> Ok, so you didn't say that to start with, you seemed to be saying that it 
>> was constantly showing 100 kb/s.
>> 
>> Perhaps arm is displaying your maximum bandwidth over a certain time?
>> (I really don't now what bandwidth arm measures.)
> 
> I do not have a slightest freaking idea and this arm thing seems to have been 
> written by anarchists who thought that documentation was too bourgeois

Maybe you think this is clever snark.
But some people might not want to help you if you talk like that.

There is extensive documentation for arm and stem (the backend library
used by arm). It's some of the best documentation I've seen.

Here is the documentation for arm:
https://www.atagar.com/arm/

Here is the documentation for stem:
https://stem.torproject.org/index.html

In particular:
https://stem.torproject.org/api/descriptor/server_descriptor.html

• average_bandwidth (int) -- * average rate it's willing to relay in bytes/s
• burst_bandwidth (int) -- * burst rate it's willing to relay in bytes/s
• observed_bandwidth (int) -- * estimated capacity based on usage in bytes/s

And:
https://stem.torproject.org/api/descriptor/extrainfo_descriptor.html

• read_history_end (datetime) -- end of the sampling interval
• read_history_interval (int) -- seconds per interval
• read_history_values (list) -- bytes read during each interval
• write_history_end (datetime) -- end of the sampling interval
• write_history_interval (int) -- seconds per interval
• write_history_values (list) -- bytes written during each interval


T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[Moritz Bartl]

On 12/10/2016 09:52 PM, pa011 wrote:
>> btw, it would be awesome to give away t-shirts or something for running
>> diverse relays.
> that was a least a promise the year ago (its not any more)
> - and I believe one should stand to his promises

I don't know where this idea is coming from that it's not any more the
case. I have not heard of any changes in that respect, the instructions
are still the same: https://www.torproject.org/getinvolved/tshirt.html

You need to email tshirts@, include your fingerprints, and then wait
weeks or months until the one poor person that is processing all the
requests and all the requests from the campaign and also has other hats
to get to it.

It's a thank you gift. I don't mean you, pa011, when I say this, but in
general I would expect a bit more gratitude and understanding what it
means to run a small understaffed organization. :(

Moritz
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Draft Fallback Directory List

[teor]

> On 12 Dec. 2016, at 05:08, Andrew Deason  wrote:
> 
> On Sun, 11 Dec 2016 23:45:42 +1100
> teor  wrote:
> 
>> One or more of your relays have been selected as fallback directory
>> mirrors[0] for the next tor release. Please keep the relay available on
>> the same addresses, ports, and identity key (fingerprint) for the next
>> 2 years.
> 
> Does ipv6 connectivity matter at all for the purposes of being a
> fallback directory mirror? I can see of course it's not required, but
> I'm not sure if an ipv6 address would be used at all (as a directory
> mirror). That is, if I added a v6 addr to a relay in that list, would
> that help anything, or not yet?

It helps clients configured to use dual-stack IPv6:
ClientPreferIPv6ORPort 1

And clients configured to use IPv6 only:
ClientUseIPv4 0
UseMicrodescriptors 0

But as they are manual configs, not many clients use them yet.
We want to make dual-stack easier (even automatic) on clients, but we
need more IPv6 relays to preserve client privacy.

> I assume that adding a v6 address does not violate the "keep the same
> address/port/key for the next 2 years" requirement. Is that correct?

Yes, but you need to keep *both* addresses for 2 years after you add
IPv6. Let me know, and I'll add the IPv6 address to the fallback list.

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Inconsistent BW measurements of unused relay

[Rana]

> On 12 Dec. 2016, at 01:56, Rana  wrote:
> 
> OK Tim thanks for the answers, I appreciate your patience with me 
> [even though I "lack programming skills" :) ]
> 
> The one answer of yours that still does not make sense to me is that 
> arm actually means Kbytes/sec and not kbits/sec  when it writes Kb/s
> 
> I have arm reporting average  of at least several tens of Kb/s all the time, 
> and about 100 Kb/s most of the time,  and then I wind up with almost constant 
> 200 bit/sec actual average rate over 6 hours, based on the total number of 
> Mbytes sent that Tor reports in its log file. 
> 
> Even if the 200 bit/sec figure is somehow rounded to 8000 bit/ sec or 
> even 8000 bytes/sec as you suggested , this does not make sense…

Ok, so you didn't say that to start with, you seemed to be saying that it was 
constantly showing 100 kb/s.

Perhaps arm is displaying your maximum bandwidth over a certain time?
(I really don't now what bandwidth arm measures.)

T

I do not have a slightest freaking idea and this arm thing seems to have been 
written by anarchists who thought that documentation was too bourgeois

Rana

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Inconsistent BW measurements of unused relay

[teor]

> On 12 Dec. 2016, at 01:56, Rana  wrote:
> 
> OK Tim thanks for the answers, I appreciate your patience with me [even 
> though I "lack programming skills" :) ]
> 
> The one answer of yours that still does not make sense to me is that arm 
> actually means Kbytes/sec and not kbits/sec  when it writes Kb/s
> 
> I have arm reporting average  of at least several tens of Kb/s all the time, 
> and about 100 Kb/s most of the time,  and then I wind up with almost constant 
> 200 bit/sec actual average rate over 6 hours, based on the total number of 
> Mbytes sent that Tor reports in its log file. 
> 
> Even if the 200 bit/sec figure is somehow rounded to 8000 bit/ sec or even 
> 8000 bytes/sec as you suggested , this does not make sense…

Ok, so you didn't say that to start with, you seemed to be saying that
it was constantly showing 100 kb/s.

Perhaps arm is displaying your maximum bandwidth over a certain time?
(I really don't now what bandwidth arm measures.)

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] ansible for tor relay ops

[nusenu]

> You are quite often referring to Ansible which is new to me. Is there
> a permanent free version around to let your
> https://github.com/nusenu/ansible-relayor run on it?

Yes ansible is free software and you can install it with your preferred
package manager (depending what OS you use).

> Isn’t it somehow dangerous in the area we operate, to rely on a piece
> of software created more or less by a single person?

Thanks for this question. Can you give a few examples for "dangerous" in
the context of your question so I might be able to address your concerns
more specifically?

thanks,
nusenu



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Draft Fallback Directory List

[Andrew Deason]

On Sun, 11 Dec 2016 23:45:42 +1100
teor  wrote:

> One or more of your relays have been selected as fallback directory
> mirrors[0] for the next tor release. Please keep the relay available on
> the same addresses, ports, and identity key (fingerprint) for the next
> 2 years.

Does ipv6 connectivity matter at all for the purposes of being a
fallback directory mirror? I can see of course it's not required, but
I'm not sure if an ipv6 address would be used at all (as a directory
mirror). That is, if I added a v6 addr to a relay in that list, would
that help anything, or not yet?

I assume that adding a v6 address does not violate the "keep the same
address/port/key for the next 2 years" requirement. Is that correct?

-- 
Andrew Deason
adea...@dson.org
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Second relay on same ESX

[s7r]

Hello,

Thanks for running relays.


Patrick DERWAEL wrote:
> Hi guys,
> 
> I'm running a relay in a VM on a physical server which is largely under used
> Current advertised bandwidth 26MB, consensus 76500
> I'm considering running a second relay (2nd VM) on the very same
> hardware, but this brings a few questions:
> 
> - is there any issue running it at the same geographical place?

It desirable to have geographical diversity of course, but running two
in the same place to increase capacity doesn't do any harm. Just don't
forget to configure MyFamily in both torrcs so that the relays are
linked together as belonging to the same family.

> - would the current total BW effectively consumed (26MB) be divided in 2
> (i.e. no added value in BW)?

This depends on a lot of things. If your network port can handle more
than 26MB, and the limit of 26 MB observed on the first relay comes from
CPU/RAM, the 26 MB will not be divided but increased. If the first relay
has underused CPU / RAM this means the 26 MB is a limitation that comes
from the network port speed, and in this case it will be obviously divided.

> - basically, would it have any significant added value to the network?
> 
> Thanks
> 

Yes, if the bandwidth grows. If the 26 MB is divided in two, it's easier
and better to run a single one of 26 MB (save space in descriptors
distributed network wide, have a single box to maintain and keep up to
date, etc.)



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Second relay on same ESX

[John Ricketts]

Patrick,

I run all of my relays under VMware  and I don't have any issues at all.

How many CPUs do you have in the physical server and how many virtual CPUs do 
you have assigned to the VM?

John

On Dec 11, 2016, at 11:19, Patrick DERWAEL 
> wrote:

Hi guys,

I'm running a relay in a VM on a physical server which is largely under used
Current advertised bandwidth 26MB, consensus 76500
I'm considering running a second relay (2nd VM) on the very same hardware, but 
this brings a few questions:

- is there any issue running it at the same geographical place?
- would the current total BW effectively consumed (26MB) be divided in 2 (i.e. 
no added value in BW)?
- basically, would it have any significant added value to the network?

Thanks



___
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] Second relay on same ESX

[Patrick DERWAEL]

Hi guys,

I'm running a relay in a VM on a physical server which is largely under used
Current advertised bandwidth 26MB, consensus 76500
I'm considering running a second relay (2nd VM) on the very same hardware,
but this brings a few questions:

- is there any issue running it at the same geographical place?
- would the current total BW effectively consumed (26MB) be divided in 2
(i.e. no added value in BW)?
- basically, would it have any significant added value to the network?

Thanks
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Inconsistent BW measurements of unused relay

[Rana]

OK Tim thanks for the answers, I appreciate your patience with me [even though 
I "lack programming skills" :) ]

The one answer of yours that still does not make sense to me is that arm 
actually means Kbytes/sec and not kbits/sec  when it writes Kb/s

I have arm reporting average  of at least several tens of Kb/s all the time, 
and about 100 Kb/s most of the time,  and then I wind up with almost constant 
200 bit/sec actual average rate over 6 hours, based on the total number of 
Mbytes sent that Tor reports in its log file. 

Even if the 200 bit/sec figure is somehow rounded to 8000 bit/ sec or even 8000 
bytes/sec as you suggested , this does not make sense...

Rana

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Inconsistent BW measurements of unused relay

[teor]

> On 12 Dec. 2016, at 00:08, Rana  wrote:
> 
>>> On 10 Dec. 2016, at 07:12, Rana  wrote:
>>> 
>>> My relay remains severely under-used. One thing that bothers me are 
>>> inconsistent bandwidth measurements. Here they are: 
>>> Atlas “advertised” (which is actually supposed to be “measured”?:   100 
>>> KB/s = ~ 800,000 bit/s
>> 
>> This is the minimum of:
>> * the bandwidth rate,
>> * the bandwidth burst, and
>> * the observed bandwidth (the maximum bandwidth your relay has recently
>> sustained over a 10 second period).
>> * the consensus weight, converted to a bandwidth figure (I think?).
>> 
>> If you hover over the figure in atlas, it will break it down for you.
> 
> Thanks for the tip. It says it is the actually measured bandwidth

This is the "Advertised Bandwidth".

It is the minimum of 3 (or 4) different bandwidths your relay
advertises it can handle.

Some of these are measured at your relay as a 10-second sustained
maximum. Others are taken from the configuration.

>>> “I have sent” reported in Tor log: on the average pretty stable 17 mbytes 
>>> every 6 hours =   ~ 200 bit/s
>> 
>> This is what your relay has actually sent.
> 
> Totally inconsistent with the rest
> 
>>> Atlas graphs:  1 Kbytes/s  on the average   
>>>~ 8,000 
>>> bit/s
>> 
>> This is the value that your relay reports it has sent.
>> It is rounded and averaged to preserve client privacy.
> 
> This is not consistent with the 200 bit/s figure. Do you mean to say that 
> Atlas rounds 200 bps on the average to 8000 bps on the average?

This is the "Bandwidth History".

These are measured at your relay over 10-second periods, then averaged
over a few hours, then rounded to the nearest kilobyte.

Since a relay's reported bandwidth history is rounded to kilobytes per
second, you will only see figures in multiples of 8192 bps.

>>> Consensus BW: 26 =  
>>> 
>>>  ~ 26,000 bit/s
> 
>> This is the low-median of the measurements of the 5 bandwidth authorities. 
>> It is a dimensionless figure that only makes sense when compared with other 
>> relay consensus weights.
> 
> Can't comment because I have no idea what the formula is, therefore this 
> figure is meaningless to me.

This is the "Consensus Weight", based on the measured bandwidth.

Your relay is measured at random times and in random pairings with other
relays, from 5 different tor clients around the US and western Europe.

Then these measurements are averaged, scaled according to the ratio
between your relay's reported bandwidth and measured bandwidth, and
then the low-median (3rd highest out of 5) is used as the measurement.

If that doesn't make sense, don't worry about the details.

>>> Average upload bw reported by arm: 100 kb/s =   
>>>   ~ 100,000 bit/s
> 
>> I suspect this is actually kilobytes, and is the same as the atlas figure. 
>> (They use the same backend library.)
> 
> This would not be consistent at all with actual reported upload of 17 mbytes 
> in 6 hours which as I said is pretty constant. The ~100 Kb/s average bit rate 
> figure reported by arm lingers for HOURS. This rate,s 17 MB would have been 
> sent in THREE MINUTES. If the rate were 100 kbyte/s as you suggest then it 
> would take the relay 22 SECONDS to send what it claims it is sending in 6 
> hours.

This is the "Advertised Bandwidth".
It is the same one displayed by Atlas.
But it should probably have a capital "B" in "Bps".

>>> Makes zero sense.
> 
> Still doesn't. Why do Tor and Tor-related projects such as arm  publish all 
> these TOTALLY inconsiostent figures? If they want to confuse the adversaries 
> I doubt that it worked, but they sure as hell were highly successful in 
> confusing me :)

It seems to me that you want everything containing the word "bandwidth"
to have the same value. But they are measured over different times and
at different places, so they are never going to be the same.

Have you tried checking the bandwidth of your connection to servers
located in 5 different countries?

I bet you get 5 different answers.

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Inconsistent BW measurements of unused relay

[Rana]

>> On 10 Dec. 2016, at 07:12, Rana  wrote:
>> 
>> My relay remains severely under-used. One thing that bothers me are 
>> inconsistent bandwidth measurements. Here they are: 
>> Atlas “advertised” (which is actually supposed to be “measured”?:   100 KB/s 
>> = ~ 800,000 bit/s
>
>This is the minimum of:
>* the bandwidth rate,
>* the bandwidth burst, and
>* the observed bandwidth (the maximum bandwidth your relay has recently
> sustained over a 10 second period).
>* the consensus weight, converted to a bandwidth figure (I think?).
>
>If you hover over the figure in atlas, it will break it down for you.

Thanks for the tip. It says it is the actually measured bandwidth

>
>> “I have sent” reported in Tor log: on the average pretty stable 17 mbytes 
>> every 6 hours =   ~ 200 bit/s
>
>This is what your relay has actually sent.

Totally inconsistent with the rest

>> Atlas graphs:  1 Kbytes/s  on the average
>>   ~ 8,000 
>> bit/s
>
>This is the value that your relay reports it has sent.
>It is rounded and averaged to preserve client privacy.

This is not consistent with the 200 bit/s figure. Do you mean to say that Atlas 
rounds 200 bps on the average to 8000 bps on the average?

>> Consensus BW: 26 =   
>>  
>>~ 26,000 bit/s

>This is the low-median of the measurements of the 5 bandwidth authorities. It 
>is a dimensionless figure that only makes sense when compared with other relay 
>consensus weights.

Can't comment because I have no idea what the formula is, therefore this figure 
is meaningless to me.


>> Average upload bw reported by arm: 100 kb/s =
>>  ~ 100,000 bit/s

>I suspect this is actually kilobytes, and is the same as the atlas figure. 
>(They use the same backend library.)

This would not be consistent at all with actual reported upload of 17 mbytes in 
6 hours which as I said is pretty constant. The ~100 Kb/s average bit rate 
figure reported by arm lingers for HOURS. This rate,s 17 MB would have been 
sent in THREE MINUTES. If the rate were 100 kbyte/s as you suggest then it 
would take the relay 22 SECONDS to send what it claims it is sending in 6 hours.

>> Makes zero sense.

Still doesn't. Why do Tor and Tor-related projects such as arm  publish all 
these TOTALLY inconsiostent figures? If they want to confuse the adversaries I 
doubt that it worked, but they sure as hell were highly successful in confusing 
me :)


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Draft Fallback Directory List

[teor]

(This is a copy of the email I BCC'd to each relay operator on the draft
fallback directory list. Please email me to add your relays.)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Tor Relay Operator,

One or more of your relays have been selected as fallback directory
mirrors[0] for the next tor release. Please keep the relay available on
the same addresses, ports, and identity key (fingerprint) for the next
2 years.

This is a draft list.[3] I can make changes for the next week. Next
weekend, I will send another email to those operators whose relays have
been added or removed. (Otherwise, you're on the list.)

We are taking 3 relays per operator, if you only have 1 or 2 on the list,
please email me to add more.

Wondering why your relay didn't make the list?
Search the selection log[4] for its fingerprint.

If the log says:
* in neither blacklist nor whitelist,
email me to add your relay.
(I run a script that checks relays, then outputs a list.)

If it says:
* not a candidate: version delivers stale consensuses,
* not a candidate: version not recommended,
* not a candidate: changed address/port recently
(on 0.2.7.6 or earlier), or
* outdated consensus,
upgrade to 0.2.8.9 or later, or 0.2.9.5-alpha or later.

If it says:
* bandwidth too low,
* download too slow,
* HTTP Error 503: Directory busy,
* or some sort of download connection error,
it might help to give your relay more memory or bandwidth.
(And please make sure it's still running!)

If it says:
* not a candidate: changed address/port recently,
* not a candidate: guard avg too low,
* not a candidate: running avg too low, or
* not a candidate: v2dir avg too low,
your relay needs to be consistently up with high bandwidth to help
clients. Try keeping it stable for 6-12 months, and it might be selected
next time.

But don't worry, your relay(s) are still helping the tor network, even
if they are not selected as a fallback.

Tim

[0]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
[3]: 
https://trac.torproject.org/projects/tor/attachment/ticket/18828/draft_fallback_dirs_20161210_1121_2594b7b
   (or [8] if you want to see what the git commit will look like)
[4]: 
https://trac.torproject.org/projects/tor/attachment/ticket/18828/draft_fallback_dirs_20161210_1121_2594b7b.log
[8]: 
https://github.com/teor2345/tor/blob/new-fallbacks-028-v2/src/or/fallback_dirs.inc

From: teor 
Subject: Call for Tor Fallback Directories
Date: 4 December 2016 at 21:44:39 AEDT
To: tor-relays@lists.torproject.org

Dear Tor Relay Operator,

Your relay(s) can help tor clients find the tor network by becoming a
fallback directory mirror.[0]

These mirrors are hard-coded into tor's source code, like the directory
authorities. We have 80 fallbacks, but we want 200 for the next release.

Fallbacks need to have:
- - the same IP address(es) and ports for the next 2 years,
- - the same relay identity key for the next 2 years,
- - good uptime (at least 95%), and
- - good bandwidth and network connectivity
(we estimate an extra 25GB per month).

Please email me to add your relays that fit these criteria to the list.
If you are BCC'd on this email, it looks like you have at least one
relay that could become a fallback.
You can also email me if you know your relay will be changing address
or key, and I'll make sure we don't choose it.

We are keeping the fallback lists from the last release[1][2].

So if you have emailed me before about becoming a fallback, there is no
need to email again. But please let me know if your relay details have
changed.  (I did not BCC relay operators who are already on the fallback
lists, unless their relay details changed.)

In a week or two, I will run a script to select the hard-coded list for
the release.

If you're interested, here's some background to this request:

The latest list[3] and log[4] of candidates was generated using the
instructions in [5] from scripts/maint/updateFallbackDirs.py on my
GitHub branch[6]. (This branch has some bug fixes compared to what's in
master.) We're tracking this work in [7].

(links updated to the latest code and relay list)
[0]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
[1]: 
https://github.com/teor2345/tor/blob/fallbacks-201612-v4/scripts/maint/fallback.whitelist
[2]: 
https://github.com/teor2345/tor/blob/fallbacks-201612-v4/scripts/maint/fallback.blacklist
[3]: 
https://trac.torproject.org/projects/tor/attachment/ticket/18828/draft_fallback_dirs_20161210_1121_2594b7b
[4]: 
https://trac.torproject.org/projects/tor/attachment/ticket/18828/draft_fallback_dirs_20161210_1121_2594b7b.log
[5]: 
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrors
[6]: 
https://github.com/teor2345/tor/blob/fallbacks-201612-v4/scripts/maint/updateFallbackDirs.py
[7]: https://trac.torproject.org/projects/tor/ticket/18828

T
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

Re: [tor-relays] Inconsistent BW measurements of unused relay

[teor]

> On 10 Dec. 2016, at 07:12, Rana  wrote:
> 
> My relay remains severely under-used. One thing that bothers me are 
> inconsistent bandwidth measurements. Here they are:
>  
>  
> Atlas “advertised” (which is actually supposed to be “measured”?:   100 KB/s 
> = ~ 800,000 bit/s

This is the minimum of:
* the bandwidth rate,
* the bandwidth burst, and
* the observed bandwidth (the maximum bandwidth your relay has recently
  sustained over a 10 second period).
* the consensus weight, converted to a bandwidth figure (I think?).

If you hover over the figure in atlas, it will break it down for you.

> “I have sent” reported in Tor log: on the average pretty stable 17 mbytes 
> every 6 hours =   ~ 200 bit/s

This is what your relay has actually sent.

> Atlas graphs:  1 Kbytes/s  on the average 
>  ~ 8,000 bit/s

This is the value that your relay reports it has sent.
It is rounded and averaged to preserve client privacy.

> Consensus BW: 26 =
>   
>  ~ 26,000 bit/s

This is the low-median of the measurements of the 5 bandwidth
authorities. It is a dimensionless figure that only makes sense when
compared with other relay consensus weights.

(It is not measured in kilobytes per second, although since the input
values are kilobytes per second, it can sometimes be comparable.)

> Average upload bw reported by arm: 100 kb/s = 
> ~ 100,000 bit/s

I suspect this is actually kilobytes, and is the same as the atlas
figure. (They use the same backend library.)

> Makes zero sense.

Yes, it can be very confusing.
Each of these figures measures a different thing.
They are made for different purposes.

Other than that, I'll repeat what I said the last time you asked this
question, in:
https://lists.torproject.org/pipermail/tor-relays/2016-December/01.html

> I don't know your relay's fingerprint, so I can only repeat the
> general advice I have given others with similar questions:
> 
> https://lists.torproject.org/pipermail/tor-relays/2016-November/010913.html
> https://lists.torproject.org/pipermail/tor-relays/2016-November/010928.html
> https://lists.torproject.org/pipermail/tor-relays/2016-November/010916.html

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Inconsistent BW measurements of unused relay

[Rana]

My relay remains severely under-used. One thing that bothers me are
inconsistent bandwidth measurements. Here they are:
 
 
Atlas "advertised" (which is actually supposed to be "measured"?:   100 KB/s
= ~ 800,000 bit/s
"I have sent" reported in Tor log: on the average pretty stable 17 mbytes
every 6 hours =   ~ 200 bit/s
Atlas graphs:  1 Kbytes/s  on the average
~ 8,000 bit/s
Consensus BW: 26 =
~ 26,000 bit/s
Average upload bw reported by arm: 100 kb/s =
~ 100,000 bit/s
 
Makes zero sense.
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays