Full bandwidth is not used.
Paul Menzel
paulepanter at users.sourceforge.net
Fri Mar 12 10:40:29 UTC 2010
Am Dienstag, den 09.03.2010, 14:01 +0100 schrieb Paul Menzel:
> Am Dienstag, den 09.03.2010, 07:40 -0500 schrieb andrew at torproject.org:
> > On Mon, Mar 08, 2010 at 10:21:29AM +0100, paulepanter at users.sourceforge.net wrote 1.6K bytes in 52 lines about:
> > : I now increased the RAM too and restarted the server to no avail. It is
> > : still below 100 KB/s.
> >
> > What is the network configuration?
>
> $ more /etc/tor/torrc
> SocksPort 0 # what port to open for local application
> connections
> ControlPort 9051
> ORPort 443
> ORListenAddress 0.0.0.0:9090
> Address 62.141.42.186
> ContactInfo 1024D/6C0E1D58 Paul Menzel <paul at gw90.de>
> DirPort 80 # what port to advertise for directory connections
> DirListenAddress 0.0.0.0:9091
I implemented the changes suggested by arma on IRC (due to Exit and
Guard flag [1]) to configure my server as non-exit relay, so I added the
following line.
ExitPolicy reject *:*
> It is a virtual machine and connections to port 80 and 443 are forwarded
> by an IPtables entry in the nat table with DNAT to the virtual host. On
> the virtual host using IPtables ports 80 and 443 are forwarded to 9090
> and 9091.
>
> Sebastian on IRC helped me to gather more data. In `cached-descriptors`
> I have the following.
>
> bandwidth 5242880 10485760 155910
>
> There are more entries for my IP address when I restarted and upgraded
> Tor.
>
> In `cached-consensus` (from 12:28 UTC) there is
>
> r anonymisierungsdien s+wb9df31yS6Y02Rvl0i0tenAWA vyRDgH2XTP6Tn1MPiJkWE0Yk9e8 2010-03-08 18:05:07 62.141.42.186 443 80
> s Exit Fast HSDir Running Stable V2Dir Valid
> v Tor 0.2.1.23
> w Bandwidth=61
> p reject 25,119,135-139,445,563,1214,4661-4666,6346-6429,6699,6881-6999
>
> and Bandwidth even decreased by 1 (from 62) compared to the value before
> the update (11:14 UTC).
Unfortunately changing the server to a non-exit relay on 2010-03-10
09:28:25 UTC did not change anything. Although looking at my logs and
the data on [2] I would say it differs a bit. According to my logs I
would say, that traffic even decreased.
$ grep -A 6 "62.141.42.186" cached-descriptors | grep -E 'published|bandwidth'
published 2010-03-07 17:51:12
bandwidth 5242880 10485760 55006
published 2010-03-08 00:05:02
bandwidth 5242880 10485760 155910
$ grep -A 6 "62.141.42.186" cached-descriptors | grep bandwidth
bandwidth 5242880 10485760 214272
bandwidth 5242880 10485760 141962
$ LANG=C date && grep -A 6 "62.141.42.186" cached-descriptors | grep bandwidth
Thu Mar 11 10:30:02 UTC 2010
bandwidth 5242880 10485760 181555
$ LANG=C date && grep -A 6 "62.141.42.186" cached-descriptors | grep -E 'published|bandwidth'
Fri Mar 12 09:46:43 UTC 2010
published 2010-03-10 09:28:24
bandwidth 5242880 10485760 181555
published 2010-03-11 03:28:50
bandwidth 5242880 10485760 178964
published 2010-03-11 21:29:37
bandwidth 5242880 10485760 143546
The value displayed on [2] seems to be more up to date.
Here are some compiled values from `cached-consensus`.
$ grep -A4 62.141.42 cached-consensus # adapted the output.
r anonymisierungsdien s+wb9df31yS6Y02Rvl0i0tenAWA QvLgYWR3HuX0DKMSPBCwzjIVpCk 2010-03-09 12:05:55 62.141.42.186 443 80
s Exit Fast HSDir Running Stable V2Dir Valid
w Bandwidth=63
$ ls -al (adapted)
384600 9. Mär 21:27 cached-consensus
w Bandwidth=102
362245 9. Mär 23:15 cached-consensus
w Bandwidth=90
342063 10. Mär 07:32 cached-consensus
w Bandwidth=88
# (configure as non-exit relay)
356455 10. Mär 11:14 cached-consensus
w Bandwidth=86
385656 10. Mär 21:16 cached-consensus
w Bandwidth=81
w Bandwidth=64
390325 11. Mär 20:03 cached-consensus
w Bandwidth=58
Thu Mar 11 20:21:07 UTC 2010
w Bandwidth=58
anonymisierungsdien s+wb9df31yS6Y02Rvl0i0tenAWA BfwbPy3Xd3P2smQnEdl3Tqp9E9I 2010-03-11 21:29:37 62.141.42.186 443 80
w Bandwidth=52
r anonymisierungsdien s+wb9df31yS6Y02Rvl0i0tenAWA BfwbPy3Xd3P2smQnEdl3Tqp9E9I 2010-03-11 21:29:37 62.141.42.186 443 80
w Bandwidth=52
Do you have more ideas?
Thanks,
Paul
[1] http://archives.seul.org/or/talk/Jan-2010/msg00175.html
[2] http://trunk.torstatus.kgprog.com/router_detail.php?FP=b3ec1bf5d7f7d724ba634d91be5d22d2d7a70160
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20100312/0bfb754f/attachment.pgp>
More information about the tor-talk
mailing list