Can any 1 tell me how to find the lag time in client side?
I am creating a networking game for a webplayer..!!


  • PhotonNetwork.GetPing()
  • I thought it was related with PhotonNetwork.sendRateOnSerialize ?
    Because if PhotonNetwork.sendRateOnSerialize is at 10 but GetPing is at 20ms, the lag should be Max(1/10, 20) = 100ms ?
  • 20ms is the time it takes from client to server, thats what ping is all about.

    Its not the actual time a message will need until it is received by the server on average or in worst case (yours would be worst case) as that is totally depending on when you issue the message etc. If you issue it 0.1ms before the send of the next batch it would be 20ms for example
  • The question is all about the lag time for a client, not only his ping to the server.
    I definitely think that the sendRateOnSerialize should be taken in account, and furethermore, a timer should be placed in OnPhotonSerialize to ensure the latency. Because for exemple, even if you set sendRateOnSerialize at 10, you still can send 5 packages per seconds (for performance reasons in the client-side or server-side), or if you're unreliable some packages can be discard, and if you're reliable some can be slowed.
    Unfortunately, it seems that the worst case is at too many times the real case (it's not 0.1ms but 0.1s in my exemple).

    Edit : sendRateOnSerialize is the number of time per seconds a package is delivered, or the delay in ms between each package ?
  • sendRateOnSerialize is both. its the fixed rate at which the packets are sent.

    And the command is called getPing not getLatency which would be what you want. Cause just the 1 way information is not latency nor reflecting the impact of the 4 way (client -> cloud -> master client -> cloud -> client) architecture with master clients in any form. Ping only gets you information on client -> server
  • dreamora wrote:
    sendRateOnSerialize is both. its the fixed rate at which the packets are sent.
    The unit is important. If it's the number of time a packet is send by second, well if someone sets it to 10, client send a packet every 100ms (in a perfect world). But if it's the number of ms between each sending's packet, then it's every 10ms... it's definitely not the same.

    Agree with you about getPing (anyway ping should be "client->server->client" -where client is the same-, and not only "client->server"), that's why I try to complete Tobia's response...
  • The number that you get in GetPing() is the roundtrip time! It measures the network time from sending something to getting the fitting reply (so it is measured only for reliable stuff that is acknowledged)...

    sendRateOnSerialize is commented.
    It should say that it's the number of sends per second, if I'm not mistaken.

    The rate is a simplification of sending stuff. You don't have to think about and it still works. If you care to think about it, you will come up with solutions that fit your game's needs better than a framework created with simplicity in mind.
    As simple improvement, sending should be done directly after the OnPhotonSerialize calls are done. This reduces client side lag.

    From there on, the options to optimize this are more or less endless. Let us know what you could make out of the code :)
  • After a quick analyze of PUN, "OnPhotonSerializeView" is called in "Update()" with a timeout calculated like this :
    TimeForNextSerializeCall = TimeOfPreviousCall + 1000/PhotonNetwork.sendRateOnSerialize

    So there is a call's approximation which depend of your FPS. Say you have 60 FPS and sendRateOnSerialize is at 10, every 6 frames a call is made : perfect. But if your FPS is at 55, some calls are dismissed.

    To get the real "average" value of sendRateOnSerialize, I will try something like this...
    private var startingTime:double	= 0;
    private var numOfTime:float	= 0;
    private var RealSendRateOnSerialize:float	= 0;
    function OnPhotonSerializeView(stream : PhotonStream, info:PhotonMessageInfo){
    		startingTime	= PhotonNetwork.time;
    		RealSendRateOnSerialize = numOfTime/(PhotonNetwork.time-startingTime);
    ...and from there you have to interpolate movements back of laggingTime ms...
    //pingA=>ping of the player sending data
    laggingTime = Mathf.Max( Mathf.Max(pingA, PhotonNetwork.GetPing()), 1/RealSendRateOnSerialize);//in ms
    ...or player's movements will be jittery.

    Am I right, or it's just crazy stuff ?
  • I tried the method described above, and I run into strange issue.
    I set PhotonView on Unreliable and PhotonNetwork.sendRateOnSerialize at 15.
    I test the system with someone in Algeria (because I know his connexion is weird), and by computing the number of time OnPhotonSerializeView is called, I found that his RealSendRateOnSerialize is around 12/11/10 (I recalculate the value every seconds). It feels ok, some packets are lost or not send, but that's what I waited for.

    But when I make the difference between timestamp returned by OnPhotonSerializeView, and my PhotonNetwork.time, it is between 230 and 300 ms, and the longer he stays in the room, the higher this difference increase.
    His ping is around 120 +/- 20, and it seems stable.

    That's odd, because in this configuration, PhotonNetwork.time-info.timestamp should return something around 1/10, or his ping, ie 100ms or 120ms.

    Is there any problem with PhotonNetwork.time and the way it is syncronized ?

    I search and find this topic :

    Is It possible to check values of PhotonNetwork.time across the differents players ?
  • I never checked PhotonNetwork.time - info.timestamp but if the result is increasing, then it's worth checking that.

    But: The value is expected to be higher than regular ping, as it includes local lag of both players (sending and receiving). It can be reduced by being smarter with sending and dispatch more often (down to every frame).
  • What is a local lag for you ?

    Edit : I think you mean performances issues for players, ie if there is peaks in performance.
    Also I will try to minimize my project in order to make a repro case.