Digital ocean does not currently charge for going over your data limit. On Jan 31, 2015 1:51 PM, <[email protected]> wrote:
> Send tor-relays mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > Today's Topics: > > 1. Re: entry guard interference? ([email protected]) > 2. Re: entry guard interference? ([email protected]) > 3. Re: Digital Ocean: Moving to better Plan (Abhiram Chintangal) > 4. Re: Consensus weight dropped (Bram de Boer) > 5. Re: Consensus weight dropped ([email protected]) > 6. Re: Consensus weight dropped ([email protected]) > 7. Re: Consensus weight dropped (Network Operations Center) > > > ---------- Forwarded message ---------- > From: [email protected] > To: [email protected] > Cc: > Date: Sat, 31 Jan 2015 09:26:24 -0500 > Subject: Re: [tor-relays] entry guard interference? > At 06:20 1/31/2015 -0500, grarpamp wrote: > >Yet during the time of an outage, you might try > >to leave the old tor running and. . . > > I see the idea here but it's a lot > of fiddling and preparation. If it > continues to happen and I suspect > a bug, I'll upgrade the relay > version and run 'tcpdump' with > a ring-buffer capture that holds > the last two or three hours of > traffic. Then I just have to > stop the 'tcpdump' and review what > happened. Look for ICMP "not > reachable," injected RST's etc. > > If my "just because your paranoid > doesn't mean they're not out to > get you" theory is correct, it > may never happen again. Certainly > the spooks of the world all read > the Tor mailing lists. > > > > > ---------- Forwarded message ---------- > From: [email protected] > To: [email protected] > Cc: > Date: Sat, 31 Jan 2015 10:04:14 -0500 > Subject: Re: [tor-relays] entry guard interference? > At 06:20 1/31/2015 -0500, grarpamp wrote: > >Yet during the time of an outage, you might try > >to leave the old tor running and. . . > > Also I see I should make a copy of the > cached-* files and the state file in > case some anomaly is present the Tor > routing data. > > I did look at Vidalia'a network map > at the time of the incident and the > list of relays on the left side looked > ok. On the right side something like > > <path> > <path> > etc > > appeared where client connections > normally are listed. > > > > > ---------- Forwarded message ---------- > From: Abhiram Chintangal <[email protected]> > To: [email protected] > Cc: > Date: Sat, 31 Jan 2015 12:22:42 -0500 > Subject: Re: [tor-relays] Digital Ocean: Moving to better Plan > Hello Sebastian, > > Thanks for responding. > > On Fri, Jan 30, 2015 at 10:15 PM, Sebastian Urbach <[email protected]> > wrote: > >> On January 31, 2015 2:09:14 AM Abhiram Chintangal < >> [email protected]> wrote: >> >> Hi Abhiram, >> >> >>> I have been running a tor middle relay[1] for the past few months. >>> >> >> Thank you very much ! >> >> >>> One thing that I noticed in the last two months is that my relay is >>> eating >>> up the 1tb bandwidth in the first three weeks. So I am thinking of moving >>> to a better plan or tweaking the current config to serve the bandwidth so >>> that the relay is up for the entire month. >>> >> >> I assume that you want a recommendation. A better plan probably means >> spending more money. Would be better for the network. If you can spare the >> money, go for it. >> >> If you dont want to spend more money than it would be a good idea to >> lower the Rate value until you end up within your traffic limit for the >> month. The benefit would be a permanent available relay. >> > > Hmm, I think I will try changing the rate and see what happens. Last > year, I used a daily limit instead of monthly one. It drastically reduced > the relays reported bandwidth ( 1Mbps to 60 kbps ). > > Thanks! > > > -- >> Sincerely yours / Sincères salutations / M.f.G. >> >> Sebastian Urbach >> >> ----------------------------------------- >> Religion is fundamentally opposed to >> everything I hold in veneration - courage, >> clear thinking, honesty, fairness, and, >> above all, love of the truth. >> ----------------------------------------- >> Henry Louis Mencken (1880 - 1956), >> American journalist, essayist, magazine >> editor, satirist and critic. >> >> >> _______________________________________________ >> tor-relays mailing list >> [email protected] >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > > > -- > Abhiram Chintangal > > > > > ---------- Forwarded message ---------- > From: Bram de Boer <[email protected]> > To: [email protected] > Cc: > Date: Sat, 31 Jan 2015 20:54:42 +0100 > Subject: Re: [tor-relays] Consensus weight dropped > All, > > Consensus weight of my relays and those of others is still near zero, and > not improving. For a network that attempts to break censorship, it is > peculiar that this is getting so little attention. > > Apparently a few malfunctioning bwauth systems is enough to censor > specific Tor relays. Endless research and development effort is put in > tweaking and optimizing the relay-to-relay communication, but having only > a few systems in the world that determine the consensus weight of the > entire network does not seem to trouble anyone. Wierd. > > I hope the bwauth operators can find a way to correct the problem. I am > feeling silly spending good money on a high-end server with unmetered > bandwidth that has now been relaying a whopping 300 Kb/s on average during > the last five weeks. > > Thanks, > Bram > > > > Thank you all for looking into this. > > > > Karsten wrote: > >> You could start a second relay on the same physical machine on a > >> different port and see whether the bandwidth scanners pick that up. > >> Give it a day or two, and see if only tor26 and moria1 measure it. > > > > In fact, both the 7C3AE76BB9E9E6E4F2AE9270FD824DF54A944127 and > > E6D740ABFFAAAD8052EDF95B2C8DC4059763F365 relays operate on the same IP > > address. Both dropped to 0.000000%. > > > > However, other nodes in the same AS16265 are doing fine (e.g. > > B144DC5C08AF1FB3ABD729AFC2CF938CF63F78AC). This seems to suggest that the > > route between the bwauths and the relay is irrelevant and connectivity is > > not an issue. > > > > I can imagine that an overloaded bwauth occasionally skips a few relays. > > But wouldn't that be corrected automatically during the measurement the > > next day? Given that the relays are missing votes consistently during > many > > consecutive days, some other mechanism must be causing this. > > > > Would a quick-fix be to randomize the order in which relays are measured? > > That way, if a bwauth has trouble processing the entire list in 24h, > every > > day other relays are given a chance? > > > > Thanks, > > Bram > > > > _______________________________________________ > > tor-relays mailing list > > [email protected] > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > > > ---------- Forwarded message ---------- > From: [email protected] > To: [email protected] > Cc: > Date: Sat, 31 Jan 2015 15:23:08 -0500 > Subject: Re: [tor-relays] Consensus weight dropped > At 20:54 1/31/2015 +0100, you wrote: > >Consensus weight of my relays and those of others > >is still near zero, and not improving. . . > > I read the earlier discussion around this > issue with interest. Have no specific > ideas about resolving the problem, but > I can recommend pulling the raw text > data files for the authority votes, > grep'ping your nodes, and looking at > the specific BWauth votes over time. > > The data is found here > > https://collector.torproject.org/archive/relay-descriptors/votes/ > > and while the files are a bit huge, > are easy to whack at with *nix > command line tools such as > egrep/awk/sed/perl etc. In a > pinch one might apply Excel to the > problem, but first trim the data > set down to size with a grep or your > desktop and Excel will choke and > die. > > I did this at the point where the > bandwidth for election to guard > status was increased greatly and > my node was shipped off to middle- > relay mediocrity. Could see > clearly how it all transpired, but > of course I could do nothing about > it short of spending more $$ on > bandwidth. > > With the raw data in hand, it will > be easier to campaign the operators > of the troublesome BWauths to correct > the problem. > > > > > ---------- Forwarded message ---------- > From: [email protected] > To: [email protected] > Cc: > Date: Sat, 31 Jan 2015 15:32:23 -0500 > Subject: Re: [tor-relays] Consensus weight dropped > also, for recent data. . . > > https://collector.torproject.org/recent/ > > > > > ---------- Forwarded message ---------- > From: Network Operations Center <[email protected]> > To: [email protected] > Cc: > Date: Sat, 31 Jan 2015 21:51:12 +0100 > Subject: Re: [tor-relays] Consensus weight dropped > This has already been done. And I was under the impression that things > would be changing soon. I still find it weird that the network is ignoring > several nodes. > > On 31.01.2015 09:23 PM, [email protected] wrote: > >> At 20:54 1/31/2015 +0100, you wrote: >> >>> Consensus weight of my relays and those of others >>> is still near zero, and not improving. . . >>> >> >> I read the earlier discussion around this >> issue with interest. Have no specific >> ideas about resolving the problem, but >> I can recommend pulling the raw text >> data files for the authority votes, >> grep'ping your nodes, and looking at >> the specific BWauth votes over time. >> >> The data is found here >> >> https://collector.torproject.org/archive/relay-descriptors/votes/ >> >> and while the files are a bit huge, >> are easy to whack at with *nix >> command line tools such as >> egrep/awk/sed/perl etc. In a >> pinch one might apply Excel to the >> problem, but first trim the data >> set down to size with a grep or your >> desktop and Excel will choke and >> die. >> >> I did this at the point where the >> bandwidth for election to guard >> status was increased greatly and >> my node was shipped off to middle- >> relay mediocrity. Could see >> clearly how it all transpired, but >> of course I could do nothing about >> it short of spending more $$ on >> bandwidth. >> >> With the raw data in hand, it will >> be easier to campaign the operators >> of the troublesome BWauths to correct >> the problem. >> >> _______________________________________________ >> tor-relays mailing list >> [email protected] >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > > _______________________________________________ > tor-relays mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >
_______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
