-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
> If you can read Python and shell script, then checking I haven't made
any obvious coding errors in my changes would help. But that might
require becoming familiar with the codebase - which may take some effort.
>
> The diffs are here, or you can
> On 10 Jul 2015, at 11:35 , teor wrote:
>
>
>> On 10 Jul 2015, at 09:47 , Cory Pruce wrote:
>>
>>
>> Signed PGP part
>>
>>>
>>> Well, you could test my latest branches for #14175:
>>
>> Hey Tim, I got the branch of chutney and tor and made sure that the
>> commands you run in the comment
> On 10 Jul 2015, at 09:47 , Cory Pruce wrote:
>
>
> Signed PGP part
>
> >
> > Well, you could test my latest branches for #14175:
>
> Hey Tim, I got the branch of chutney and tor and made sure that the
> commands you run in the comments of the issue exist. What do you think
> would be a good
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
> Well, you could test my latest branches for #14175:
Hey Tim, I got the branch of chutney and tor and made sure that the
commands you run in the comments of the issue exist. What do you think
would be a good way to start testing? Begin with a sta
> On 6 Jul 2015, at 11:16 , Cory Pruce wrote:
>
> >
> >
> > And running everything on the same box / VM should still give you some
> idea, as long as CPU usage on all CPUs isn't ~100%.
> >
>
> Haha I guess this is a "we'll wait and see" situation. Let me know if
> there is anything I can do for
On Sun, 05 Jul 2015 10:20:50 -0700
Cory Pruce wrote:
> Dude, thanks a bunch for you help. I'm really excited to start :D I'm
> going to read through the initial design and the code to see what
> functions/structures/constants/etc. need to be changed. Let me know
> when you release #14175 and I'll
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
> Well, your ideal scenario is a separate box / VM, with at least 2
separate cores, for each of the tor instances you're pushing data
through (2-3 with a path length of 1, 4-5 with a path length of 3, as
you'll need to account for cannibalization).
> On 6 Jul 2015, at 04:36 , Cory Pruce wrote:
>
> >
> > Yes, and testing locally gives you much better control of all the
> factors which affect performance.
> >
>
> Can I set everything up using vm's or maybe just a single relay?
Well, your ideal scenario is a separate box / VM, with at least
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
> Yes, and testing locally gives you much better control of all the
factors which affect performance.
>
Can I set everything up using vm's or maybe just a single relay?
>
> Yeah, that was 8 optimistic, uninterrupted hours. Otherwise known as
"fa
> On 6 Jul 2015, at 03:20 , Cory Pruce wrote:
>
> On 07/04/2015 06:19 PM, teor wrote:
>
> > You could also modify tor to use single-hop connections, then measure
> > single-hop bandwidth, by
> making a 1-hop connection and pushing data through it. There won't be as
> much client crypto as the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/04/2015 06:19 PM, teor wrote:
>
> make test-network is dominated by the 25 second delay waiting for the
Tor test network to bootstrap. So it's not going to help much.
>
> I'm working on a chutney branch to measure bandwidth on "chutney
verify"
> On 5 Jul 2015, at 05:45 , Cory Pruce wrote:
>
> One more thing for right now: how should I do benchmarks with chutney.
> Should I measure the averages of how long it takes to complete the make
> test-network command?
make test-network is dominated by the 25 second delay waiting for the Tor te
12 matches
Mail list logo
