Add new/better bandwidth measurement algorithm

[david415]

Currently our bandwidth measurements are done incrementally with each cell that traverses the circuit but instead we could measure the time once the entire test payload is received.

[DonnchaC]

The incremental measurement approach is more likely to reflect the real bandwidth on a connection. Measuring the start and end of the test payload download will be affected by the latency in establishing a circuit and connection. We should decide which of these values is more relevant for the Tor bandwidth auths.

[DonnchaC]

The measurement code is now just using the fetch start and finish time and does the naive calculation to determine the bandwidth. This time will include the extra time needed to establish the circuit. It would be useful to have an event which also logs the circuit establishment time.

This would allow us to analyse the measurements later and determine if the circuit creation time distorts the total bandwidth values.

[joelanders]

We have both a class CircuitEventListener(CircuitListenerMixin, StreamListenerMixin) and a class StreamBandwidthListener(CircuitListenerMixin, StreamListenerMixin), but it looks like they need to be attached to the txtorcon state like self.tor.add_circuit_listener(self.circuit_event_listener), and that's only happening in test/test_listener.py.

Is that old code, or what? Seems easy to attach the circuit listener and read out the times of the circuit build events? I might be missing something.

[meejah]

I was going to add a "listener" style API to txtorcon 1.0. Would such an API be useful in a case like this? See meejah/txtorcon#168

Anyway, no matter the method, you can indeed get timestamps for all aspects of the circuit lifetime (each time it's extended, when it becomes BUILT and thus ready to take a stream, etc). See https://txtorcon.readthedocs.io/en/latest/txtorcon-state.html#circuit for meanings of the .state attribute. The circuit events are emitted when this is updated, approximately (except: there are several EXTENDED events, after each of which .path will be one Router instance longer).

[DonnchaC]

@joelanders Yes, your right. Those circuit and stream bandwidth listeners are not currently being used. We had trouble testing this in #20 but its potentially useful so we didn't want to purge it just yet. It would be useful if you could figure out how to test that code based on #20.