If you haven't already, I suggest you to read these two deep but understandable articles : https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking and http://fabiensanglard.net/quake3/network.php.
These explain why it's advised to use 'fixed interval' packet sending.
To be short, it's in fact mainly important for packets sent by the server.
Sending a packet has a fixed cost, and a network packet maximum size is about 1.5 KB.
So if you have for example 16 players on your server, each frame when you calculate movement for a player, naive code could send a update packet to each player after each movement resolution, so 16*16 = 256 packets.
If you have a framerate of 30, that's 7680 packets.
A better approach, is to create a buffer in each beginning of frame, concatenate in it your 16 calculated positions update, and then send them to your 16 players.
You now send only 480 packets by seconds for same results.
In the player-to-server case, that just means you should send, in the same packet a maximum of data, like; looked position, actions called this frame and so on.
About the second part of your question - the way I choose to reduce the lag sensation was to send this information to the server on each frame:
actual current position of player (used by server to check if server side and player side positions aren't too much desynchronized).
Estimated player position in 1 second : calculated by client: if the player doesn't change mouse direction and leaves the keyboard in its current state for 1 sec where will be the player? (we don't care about collisions)
If the player isn't moving, then his estimated position in 1 second is its current position.
The position he look at.
Each time the server receives this information it updates the future position and looked position, and the player entity eventually moves toward its future position.
Players are never exactly synchronized, but input response is instant (most important for me) and I found predicted positions to be accurate enough for me.