On 27/10/16 00:15, teor wrote:
>
>> On 27 Oct. 2016, at 00:32, D. S. Ljungmark wrote:
>>
>> On tis, 2016-10-25 at 22:52 +1100, teor wrote:
On 25 Oct. 2016, at 22:26, D.S. Ljungmark
wrote:
So, Now I've taken some steps to adjust the state of the relay, and
try to b
> On 27 Oct. 2016, at 00:32, D. S. Ljungmark wrote:
>
> On tis, 2016-10-25 at 22:52 +1100, teor wrote:
>>>
>>> On 25 Oct. 2016, at 22:26, D.S. Ljungmark
>>> wrote:
>>>
>>> So, Now I've taken some steps to adjust the state of the relay, and
>>> try to balance this.
>>>
>>> To reiterate a poin
On ons, 2016-10-26 at 15:32 +0200, D. S. Ljungmark wrote:
> On tis, 2016-10-25 at 22:52 +1100, teor wrote:
> >
> > >
> > >
> > > On 25 Oct. 2016, at 22:26, D.S. Ljungmark
> > > wrote:
> > >
> > > So, Now I've taken some steps to adjust the state of the relay,
> > > and
> > > try to balance thi
On tis, 2016-10-25 at 22:52 +1100, teor wrote:
> >
> > On 25 Oct. 2016, at 22:26, D.S. Ljungmark
> > wrote:
> >
> > So, Now I've taken some steps to adjust the state of the relay, and
> > try to balance this.
> >
> > To reiterate a point previously, before I start adding more tor
> > daemons o
On tis, 2016-10-25 at 13:34 +0200, Volker Mink wrote:
> Apart from your topic - what kind of internet connection do you use?
> :D
Gigabit dedicated fiber.
//D.S.
signature.asc
Description: This is a digitally signed message part
___
tor-relays mailing
On Tue, Oct 25, 2016 at 13:26:25 +0200, D.S. Ljungmark wrote:
> So far, I'm not sure _why_ it's capping itself on bandwidth, and
> that's the one thing that I want to figure out before I start scaling
> out horizontally.
>
Performance of relays can be a mystery and hard to figure out.
For exampl
> On 25 Oct. 2016, at 22:26, D.S. Ljungmark wrote:
>
> So, Now I've taken some steps to adjust the state of the relay, and
> try to balance this.
>
> To reiterate a point previously, before I start adding more tor
> daemons or servers to this, I want to know how to scale and optimise
> what is
Apart from your topic - what kind of internet connection do you use? :D
Gesendet: Dienstag, 25. Oktober 2016 um 13:26 Uhr
Von: "D.S. Ljungmark"
An: tor-relays@lists.torproject.org
Betreff: Re: [tor-relays] Rampup speed of Exit relay
So, Now I've taken some steps to adjust t
So, Now I've taken some steps to adjust the state of the relay, and
try to balance this.
To reiterate a point previously, before I start adding more tor
daemons or servers to this, I want to know how to scale and optimise
what is already there.
- Set up unbound in cache mode rather than use our
> > > > > So, how do we get tor to move past 100-200Mbit? Is it just a
> > > > > waiting game?
>> >
>> > I'd say just run more instances if you still have resources left and
>> > want to contribute more bw.
>> > (obviously also your exit policy influences on how much your instance
>> > is
> On 22 Sep 2016, at 11:55, Dennis Ljungmark wrote:
>
> On Thu, Sep 22, 2016 at 6:30 PM, teor wrote:
>> ...
>>
Have you considered configuring an IPv6 ORPort as well?
(It's unlikely to affect traffic, but it will help clients that
prefer IPv6.)
>>>
>>> Not sure right now, I've
On Thu, Sep 22, 2016 at 6:30 PM, teor wrote:
> Hi,
>
> I wanted to highlight the following parts of my reply:
>
> The Tor network is quite happy to allocate around 47 MByte/s (yes, 376
> MBit/s) to your relay based on its bandwidth measurements, but it won't do
> that until your relay shows it i
Hi,
I wanted to highlight the following parts of my reply:
The Tor network is quite happy to allocate around 47 MByte/s (yes, 376 MBit/s)
to your relay based on its bandwidth measurements, but it won't do that until
your relay shows it is actually capable of sustaining that traffic over a
10-s
> On 22 Sep 2016, at 04:40, D. S. Ljungmark wrote:
>
> On tor, 2016-09-22 at 12:08 +0200, Aeris wrote:
>>>
>>> Scaling up on more hardware is always an option, but I really want
>>> to
>>> push the limit of the exit node, as the others won't be exits
>>> (Local
>>> network design, really) , and
On tor, 2016-09-22 at 12:08 +0200, Aeris wrote:
> >
> > Scaling up on more hardware is always an option, but I really want
> > to
> > push the limit of the exit node, as the others won't be exits
> > (Local
> > network design, really) , and exit traffic is always more
> > interesting.
>
> When I
On tor, 2016-09-22 at 06:29 +1000, teor wrote:
> >
> > On 22 Sep 2016, at 05:41, nusenu wrote:
> >
> > >
> > > >
> > > > >
> > > > > So, how do we get tor to move past 100-200Mbit? Is it just a
> > > > > waiting game?
> >
> > I'd say just run more instances if you still have resources left
>
> Scaling up on more hardware is always an option, but I really want to
> push the limit of the exit node, as the others won't be exits (Local
> network design, really) , and exit traffic is always more
> interesting.
When I say another instance, it’s on the same hardware.
Because Tor is not fully
D. S. Ljungmark:
>> You have to start another Tor instance to use a little more your CPU
>> > (1 other
>> > core) and so to drain additionnal 150-300Mbps.
>
> Scaling up on more hardware is always an option, but I really want to
> push the limit of the exit node, as the others won't be exits (L
On ons, 2016-09-21 at 17:29 +0200, Aeris wrote:
> >
> > 17 MBytes/s in each direction.
>
> From Atlas graph, your node is currently growing up, so wait few
> weeks more to
> have the real bandwidth consumption, but don’t expect huge change.
It looks as if it stabilized a while ago, and I see mo
> On 22 Sep 2016, at 05:41, nusenu wrote:
>
So, how do we get tor to move past 100-200Mbit? Is it just a waiting game?
>
> I'd say just run more instances if you still have resources left and
> want to contribute more bw.
> (obviously also your exit policy influences on how much your insta
>>> So, how do we get tor to move past 100-200Mbit? Is it just a waiting game?
I'd say just run more instances if you still have resources left and
want to contribute more bw.
(obviously also your exit policy influences on how much your instance is
used)
>> How long has the relay been up?
>
> 4
> 17 MBytes/s in each direction.
From Atlas graph, your node is currently growing up, so wait few weeks more to
have the real bandwidth consumption, but don’t expect huge change.
17M*B*ps is 140M*b*ps and you already have a good relay :)
This is around the speed expected for standard CPU (150 to
On 21/09/16 15:24, teor wrote:
>
>> On 21 Sep 2016, at 20:01, D.S. Ljungmark wrote:
>>
>> Hi all,
>>
>> I'm looking at some traffic patterns for my Exit relay, and I'm frankly
>> a bit disappointed with the utilization.
>>
>> Currently it's running at a load average of 0.3-0.5, and CPU idle at
> On 21 Sep 2016, at 20:01, D.S. Ljungmark wrote:
>
> Hi all,
>
> I'm looking at some traffic patterns for my Exit relay, and I'm frankly
> a bit disappointed with the utilization.
>
> Currently it's running at a load average of 0.3-0.5, and CPU idle at
> 70-80%.
>
>
> We're not limited on
In short, yes.
On Sep 21, 2016 5:02 AM, "D.S. Ljungmark" wrote:
> Hi all,
>
> I'm looking at some traffic patterns for my Exit relay, and I'm frankly
> a bit disappointed with the utilization.
>
> Currently it's running at a load average of 0.3-0.5, and CPU idle at
> 70-80%.
>
>
> We're not li
Hi all,
I'm looking at some traffic patterns for my Exit relay, and I'm frankly
a bit disappointed with the utilization.
Currently it's running at a load average of 0.3-0.5, and CPU idle at
70-80%.
We're not limited on Bandwidth (tests show that our max cap is more than
safe to produce), yet,
26 matches
Mail list logo
