> On 16 Sep 2016, at 07:58, Ralph Seichter wrote:
>
> I have made some measurements. Downloading large files through Tor did
> not appear to show significant differences between both nodes, which
> could mean that Tor clients are either capped in general or the circuits
> were overall not fast e
I have made some measurements. Downloading large files through Tor did
not appear to show significant differences between both nodes, which
could mean that Tor clients are either capped in general or the circuits
were overall not fast enough to make my nodes reach their limits.
I also tried severa
On 15.09.16 21:21, Green Dream wrote:
> The Advertised Bandwidth is is significantly lower on TorRelay02HORUS
> too.
Indeed, even though bandwitdh settings are identical on both nodes:
BandwidthRate 96 MBytes
BandwidthBurst 112 MBytes
Arm shows me that node #1 has upload/download of around
The Advertised Bandwidth is is significantly lower on TorRelay02HORUS
too. Let me quote teor from another recent thread, I think the same
info is helpful here:
-- begin quote --
Your relay reports a bandwidth based on the amount of traffic it has
sustained in any 10 second period over the past da
On 15.09.16 20:57, Roman Mamedov wrote:
> You should post both fingerprint or even just Atlas links directly,
> maybe someone will have more ideas on why this could happen.
1)
https://atlas.torproject.org/#details/0C3D5E19E3C75B505C8ACD26F89DCA2DF970553E
2)
https://atlas.torproject.org/#details
On Thu, 15 Sep 2016 20:34:54 +0200
Ralph Seichter wrote:
> On 15.09.16 19:43, Roman Mamedov wrote:
>
> > It is normal to run multiple nodes in one family and have most or all
> > of them get the Guard flag.
>
> I don't see this happen. I would think that weeks of uninterrupted
> uptime should m
On 15.09.16 19:43, Roman Mamedov wrote:
> It is normal to run multiple nodes in one family and have most or all
> of them get the Guard flag.
I don't see this happen. I would think that weeks of uninterrupted
uptime should mean both nodes qualify, but only one has a guard flag.
The nodes are on s
I think he meant that it will not get the flag the same time. I set up
some relays and the "lifetime of a relay" is a nice indicator but
relays behave different. One relay needed 14 days to be stable and I
am 100% sure that the server and network was online 24/7. Just wait
and see :)
Markus
2016
On Thu, 15 Sep 2016 19:39:07 +0200
Ralph Seichter wrote:
> On 15.09.2016 18:40, Markus Koch wrote:
>
> > 100% normal. Welcome to tor.
> > No, no clue why ;)
>
> I was contemplating possible security considerations behind this. One
> particular person or organization responsible for the adminis
On 15.09.2016 18:40, Markus Koch wrote:
> 100% normal. Welcome to tor.
> No, no clue why ;)
I was contemplating possible security considerations behind this. One
particular person or organization responsible for the administration of
multiple guards, when guards are sensitive because users conne
100% normal. Welcome to tor.
No, no clue why ;)
Markus
Sent from my iPad
> On 15 Sep 2016, at 18:12, Ralph Seichter wrote:
>
> When running two non-exit nodes, configured as a single family with no
> other members, and using identical bandwidth settings, is it to be
> expected that only one o
When running two non-exit nodes, configured as a single family with no
other members, and using identical bandwidth settings, is it to be
expected that only one of the nodes ever obtains the guard flag? The
node uptimes are pretty much the same as well, but consensus weight
differs significantly. I
12 matches
Mail list logo
