logs archiveIRC Archive / Oftc / #tor / 2009 / December / 31 / 1
fabi
The problem seem to lie elsewhere
seems like he's not looking at the newest scan, although there is one. interesting
Sebastian
you could try removing the stale scan files
fabi
yes, i tried - it didn't help
also i'm not sure, that this Warn-message is really a problem - it still produces a valid v3bandwidth file
ok, no i have a clue:
the scan files actually seem to be stale
if i compare the scan-data dir's in the scanners of my two authorities, the working one has a lot more and up-to-date files in there
Sebastian
great
fabi
so it really seems, the scanner is not working right
Sebastian
see, that's what I was trying to get you to do ;)
fabi
but that makes my problem worse
i mean - what can i do else, than completely restarting it?
Sebastian
well, now you have to check how scanning fails for one of the two. Check the obvious things first, wrong path, wrong access rights, script not marked as executable
fabi
this all cannot be
i didn't change anything
         

Sebastian
can you give someone access to the machine?
fabi
unfortunately not :(
Sebastian
ok
fabi
Sebastian: btw, you were wrong that 1 of 3 directories is enough to perform bw authority votes
it has to be a majority of them
the interesting question is: what is a "majority" of 4? 2 oder 3?
Sebastian
fabi: I thought one of those 3 authorities was turned off?
fabi
that's why i ask
Sebastian
but you might still be right that majority means ceil(half + 0.5)
I don't know. The spec should tell, or we should put it in the spec.
fabi
in that case it would be of no help adding a new directory that works fine in any way
Sebastian
hrm
in Tor, we have 7 dir auths
fabi
8
nsa
or: phobos committed revision 21364 (/website/trunk): I've had this in my working dir for a bit, start a relays4tor campaign.
Sebastian
I don't know how many of those measure, I thought it was only 3
8?
can you list them?
fabi
aren't it 8?
they are 9
according to torstatus
Sebastian
I know 7. moria1, urras, gabelmoo, dannenberg, tor26, ides, dizum
well
torstatus lists bridge authorities, hidden service authorities, and v1 authorities
fabi
moria2, tonga
for my problem iirc it was "the majority or at least 3"
Sebastian
ah ok
fabi
so if the majority of 4 is also 3 it would be a bad idea to add a new directory to my network
Sebastian
right, unless it can measure
maybe the code is screwed up somewhere and we messed up the majority check, and went with at least 3 exclusively?
fabi
exactly this was my very first intention that made me look around here ;9
Sebastian
aha!
looks like we screwed up.
if (consensus_method >= 6 && num_mbws > 2) {
rs_out.has_bandwidth = 1;
rs_out.bandwidth = median_uint32(measured_bws, num_mbws);
fabi: where did you find your "the majority or at least 3" sentence?
         

fabi
it was either in a proposal (160/161) or it came from arma's words
So it has always to be at least 3 authorities voting a measured-bw value?
Sebastian
the proposal says this:
Finally, networkstatus_compute_consensus() will set rs_out.bandwidth
to the median of the measured values if there are more than 3, otherwise
it will use the bandwidth value median as normal.
looks like it lies.
fabi
why?
the bandwidth value median as normal means the observed-bw from the descriptor doesn't it?
Sebastian
I think so
fabi
ok, that's really interesting
Sebastian
it lies because it asks for more than three, and the code asks for more than 2
anyways
fabi
then i was misinformed
Sebastian
there is a lot of bullsh*t in this
you should file a bug to get it fixed.
fabi
so this means it's completely useless to get my second scanner running unless I add a new one so that at last in total 3 of them are voting..
Sebastian
or you change the source
I declare that this is a bug anyways
we should totally support networks with one authority.
fabi
the question here is (and that is very important) that the quality of the selection algorithm will be less when there are less votes used
Sebastian
well, one or two doesn't make a difference
fabi
the bw-authority measurements may differ a lot while the descriptor's values do not
Sebastian
because it doesn't take an average, it takes a median, choosing the lower value. So having two authorities measure just means that the one that happened to measure the lower value for that relay wins.
fabi
right
Sebastian
this is actually obvious from the code snippet I pasted above
Of course, this might be the reason why >2 makes sense from a point of view where you want good results
fabi
this also implies that for a well perfoming measurement there _have_ to be more than two voting
Sebastian
so that one measuring authority being flaky doesn't kill you entirely
fabi
exactly
exactöy
Sebastian
but this is a bad assumption for private tor networks.
fabi
hmm... depends on the private network
Sebastian
if you want realistic results for your private network, you're going to set up a large number of authorities, anyways
fabi
hmm...
Sebastian
and with that, a large number of bandwidth scanners
fabi
i always feared that ;)
Sebastian
I think the problem was that we have too many people running an authority who are unable to run a bandwidth scanner reliably, so we said that more than three must be enough
this is imho even a security issue, if you have 100 authorities, should three of them really get to make such a decision?
But this is all fine discussion for a bug report where it is documented.
fabi
if you are in need of 100 authorities your network info distribution system is not well-designed ;)
Sebastian
If we could, we would have 20 or more
it's a huge gain in trust
having 4 people collaborate is relatively easy
having 50 do so is not that trivial.
fabi
but this authority scheme won't scale forever
Sebastian
Tor won't scale forever
fabi
each client is uploading it's descriptor to each authority
Sebastian
the authority scheme can scale a lot longer
fabi
but that's not my task ;)
Sebastian
each relay, not each client.
what is your task, anyways
fabi
yes, i meant that
performance
Sebastian
well, scaling will become a big issue wrt performance ;)
it is currently totally impossible to have 100k relays, for example
fabi
?
Sebastian
but anyways, that isn't important. Please file that bugreport.
fabi
i wonder how much effort it needs to add 2 new authorities to my network...
Sebastian
only you can tell ;)
fabi
why?
my private network doesn't differ from others
Sebastian
well, it not only depends on your current setup, but also your experience and overall technical ability. I would think it is rather trivial to set up two more authorities after having set up three already
and I think you're probably one of very few people, possibly the only one, to run a private Tor network with bandwidth scanners.
fabi
my thought is: do i only have to change the authorities configuration (of the existing 3, or the remaining 2 of them) or do i have to change the configuration of all relays and all clients also?
i think you are right with that
i am probably the only one running a private tor network that exactly rebuilds real Tor's performance ;)
but in order to prove that, i have to find out, that performance improvements with the bw authority scheme apply to my network exactly as they do in the real tor
that's why i'm so interested in getting these scanners to work ;)
Sebastian
well, you would only need to change the authorities' source
will you file that bug? Otherwise I'll do it tomorrow.
fabi
could you do that? that would be nice
i don't want to change authorities source. Than the measurements in my network arent comparable to those on the real network anymore
Sebastian
if you think they aren't comparable due to this, then you definitely want to have 7 dirauths and 3 scanners.
fabi
no
4 authorites with 3 scanners would result exactly in the same vote
but at least now i know that i definitely need 3 scanners...
Sebastian
right. Do you not read C? Just wondering, because you could have gotten that answer much quicker :)
fabi
I don't have time to validate any info i read in a spec, a proposal or that I get here in sources
Sebastian
Sure, it's unfortunate that you picked a topic for your research that is new, poorly specified, and still changing often.
fabi
exactly
but fortunately the end is close
Sebastian
but that is your problem, and it would be really neat if you helped overcome the current chaos by being constructive.
At least there is a spec and proposals to serve as a guideline
We rely on people like you to challenge them and put them to the test
fabi
i know
i know that a proposal is a proposal. It's a written form of ideas
but i thought a spec is a specification where the implementation is specified
that was naive
Sebastian
that's the way it is supposed to be
unfortunately, reality proves that often code is merged without it being specified well.
but if you don't write bug reports about those issues, they will never be fixed
fabi
what would be no big problem if the specification is not the basis of research
Sebastian
it is your responisbility to at least complain in form of a bug report
fabi
i think i complained often enough ;)
Sebastian
how many bug reports did you open?
I thought so.
fabi
most bugs i found, that i call bugs and i can prove them to be bugs are in python TorCtl API
in Tor you never know whether it is a bug or a feature
Sebastian
If you find something that is not specified or specified incorrectly, that's a bug.
anyways, this is pointless.
fabi
i heared several times here, that probably all specs have to be updated in any way
Sebastian
In the future, you'll save your precious time and continue not reading the source and filing bugs, and I save my precious time and don't try to help you.
fabi
hmm
i don't understand your point
you complain that i don't have time to read Tor source code? (what is a quite hard task, since it is not easy to read if your time is limited by more important things)
i actually thought that is exactly what these irc channels are for...
nsa
or: phobos committed revision 21365 (/website/trunk/en): make the relay count look like a count and not a year.
or: phobos committed revision 21366 (/website/trunk/en): update the total # of running routers
or: phobos committed revision 21367 (/website/trunk): update the relay thermometer fill level to be accurate
or: phobos committed revision 21368 (/website/trunk): update the font weight so it looks placed correctly.
keb
svn: warning: URL 'https://tor-svn.freehaven.net/svn/torbutton/trunk/website/design' at revision 21368 doesn't exist
hmm
phobos
yeah
we moved torbutton to git
and need to figure that out ;)
keb
ah yes it is code
arma
phobos: i think what should be done is we should just copy the files from the git repo, and commit them into that directory of the website. when they change, eventually remember to update the files in website svn.
BarkerJr
only one more day to release 0.2.2.7 *blinks*
keb
i didnt know there was a milestone date
BarkerJr
yeah, the changelog says it'll be released in 2009-12
keb
whose nick is "changelog", we must hold them accountable for this
BarkerJr
hehe
xtoaster
arma: any plan for the solution of bridge blockage ? i mean for handling the geo difference ?
BarkerJr
I added a new bridge last week and it has about 50 times as many connections than my old bridges... is that what you mean?
keb
bridges are needed more than ever
xtoaster
no some briges are blocked here but not there
and our bridge page serve bridge wihtout geo consideration
and another question - hwo do we know which bridge is blocked in what country :(
phobos
arma: how do we get rid of the external include?
nsa
or: phobos committed revision 21369 (/website/trunk/torbutton): add torbutton design dir from git.
phobos
there
and still broken in new ways
BarkerJr
I seem to have a problem... I set ORListenAddress and the daemon is listening on the right address, but it's still checking if the old ip/port is reachable... how come?
will it fail in 20mins then try the new ip?
keb
do you still have Address and ORPort specified?
phobos
did you restart or reload?
BarkerJr
I restarted (had to reboot to add the IP address)
I have ORPort [Port] and ORListenAddress [IP] set
like I said, it is bound to the right one as I see in 'netstat', just its log entry has: Now checking whether ORPort [Old IP]:[Port] is reachable...
keb
PublishServerDescriptor is tied to ORPort. maybe it is due to that?
BarkerJr
is ORListenAddress the wrong setting to force tor to use a specific ip?
here's what I'll do... I'll just make my new IP the primary
keb
hmm the manpage says ORPort is the advertised port, while ORListenAddress is the bound ip:port.
https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ServerForFirewalledClients
aef
hi, i saw the lecture on 26c3 and wanted to setup a bridge node. why the hell isn't there a tor package on ubuntu anymore?
keb
they dont keep it up to date enough. check http://www.torproject.org/docs/tor-doc-unix.html.en
« prev 1 2 3 next »