[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Full bandwidth is not used.
On Fri, 12 Mar 2010 11:40:29 +0100 Paul Menzel
<paulepanter@xxxxxxxxxxxxxxxxxxxxx> wrote:
>Am Dienstag, den 09.03.2010, 14:01 +0100 schrieb Paul Menzel:=20
>> Am Dienstag, den 09.03.2010, 07:40 -0500 schrieb andrew@xxxxxxxxxxxxxx:
>> > On Mon, Mar 08, 2010 at 10:21:29AM +0100, paulepanter@xxxxxxxxxxxxxxxxx=
>.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.
>> >=20
>> > What is the network configuration?
>>=20
>> $ 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@xxxxxxx>
>> 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.
>>=20
>> Sebastian on IRC helped me to gather more data. In `cached-descriptors`
>> I have the following.
>>=20
>> bandwidth 5242880 10485760 155910
>>=20
>> There are more entries for my IP address when I restarted and upgraded
>> Tor.
>>=20
>> In `cached-consensus` (from 12:28 UTC) there is
>>=20
>> r anonymisierungsdien s+wb9df31yS6Y02Rvl0i0tenAWA vyRDgH2XTP6Tn1M=
>PiJkWE0Yk9e8 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=3D61
>> p reject 25,119,135-139,445,563,1214,4661-4666,6346-6429,6699,688=
>1-6999
>>=20
>> 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=3DC date && grep -A 6 "62.141.42.186" cached-descriptors | g=
>rep bandwidth
> Thu Mar 11 10:30:02 UTC 2010
> bandwidth 5242880 10485760 181555
> $ LANG=3DC date && grep -A 6 "62.141.42.186" cached-descriptors | g=
>rep -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 QvLgYWR3HuX0DKMSP=
>BCwzjIVpCk 2010-03-09 12:05:55 62.141.42.186 443 80
> s Exit Fast HSDir Running Stable V2Dir Valid
> w Bandwidth=3D63
> $ ls -al (adapted)
> 384600 9. M=C3=A4r 21:27 cached-consensus
> w Bandwidth=3D102
> 362245 9. M=C3=A4r 23:15 cached-consensus
> w Bandwidth=3D90
> 342063 10. M=C3=A4r 07:32 cached-consensus
> w Bandwidth=3D88
> # (configure as non-exit relay)
> 356455 10. M=C3=A4r 11:14 cached-consensus
> w Bandwidth=3D86
> 385656 10. M=C3=A4r 21:16 cached-consensus
> w Bandwidth=3D81
> w Bandwidth=3D64
> 390325 11. M=C3=A4r 20:03 cached-consensus
> w Bandwidth=3D58
> Thu Mar 11 20:21:07 UTC 2010
> w Bandwidth=3D58
> anonymisierungsdien s+wb9df31yS6Y02Rvl0i0tenAWA BfwbPy3Xd3P2smQnEdl=
>3Tqp9E9I 2010-03-11 21:29:37 62.141.42.186 443 80
> w Bandwidth=3D52
> r anonymisierungsdien s+wb9df31yS6Y02Rvl0i0tenAWA BfwbPy3Xd3P2smQnE=
>dl3Tqp9E9I 2010-03-11 21:29:37 62.141.42.186 443 80
> w Bandwidth=3D52
>
>Do you have more ideas?
>
Well, as I've pointed out in the past, the values in cached-consensus
do *not* accurately reflect either the traffic load that your relay has
carried or the traffic capacity of your relay. They are bogus a priori and
should be ignored in attempting to ascertain your relay's actual loads.
The sad thing is that recent versions of tor clients now use the consensus
values for designing routes for circuits they will build, so the bogus
values produce load distortions throughout the tor network. However, that
fact has no bearing upon the numbers you're looking for.
If you want to know the loads that your relay has carried, you should
look at the byte counts for reads and writes in the extrainfo documents or,
alternatively, the state file. (The difficulty with using the state file
is that it gets updated everytime construction of a new circuit succeeds,
so the values for the most recent time periods change frequently and at
rather unpredictable intervals. If you always ignore the most recent time
period for read and for writes, then the state file becomes more usable
for this purpose.) If, OTOH, you want to know the peak "10-second burst"
rate, then the value to trust is the one in your relay's descriptors that
appear in the cached-descriptors{,.new} files.
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at cs.niu.edu *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk in the body. http://archives.seul.org/or/talk/