For an action game, the going rate seems to be about 20-30 times a second. For an RPG, anything between 1/s and 10/s seems to be common.

Also, if you're using TCP, make sure you're turning on the SOL_SOCKET/TCP_NODELAY socket option.

How large are the packets? Are you maxing out your (upstream) bandwidth? Can you measure packet loss?

Also, if you have two clients, can you measure whether the CPU usage is actually causing delays?

You will need smoothing/interpolation/prediction for all cases if you want smooth motion (for a pong game, a simple velocity-based prediction and an IIR filter should work OK). For better results, simulate the game (visible) ball and the networked ball, or "ghost" (not normally drawn). For debugging, you'll draw both: the ghost is updated immediately from network data, and continues to run via the network-sent velocity. The game ball is smoothly IIR filtered to the ghost ball position (gameBallPos = lerp(alpha,gameBallPos,ghostBallPos), where alpha is < 1 (smaller values = smoother motion, but with more delay). Collision detection is performed for both balls.

Sending data at a fixed rate is a bad idea for at least two reasons. The first, is that under high network congestion situations, a constant send rate will prevent the network from quickly reaching stability (equilibrium). In some situations, if the data streams cannot throttle back, the network system will never recover (and the clients will be disconnected due to time out).

The second reason, is that without an adaptive and efficient send rate, the client experience will be diminished. A fast network can support extremely high send rates, providing users with little to no perceivable lag. A slow network requires updates to be throttled back, otherwise the network connection will collapse and have an effective data rate much lower than what would be possible had the stream been throttled back.

The history and theory of throttled network transmission is explained well in Congestion Avoidance and Control. While a game developer may not at first think they need to worry about congestion, it should be apparent after reading the paper that network game performance can be improved on both fast and slow networks by using the concepts and algorithms presented in the paper (I have used these concepts since 2001 (Xbox launch title) and the real-world results are excellent). If RakNet has an adaptive UDP send system, use it. If not, ask the developer if there are plans to implement one (otherwise, you can implement your own system, though it does take a bit of time and testing to get a good, working solution).

If you are using TCP, you'll need to monitor the TCP send queue (TCP will take care of throttled send rate for you). Thus, you can prevent the TCP send queue from overflowing by throttling back your sends (and increasing send rate when the queue level is low).

For testing network client+server code on a single machine: add a Sleep(0) or even a Sleep(1) to yield the thread+process (Win32 multitasking is not highly preemptive).