Hello! This situation started about a day ago, I noticed in my dashboard that my connections were unstable, and afterwards my connection to EU is back to non-EllaLink speeds. The route from my computer to the node is Mudfish’s responsibility, correct? If so, please look into this issue, the difference between EllaLink and the fallback route is very significant in a game with netcode as bad as FFXIV.
Hello! Thank you for your feedback.
To clarify, the route from your computer to the first Mudfish node is not determined by Mudfish. It is actually controlled by your local ISP and their upstream ISPs. Therefore, any routing changes (like shifting away from the EllaLink route) happen at the ISP level, which is unfortunately out of our control.
Because of this, the best approach you can take right now is to manually test various Mudfish nodes to find the most stable route for your connection. Let us know if you need any help with testing!
1 Like
What about if I choose a nearby node such as Buenos Aires or San Paolo, can Mudfish route me through EllaLink if the destination server is in EU in that case? In several years using Mudfish, the performance I’ve had from those nodes has never been anywhere near optimal.
Yes, but Mudfish controls only the relay chain. In Advanced Mode, choose a South American node first and an EU node second. Mudfish cannot force the SA→EU leg onto EllaLink; each node provider’s BGP chooses the physical route and it may change. Your EU item currently has São Paulo (Amazon EC2) and Germany (Linode) selected in Multi-Path. For a controlled test, switch to Advanced Mode, select that pair manually, restart Mudfish, and compare RTT/loss with other SA/EU pairs.
1 Like
Yes, for some reason that SA node seems to be the only one that’s using EllaLink at the moment, and only for Linode destinations. However, the hop to San Paolo adds a 33ms delay that doesn’t exist when routing is working properly. Thanks for the information though!
1 Like
Update: The EllaLink route from San Paolo Amazon EC2 seems to be gone as well. As a corporate client (to the companies hosting nodes) whose business is to deliver faster routes to end users, isn’t there anything Mudfish can do about the issue?
Another update: The EC2 route is restored now, but my question remains.
Thank you for the update. We can report the routing regression and provide node-to-node traces to the affected hosting providers, but Mudfish cannot set their BGP policy or force EllaLink; the provider ultimately decides its upstream route. We’ll review the affected SA→EU pairs. Meanwhile, please use the lowest-RTT direct EU node shown under Today’s Path, since the current SA→EU combinations do not show a latency advantage.
1 Like
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.