#25687: extreme over-report of observed / self-measure bandwidth on fast
hardware
-- critical to torflow / peerflow
--------------------------+------------------------------------
Reporter: starlight | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Core Tor/Tor | Version: Tor: 0.3.3.3-alpha
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------+------------------------------------
Comment (by arma):
Replying to [ticket:25687 starlight]:
> Have observed that on fast hardware the maximum bandwidth estimate
reported by `rep_hist_bandwidth_assess()` and published via
`ri->bandwidthcapacity` is frequently overstated and have seen it go as
high 160% of true physical bandwidth, stay there for days.
Well, from Tor's perspective I think it really is seeing you get that
level of throughput.
That is, it was able to see a sustained 10 second period where it got that
average rate.
Part of the explanation might be that the kernel is saying "yep, it's
sent" when actually it's just queued inside the kernel. For those cases,
in theory Kist should be doing *better*, because it has a chance of saying
"ok, actually I checked with the kernel and there's some stuff queued so
I'm not going to try to write more quite yet". That said, the way the
kernel maintains good throughput is by having a bunch of waiting stuff
queued, so it can always be sending the next bit as quickly as possible
rather than having to wait for user space to decide to ask it to send some
more.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25687#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
