GitLab

In connection_buckets_decrement(), we report to rep_hist_note_bytes_read/written whether the traffic was relayed traffic or our own traffic. If the user sets RelayBandwidthRate and the relayed traffic constantly hits that level, then any numbers higher than that in the read-history/write-history lines will be due to locally initiated traffic.

The easy fix would be to only count bytes that were sent on relayed connections -- so locally initiated directory connections, and all circuits on connections that recently carried traffic for an origin circuit, would be ignored:

Index: connection.c

--- connection.c (revision 11723) +++ connection.c (working copy) @@ -1546,12 +1546,12 @@ if (!connection_is_rate_limited(conn)) return; /* local IPs are free */

• if (num_read > 0)
• rep_hist_note_bytes_read(num_read, now);
• if (num_written > 0)
• rep_hist_note_bytes_written(num_written, now);

• if (connection_counts_as_relayed_traffic(conn, now)) {
• if (num_read > 0)

•  rep_hist_note_bytes_read(num_read, now);

• if (num_written > 0)

•  rep_hist_note_bytes_written(num_written, now);

• if (connection_counts_as_relayed_traffic(conn, now)) { global_relayed_read_bucket -= num_read; global_relayed_write_bucket -= num_written; }

Then I realized that this has the mirror-image problem: if the server has uniform enough usage around its BandwidthRate, then just as we were looking at spikes before and knowing they came from non-relayed traffic, now we look at dips and conclude the same thing.

Hm.

[Automatically added by flyspray2trac: Operating System: All]