Don't want to dive into if we have issues with please waits or not. But there's some technicality here to understand: The speed of your connection is mostly irrelevant. It does not matter if you are on a 1MBit/second, 16MBit/s, 25MBit/s or 1ExaBit/second connection. As long as the speed is enough to cope with the amount of data Ryzom sends to your end (and vice versa) speed is no issue. And Ryzom was designed for a time ten years ago where most people were stuck on an ADSL line with a 1MBit/s downlink and a 192kbit/s uplink.
What is important is latency and stability.
Speed really is throughput: Data per time. Latency how long it is for the bits to reach their destination. You can have a 1000Mbit/s throughput, but a latency of 1 second. If you want to download a movie, throughput is what you care about. If you want to play games you need a low latency in both directions, so that the game server can quickly react to your keystrokes and you can quickly react on new information send by the server.
Latency is what you can measure with a "ping". It is often called the "roundtrip" time. The time it takes for a packet of data to travel from you to the server and then receive the server's response. Since those tests are done with a few bytes (e.g. 512 bytes), the ping time (latency) does not really depend on your having a 50MBit/s connection.
Stability is the other thing of importance and is not easily measured. There's a tool called "traceroute": Like ping it tells you how long it takes for your data to reach the destination. But it also lists the "hops" in between. You're never connected to the Ryzom server directly (with a 1-1 cable link), there's always some hardware in between. This is the route from your computer to the Ryzom server. The internet is notoriously unstable. And it is designed to cope with that. As a result, every now and then the route your data takes does change. This can lead to unexpected, brief delays. It can cause the Ryzom server to "please wait" you.
Your internet provider is also likely to do traffic shaping. Ryzom's udp packets may be the first the carrier or the internet provider is dropping - if you're unlucky. Consider internet telephony or video conferencing, or life streaming. For all three applications it is important that no data traffic is lost or delayed. Also, providers earn extra money with these services. So this is usually prioritized. ftp and http data is probably the least important, and is often dropped - web browsers and servers will happily retry 100ms later and users often do not care. Ryzom's udp packets might be treated by those automatic traffic shaping algorithms as medium to high priority real-time gaming packets, or they might be very low priority because Ryzom is a fairly unknown and unimportant application to the providers. We'll probably never know.
One other background information: Ryzom uses such udp packets because they are smaller, and carry less overhead. At one time they were ideal for a crowded internet where realtime information had to be exchanged. Unfortunately the effectiveness comes at the price of having no guaranteed delivery. In other words: If a udp packet gets dropped/lost by the network, the Ryzom server will not resend the information, and you client won't either. Lost packets could e.g. explain the "rubberbanding" we see occasionally. Don't take me wrong: I don't know if that's the root cause, it's just one of many possible explanations. Most of the internet works with tcp packets these days. If network equipment drops one, it will be resent. For games and other realtime applications, tcp often is ineffective because resent information might already be outdated.
To make a long story short: If you experience lots of "please waits", ask in universe channel. If others experience the same, it's likely either the Ryzom server's fault (software or hardware) or the network connection near the server. If you're the only one it may be that you just lucked out on the internet connection. You could do a traceroute when it happens, and then later again when it works well, and see if you can spot a difference.
If you have constantly "please waits" (for longer than an hour) you might want to monitor all incoming and outgoing Ryzom data with a tool such as Ethereal (Wireshark) or similar and analyse if there are differences between good and bad times. But this is not for the uninitiated I guess.
I apologize for the rambling...
What is important is latency and stability.
Speed really is throughput: Data per time. Latency how long it is for the bits to reach their destination. You can have a 1000Mbit/s throughput, but a latency of 1 second. If you want to download a movie, throughput is what you care about. If you want to play games you need a low latency in both directions, so that the game server can quickly react to your keystrokes and you can quickly react on new information send by the server.
Latency is what you can measure with a "ping". It is often called the "roundtrip" time. The time it takes for a packet of data to travel from you to the server and then receive the server's response. Since those tests are done with a few bytes (e.g. 512 bytes), the ping time (latency) does not really depend on your having a 50MBit/s connection.
Stability is the other thing of importance and is not easily measured. There's a tool called "traceroute": Like ping it tells you how long it takes for your data to reach the destination. But it also lists the "hops" in between. You're never connected to the Ryzom server directly (with a 1-1 cable link), there's always some hardware in between. This is the route from your computer to the Ryzom server. The internet is notoriously unstable. And it is designed to cope with that. As a result, every now and then the route your data takes does change. This can lead to unexpected, brief delays. It can cause the Ryzom server to "please wait" you.
Your internet provider is also likely to do traffic shaping. Ryzom's udp packets may be the first the carrier or the internet provider is dropping - if you're unlucky. Consider internet telephony or video conferencing, or life streaming. For all three applications it is important that no data traffic is lost or delayed. Also, providers earn extra money with these services. So this is usually prioritized. ftp and http data is probably the least important, and is often dropped - web browsers and servers will happily retry 100ms later and users often do not care. Ryzom's udp packets might be treated by those automatic traffic shaping algorithms as medium to high priority real-time gaming packets, or they might be very low priority because Ryzom is a fairly unknown and unimportant application to the providers. We'll probably never know.
One other background information: Ryzom uses such udp packets because they are smaller, and carry less overhead. At one time they were ideal for a crowded internet where realtime information had to be exchanged. Unfortunately the effectiveness comes at the price of having no guaranteed delivery. In other words: If a udp packet gets dropped/lost by the network, the Ryzom server will not resend the information, and you client won't either. Lost packets could e.g. explain the "rubberbanding" we see occasionally. Don't take me wrong: I don't know if that's the root cause, it's just one of many possible explanations. Most of the internet works with tcp packets these days. If network equipment drops one, it will be resent. For games and other realtime applications, tcp often is ineffective because resent information might already be outdated.
To make a long story short: If you experience lots of "please waits", ask in universe channel. If others experience the same, it's likely either the Ryzom server's fault (software or hardware) or the network connection near the server. If you're the only one it may be that you just lucked out on the internet connection. You could do a traceroute when it happens, and then later again when it works well, and see if you can spot a difference.
If you have constantly "please waits" (for longer than an hour) you might want to monitor all incoming and outgoing Ryzom data with a tool such as Ethereal (Wireshark) or similar and analyse if there are differences between good and bad times. But this is not for the uninitiated I guess.
I apologize for the rambling...