[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9166 [Tor]: Write a UTP-based channel implementation
#9166: Write a UTP-based channel implementation
---------------------------+------------------------------------------------
Reporter: nickm | Owner:
Type: defect | Status: new
Priority: normal | Milestone: Tor: unspecified
Component: Tor | Version:
Keywords: tor-relay utp | Parent: #9165
Points: | Actualpoints:
---------------------------+------------------------------------------------
Comment(by robgjansen):
Replying to [comment:10 karsten]:
> I just finished new Shadow simulations using the large 64 GB network
configuration. See attached two PDFs:
>
> -
[https://trac.torproject.org/projects/tor/attachment/ticket/9166/sjm217
-utp-64GB-seeds-combined.pdf sjm217-utp-64GB-seeds-combined.pdf] compares
two runs with uTP for none of the links to two runs with uTP for all
links. The two runs using the same configuration use different random
seeds (using `scallion` vs. `scallion -s 2`). The motivation for this
experiment was to see if the large 64 GB network configuration shows more
significant performance differences than the small 16 GB network
configuration, and to see if differences are real or random.
Unfortunately, it looks like differences are mostly random.
>
Yeah, it definitely doesn't *look* like the experiments actually used a
different transport.
> -
[https://trac.torproject.org/projects/tor/attachment/ticket/9166/sjm217
-utp-64GB-traffic-combined.pdf sjm217-utp-64GB-traffic-combined.pdf]
compares the runs with seed 1 to similar runs that put additional non-Tor
TCP traffic on the Shadow network. Additional TCP traffic is produced by
adding a second instance of Shadow's filetransfer plugin called traffic,
making all clients perform requests to fileservers directly, and removing
all `".*[traffic-.*"` lines from `scallion.log` before making graphs. The
motivation for this experiment was to see if additional network load has
any effect on Tor performance. Looks like this is not the case.
>
I wouldn't expect it to produce the results you want, unless you produce
the extra TCP load on relays, clients, or fileservers that are bottlenecks
-- you need to 'steal' bandwidth from the client's Tor application, or
from a relay's Tor application. You could do this by adding the extra
client applications on existing Tor client nodes, and then reduce their
bandwidth to ensure the extra load means less bandwidth for Tor.
> I'd like to do one more experiment: can Shadow somehow output what
amount of traffic uses TCP vs. UDP? I'd like to re-run the simulation in
a small or tiny network with uTP enabled and disabled, to confirm that
enabling/disabling uTP actually worked. Rob, any idea how Shadow could
provide this information?
Its your lucky day ;) It wasn't directly possible, but I just implemented
and pushed it to shadow master. You need to include 'socket' in the
attribute value of the 'heartbeatloginfo' attribute to the 'node' element.
So, something like this:
{{{
<node heartbeatloginfo="node,ram,socket" ... >
}}}
Careful though, as this prints out information for every active socket for
every node on which you enable this feature. grep the logs for '\[shadow-
heartbeat\] \[socket'.
If you are feeling particularly adventurous, you can enable for every node
in the simulation at the same time with the shadow command line switch:
{{{
scallion --heartbeat-log-info=node,ram,socket ...
}}}
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9166#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs