# Migrating from Gemini 3f to Gemini 3g

**URL:** <https://forum.autonomys.xyz/t/migrating-from-gemini-3f-to-gemini-3g/2084>\
**Category:** Guides and FAQs\
**Tags:** gemini, nodes\
**Created:** [October 31, 2023, 10:37pm UTC](https://forum.autonomys.xyz/t/migrating-from-gemini-3f-to-gemini-3g/2084 "2023-10-31T22:37:50Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jim-Autonomys](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/jim-autonomys/32/2922_2.png) [@Jim-Autonomys](https://forum.autonomys.xyz/u/Jim-Autonomys)\
**Post date:** [October 31, 2023, 10:37pm UTC](https://forum.autonomys.xyz/t/migrating-from-gemini-3f-to-gemini-3g/2084/1 "2023-10-31T22:37:50Z")

</div>

# Gemini 3f to 3g Changes

With the release of the Gemini 3g network we wanted to take a few moments to talk about the changes between the last iteration and this new version. Note that [our documentation](https://docs.subspace.network/docs/protocol/substrate-cli) is the source of truth for how to run our software and should always be checked carefully when changing versions and especially when changing network.

## UDP Communication

The latest node and farmer employ both UDP and TCP network communications. The implications are that you will need to update any port forwarding rules you may be using to ensure both communication protocols are enabled and CLI options in case you have customized them.

This is particularly important for Docker users as their `ports` configuration will need to be updated. Please check our example in [the documentation](https://docs.subspace.network/docs/protocol/substrate-cli#ii-installation) to see how they should look now.

Anywhere an address in this format `/ip4/0.0.0.0/tcp/30433` is being used will need to be checked to see if an equivalent `udp` parameter is now also required.

## No Farming While Plotting by Default

Historically, the farmer would farm (try and provide solutions from plotted sectors to earn rewards) while it was plotting. Now the farmer does not farm while plotting by default. This is to ensure that the plotting process occurs in the most efficient manner possible as fast as possible. This behavior can be changed by providing the`--farm-during-initial-plotting` flag to the farmer on the command line, but expect performance decrease and warnings if you do so.

## Dropped Execution Flag

The node no longer requires the `--execution` flag as the default `wasm` value is always used.

## Plotting Complexity

The complexity when plotting has been increased by a factor of 8 for security reasons. Early builds of what has become the Gemini 3f farmer would take up to 8x as long to plot a sector. Thanks to optimizations delivered by the core contributors, the process has been turbocharged and real-world plotting speeds seem to be coming out at considerably less than 8x the time it took on 3f. We’d love to hear about your experiences with the increased difficulty.

## Timekeeping

With the introduction of [Proof-of-Time (PoT)](https://academy.autonomys.net/subspace-protocol/consensus/proof-of-time#timekeeping), a new, optional role has been added to the node. This is timekeeping. Timekeepers supply the flags below and help [protect the security of the network](https://academy.autonomys.net/subspace-protocol/consensus/proof-of-time#timekeeping). Our hope is that those who can spare a high-performance core for the health and success of the project will help out by running a decentralized network of timekeepers.

`--timekeeper` - to become a timekeeper.

`--timekeeper-cpu-cores` - to specify which cores timekeeper should use rather than random cores. On 13900/K/F/KF/KS and 14900/K processors physical cores 5 and 6 are the fastest, so it is recommended to set this value to `8-11`, which corresponds to 4 logical cores behind those physical cores.

Read more on timekeeping in [our documentation](https://docs.subspace.network/docs/farming-&-staking/timekeeping).

## State Pruning Flag

We have been providing the `--state-pruning archive` pruning flag to the node up to this point, it is recommended to change it to `--state-pruning archive-canonical` in order to decrease node disk usage a bit.

There are many other features, enhancements and bug fixes in this latest incarnation of Subspace but the above are the ones that will need a farmer’s immediate attention as they migrate onto the new network.

---

<div class="post-metadata">

**Author:** ![Rabinovitch](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/rabinovitch/32/99_2.png) [@Rabinovitch](https://forum.autonomys.xyz/u/Rabinovitch)\
**Post date:** [November 1, 2023, 2:03am UTC](https://forum.autonomys.xyz/t/migrating-from-gemini-3f-to-gemini-3g/2084/2 "2023-11-01T02:03:49Z")

</div>

Okay, but how to migrate from 3f to 3g in a proper way? I mean, should we delete plots (I believe that yes), wipe or purge, or any other hints maybe?

---

<div class="post-metadata">

**Author:** ![Jim-Autonomys](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/jim-autonomys/32/2922_2.png) [@Jim-Autonomys](https://forum.autonomys.xyz/u/Jim-Autonomys)\
**Post date:** [November 1, 2023, 11:45am UTC](https://forum.autonomys.xyz/t/migrating-from-gemini-3f-to-gemini-3g/2084/3 "2023-11-01T11:45:32Z")

</div>

3g is a new network. 3f plots will not work on 3g. You can `wipe` your 3f node and plot to free up all the space it is using. Or you could resize your plot - the choice is yours. An explanation on how to `wipe` can be found in the **Switching to a new snapshot from older/different versions of Subspace** section of the docs [here](https://docs.subspace.network/docs/protocol/substrate-cli/#switching-to-a-new-snapshot-from-olderdifferent-versions-of-subspace).

---

<div class="post-metadata">

**Author:** ![Rabinovitch](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/rabinovitch/32/99_2.png) [@Rabinovitch](https://forum.autonomys.xyz/u/Rabinovitch)\
**Post date:** [November 1, 2023, 2:35pm UTC](https://forum.autonomys.xyz/t/migrating-from-gemini-3f-to-gemini-3g/2084/4 "2023-11-01T14:35:50Z")

</div>

> [@Jim-Autonomys](#):
>
> Or you could _resize_ your plot - the choice is yours

Will it replot all my existing plot files to 3g network specs?

---

<div class="post-metadata">

**Author:** ![Jim-Autonomys](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/jim-autonomys/32/2922_2.png) [@Jim-Autonomys](https://forum.autonomys.xyz/u/Jim-Autonomys)\
**Post date:** [November 1, 2023, 3:27pm UTC](https://forum.autonomys.xyz/t/migrating-from-gemini-3f-to-gemini-3g/2084/5 "2023-11-01T15:27:48Z")

</div>

It will not. The idea behind resizing 3f is that you _could_ tune the amount of storage you are allocating to each network as you squeeze the last few inventivized blocks out of 3f and get plotted on 3g. It’s an option. The same as wiping 3f and starting on 3g.

---

<div class="post-metadata">

**Author:** ![Rabinovitch](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/rabinovitch/32/99_2.png) [@Rabinovitch](https://forum.autonomys.xyz/u/Rabinovitch)\
**Post date:** [November 2, 2023, 4:18pm UTC](https://forum.autonomys.xyz/t/migrating-from-gemini-3f-to-gemini-3g/2084/6 "2023-11-02T16:18:04Z")

</div>

> [@Jim-Autonomys](#):
>
> Anywhere an address in this format `/ip4/0.0.0.0/tcp/30433` is being used will need to be checked to see if an equivalent `udp` parameter is now also required.

How about `--listen-addr`? By default there is no UDP mentions in node’s `--help`, as for `--dsn-listen-on`.

---

<div class="post-metadata">

**Author:** ![nazar-pc](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/nazar-pc/32/6_2.png) [@nazar-pc](https://forum.autonomys.xyz/u/nazar-pc)\
**Post date:** [November 2, 2023, 4:39pm UTC](https://forum.autonomys.xyz/t/migrating-from-gemini-3f-to-gemini-3g/2084/7 "2023-11-02T16:39:37Z")

</div>

`--listen-addr` doesn’t support UDP yet. Just open official docs and check what is in there, it should be correct.

---

<div class="post-metadata">

**Author:** ![Rabinovitch](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/rabinovitch/32/99_2.png) [@Rabinovitch](https://forum.autonomys.xyz/u/Rabinovitch)\
**Post date:** [November 2, 2023, 4:59pm UTC](https://forum.autonomys.xyz/t/migrating-from-gemini-3f-to-gemini-3g/2084/8 "2023-11-02T16:59:05Z")

</div>

![image](https://canada1.discourse-cdn.com/flex011/uploads/subspace/original/2X/4/476b9e728fca7d4e014c1dad29d1da9033c2c1ec.png)  
🤷‍♂️ Official docs. 🙂

---

<div class="post-metadata">

**Author:** ![nazar-pc](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/nazar-pc/32/6_2.png) [@nazar-pc](https://forum.autonomys.xyz/u/nazar-pc)\
**Post date:** [November 2, 2023, 5:48pm UTC](https://forum.autonomys.xyz/t/migrating-from-gemini-3f-to-gemini-3g/2084/9 "2023-11-02T17:48:34Z")

</div>

They are correct, we want users to expose both UDP and TCP port for all 3 port numbers because we want to use UDP/QUIC for Substrate as well, it just doesn’t support QUIC right now so we don’t take advantage of that. I have seen people still using old setups from 3f for 3g, so the earlier we add those ports to docs the more likely it is that users will have them forwarded on routers once we start taking advantage of that.

---

<div class="post-metadata">

**Author:** ![Rabinovitch](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/rabinovitch/32/99_2.png) [@Rabinovitch](https://forum.autonomys.xyz/u/Rabinovitch)\
**Post date:** [November 2, 2023, 6:02pm UTC](https://forum.autonomys.xyz/t/migrating-from-gemini-3f-to-gemini-3g/2084/10 "2023-11-02T18:02:54Z")

</div>

Got it, thanks! 20 characters )
