Opened 6 years ago

Closed 18 months ago

#935 closed enhancement (wontfix)

Estimate and set initial bandwidth limits based on reseed download rate

Reported by: zzz Owned by: zzz
Priority: minor Milestone: undecided
Component: router/netdb Version: 0.9.5
Keywords: new-user performance Cc:
Parent Tickets:


Use the apparent reseed d/l rate to guess and configure the initial upstream bandwidth limits on a new installation.

Depends on #934 to d/l a zip file, as the current fetch of individual RI files is far too slow (1-2 KBps) to get a meaningful estimate.


Change History (9)

comment:1 Changed 4 years ago by str4d

  • Keywords new-user performance added
  • Milestone 0.9.9 deleted

comment:2 Changed 4 years ago by zzz

  • Milestone set to 0.9.21
  • Type changed from defect to enhancement

This is actually feasible now that we have su3 reseed; the file should be big enough that SSL handshaking and RTT don't predominate. I will add in some code to get some measurements and go from there.

comment:3 Changed 4 years ago by zzz

So I stubbed it out. Example:

Reseeder: Rcvd 75042 bytes in 1425 ms from https://xxx/i2pseeds.su3
Reseeder: Rcvd 81164 bytes in 1678 ms from https://yyy/i2pseeds.su3
Reseeder: Bandwidth average: 50515 of 2 samples

So that's 50.5 KBytes/sec down bandwidth estimate, without any correction for RTT, SSL handshake, etc.

I guess the best thing to do is maybe subtract half a second or so for the handshake, that would get me 75 KBps. Then divide by 5 or so to get an upstream estimate? That would be 15 KBps up. That's off by probably a factor of 10 from my real up bw.

We could instead measure from the first HTTP header line received to the last byte received, thus skipping all the RTT and SSL handshake, but I fear that time may be close to zero due to buffering and thread latency, leading to very high bw estimates.

Not sure we have a solution here. The su3 files may be too small to use for an estimate.

comment:4 Changed 4 years ago by echelon


IMHO a bad idea, as the bandwidth of a http request of 100kb is not near the real line speed. Also delays on server, network, clients,.... do set bandwidth down.
All I see is a min bandwidth setting based on this MAYBE, if you rule out possible caches.

comment:5 Changed 4 years ago by zzz

Maybe just a threshold test?


if the measured down reseed bw is more than X, set the default up bw to 64 KBps, else set to 32 KBps.

comment:6 Changed 3 years ago by str4d

  • Status changed from new to open

comment:7 Changed 3 years ago by zzz

  • Milestone changed from 0.9.21 to undecided

comment:8 Changed 2 years ago by slumlord

I'm not sure if it's a good idea to do automatic bandwidth limits, there's many things that I feel could affect the results, some of which echelon has already mentioned. I could be furiously uploading my latest .tar of cat photos to my NSA cloud drive which could limit my download speeds (on some types of connections, at least). I could have to go through a proxy to reach clearnet sites which would affect my download speed measurement.

I see good reasons to "encourage" users to increase their bandwidth settings, though. For one, if all routers increased their BW limits by say 10 KB/s, it would mean more capacity for I2P and, possibly, a faster network. Perhaps a collapsible banner for new installs on the console home page with a short message for users about setting BW limits?

comment:9 Changed 18 months ago by zzz

  • Resolution set to wontfix
  • Status changed from open to closed
Note: See TracTickets for help on using tickets.