You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, everything works perfectly when we run the mixnet across one (or even two) continents. For example, running several nodes in Europe and another in Toronto works well, or at least well enough that we do see a small spike in latency but nothing unexpected. We can fire up a client and run about 1,000 packets per second (pps) through the network without any trouble.
However, when we add nodes in places that are farther away from the main cluster, e.g. in Tokyo or Australia, we see huge performance degradations that we don't expect. We see about 20 pps. The really interesting thing is that once we shut down the client, Sphinx packets still dribble out of the network for a very long period of time (measured at 11 minutes). This is obviously much, much more than we can account for by round the world packet transmission.
We have been poking at it and have fixed one thing related to concurrency. But the overall problem still persists. So we'll need to keep poking at this one. We'll document our experiments in this issue until it's resolved.
The text was updated successfully, but these errors were encountered:
At the moment, everything works perfectly when we run the mixnet across one (or even two) continents. For example, running several nodes in Europe and another in Toronto works well, or at least well enough that we do see a small spike in latency but nothing unexpected. We can fire up a client and run about 1,000 packets per second (pps) through the network without any trouble.
However, when we add nodes in places that are farther away from the main cluster, e.g. in Tokyo or Australia, we see huge performance degradations that we don't expect. We see about 20 pps. The really interesting thing is that once we shut down the client, Sphinx packets still dribble out of the network for a very long period of time (measured at 11 minutes). This is obviously much, much more than we can account for by round the world packet transmission.
We have been poking at it and have fixed one thing related to concurrency. But the overall problem still persists. So we'll need to keep poking at this one. We'll document our experiments in this issue until it's resolved.
The text was updated successfully, but these errors were encountered: