Starting on November 24th, a number of updates and improvements have been published to the Portal API Cherry Picker service:
Background
The Portal API is a service that enables the abstraction of PocketJS application stakes into the URLs that developers have come to expect from centralized RPC services. This service powers the Portal dashboard, which the majority of DApps are using to send their relays through the Pocket Network.
The Cherry Picker was the first Quality of Service measure introduced to the Portal API. Before the Sync Checker and other QoS measures, the Cherry Picker was the first and only code implemented to improve the session quality on the Pocket Network.
The Cherry Picker’s basic function is to rate node service by latency and error rate. It had a secondary function of removing nodes that returned constant errors because, at the time it was written, the Network was in a very different place.
The Network was young, node runners were inexperienced, and most of the nodes that served errors at that time only served errors. They were misconfigured nodes and should not be included in any sessions. The Cherry Picker used to mark these nodes as failures for an hour so that they could be re-checked for the next session.
Current Day
Today, we have other QoS measures that are in front of the Cherry Picker. The Sync Check is run first to make sure all nodes are in adequate sync for the session. This has the added effect of removing non-responsive nodes before they even reach the Picker.
Today, nodes that throw errors typically only do so when being temporarily overloaded or because the session rolled over. Those nodes are not failures and should be allowed back into the session once those errors have resolved.
However the Cherry Picker prevented that. With the recent updates, the Cherry Picker’s responsibility for error checking has been removed. Nodes that have temporary failures (usually due to no fault of the node) are now re-checked a few minutes later for re-inclusion into the session.
Latency Measurements and Ranking
In the previous version of the Cherry Picker, the latency ranking was very rough. It didn’t matter if your node was only slightly slower than the fastest node, you were always going to receive a lot fewer relays.
The distribution was such that if you were the 2nd ranked node in latency, you would receive 80% of the relays of the 1st ranked. The 3rd ranked would receive 60% and so on. There were some adjustments in that formula that took into account the error rate, but that was the basic weighting used.
In the new version, latency difference matters. If your 2nd ranked node is only a few milliseconds slower than the first ranked node, you will receive nearly the exact same amount of relays – weighting that more accurately represents real-world responses. The end result is faster service for Pocket Network clients and rewards more fairly distributed to Pocket Network node runners.
Example Latency Response from a Session
| Avg. Latency | Rewards % | |
|---|---|---|
| Fastest Node | 0.254 | 1 |
| 2nd Node | 0.258 | 1 |
| 3rd Node | 0.341 | 0.8 |
| 4th Node | 0.775 | 0.3 |
| 5th Node | 1.251 | 0.1 |
Distribution of Rewards Based on Relative Latency
