Hey,
Currently I have setup BePU as an Authoritative Server and running it at 60FPS. When my character is near 0,0 - 50,50 I update no problem every 100ms (sending 10 updates a second to client).... Once my Character hits 100,100 BePu is only updating him once every 200ms... when he hits 200,200 its around 300-400ms. Is there a reason for this? If so is there a setting I can set to stop this from happening? I'm extreme new to this so any help would be great.

There is nothing in the engine which would change update rates based on position, and individual objects do not have different update rates. The engine simulates a series of global time steps.

While not related to update rates, the deactivation system can put entities into a low cost state when they are stationary as an optimization. While sleeping, the entity will not fire most events including the Entity.PositionUpdated event. If the character is occasionally sleeping and this is how update rates are measured, this could explain the observation.

What part was measured to find the 300-400ms interval? Was it just the time between detections of state change by the player thread? Were both threads running at full rate while this was happening?

A few shots in the dark:
1) Make sure the player thread is running when it should.
2) Make sure the physics thread is running when it should.
3) Make sure the player thread reads of physics-related data are thread safe. By default, nothing is; if the Space is permitted to update while things are being read from it (or worse, things are being written to it), stuff won't work like it should.
4) Make sure the mechanism responsible for ensuring that thread safety is not interfering with execution significantly. Big contested locks around the entire physics update and around the player thread's execution are top suspects if the player thread's execution takes much time at all (Thread.Sleep within the lock could cause big problems).

Side notes:

I probably should use PositionUpdated event... not sure how it works as I haven't looked into it

I would not recommend the PositionUpdated in this case, actually. It will fire every single time step in which the character moves, which is far more frequent than network updates need, leading to most of the event invocations being ignored. Polling state on demand seems more natural in this use case.

The MoveSpeed scale will get normalized out; the MovementDirection is just direction, not magnitude. If you'd like to change the speed at which the character tries to move, use the CharacterController's speed-related properties. If you want to give clients the most up-to-date information about the character's state, you'll need to include both the character-level state like the MovementDirection as well as the entity-level LinearVelocity and Position. The character-level stuff describes what the character is trying to do (and will inform client versions of the characters to try the same), while the entity-level stuff describes what is actually physically happening.

Hey,
Thanks for all the information on the character controller. I figured it out it, It was in fact an issue when I was comparing new position with the old position (Old bullet physic's code). I just switched it to check Vector3's instead and all is well in the world. Thanks again for you quick and extremely informative reply.