Plan for conflux onionperfs
Now that 0.4.8 is stable, we should figure out a way to switch to it, and what to do about existing onionperfs.
I think the plan that makes the most sense is:
- Deprecate the op-*6a instances
- Remove the NL instance
- Run two sets of 0.4.8 Tor for HK, DE, and US. One with
ConfluxEnabled 0one as-is.
The ConfluxEnabled 0 runners will only use congestion control, and be used for tpo/network-health/team#313 data.
The other runners will be Conflux.
This leaves us with the same number of onionperfs, all running the same version. We should name them more clearly:
- op-de-cc
- op-de-cfx
- op-hk-cc
- op-hk-cfx
- op-us-cc
- op-us-cfx
How does this sound?
Activity
assigned to @hiro
One wrinkle to be aware of: conflux circuits have their own purpose on the client side, and you won't (easily) be able to just use the existing path storage that is being used in tpo/network-health/team#313, because there are two legs.
It is fine to ignore this for now, as we will only be using that data from the congestion control instances. But if onionperf assumes it will always be able to make sense of which relays are in a path inherently, I could see surprises here.
added Metrics Maintenance Next Q3 labels
mentioned in issue #40070 (closed)
I think this sounds like a reasonable plan. I'd be especially happy to retire the 6-series instances that have generated already a lot of data.
On the other hand I am a bit worried about what the new path on conflux might look like and what onionperf might "think" of that. There might be some dev work to do there but we need to test first.
-
Tor 0.4.8 is now pre-building 3 conflux sets, and we have close to 60% exits upgraded. So conflux should now be behaving in a steady-state.
The control port purpose field for conflux circuits is "CONFLUX_LINKED". We should make sure that is handled correctly and that the onionperf fetches are using that purpose. With 3 spare sets being maintained, they should always do so.
-
@mikeperry I plan to start deploying these today.
I just have a few quick questions:
-
Should all these instances drop guards or not?
-
Also should I maintain the tor-0.4.8.0-alpha-dev instances or these can be archived?
-
Finally should both the client and the server have conflux enabled? This matters for over onion measurements basically.
Edited by Hiro -
-
- Should all these instances drop guards or not?
Yes they should, same as before. They should also wait for the BUILDTIMEOUT_SET event before fetching, as before.
- Also should I maintain the tor-0.4.8.0-alpha-dev instances or these can be archived?
I am not sure what these are. We already had 0.4.8.0 running? Were these being graphed on the website?
- Finally should both the client and the server have conflux enabled? This matters for over onion measurements basically.
Technically this does not matter since C-Tor onions don't do conflux. In fact, if it is possible to disable onion service measurements just for the cfx instances without everything exploding, maybe that would be best to avoid confusion. But otherwise, just enable it on both sides.
When we have artibench metrics and arti conflux, we will want conflux on both sides for onions.
-
Ok the tag tor-0.4.8.7 is up with the fix for tpo/core/tor#40862 (closed), for pre-built conflux sets to get built properly.
-
deployed.
Edited by Hiro -
Yes I need to fix iptables it seems on a few instances.
...
On 2 Oct 2023, at 21:40, Mike Perry (@mikeperry) git@gitlab.torproject.org wrote:
Mike Perry commented on a discussion:
There seems to be data missing from some of these instances? It looks like only the HK ones are being graphed?
— Reply to this email directly or view it on GitLab. You're receiving this email because of your account on gitlab.torproject.org. Unsubscribe from this thread · Manage all notifications · Help
-
I am almost finished archiving them. Only the nl instance is missing. Then I will have to update the wiki and shutdown the VM.
Said this, I was wondering if we want to create conflux NL instances since we do not pay for greenhost.
...
On 9 Oct 2023, at 12:14, Georg Koppen (@gk) git@gitlab.torproject.org wrote:
Georg Koppen commented on a discussion:
FWIW: op-{hk,de,nl,us}7a are still doing stuff but are gone from the measurements on metrics.tpo as well. I guess we wanna archive them, too?
That said the onion measurements seem to work for the new op8* instances...
— Reply to this email directly or view it on GitLab. You're receiving this email because of your account on gitlab.torproject.org. Unsubscribe from this thread · Manage all notifications · Help
-
It is an iptables issue w/ forwarding port 443 to tgen on 8080. All clients are deployed the same but something is happening between aws firewall and the vm itself.
...
On 16 Oct 2023, at 18:21, Mike Perry (@mikeperry) git@gitlab.torproject.org wrote:
Mike Perry commented on a discussion:
It looks like only the HK instances are being graphed still?
Was the firewall issue fixed or is there some other issues?
— Reply to this email directly or view it on GitLab. You're receiving this email because of your account on gitlab.torproject.org. Unsubscribe from this thread · Manage all notifications · Help
removed Next label
added Doing label
