thedupdup

Members
  • Content Count

    25
  • Joined

  • Last visited

About thedupdup

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I am working with quart websockets, the server sends out messages 40 times per second. But on the client, it seems most the messages are received at the same time. I have a suspicion that Nagle's algorithm is the cause. Does anybody know if this is true? If it is how can I disable it?
  2. That makes sense. Is there anyway to disable the head of line blocking? I would rather loose a couple packets than have them blocked. EDIT: I should also note that on the highest latency server (200 ms avg) the frequency is almost always 0
  3. I have multiple servers in multiple locations. I need to get the frequency at which the websocket messages are received. When I connect to a low-latency server, the frequency is normal (50 - 60 ms). But on high latency servers, the frequency sometimes is 0. I asked a similar question not to long ago, but the answer there was that the socket is buffering messages. I find this unlikely since it only happens on high latency servers. Here is the code responsible for handling the websocket: startTime = Date.now(); ws.onmessage = function (evt) { prevData = recivedData; var receivedMsg = evt.data; recivedData = JSON.parse(receivedMsg); const endTime = Date.now(); ms = endTime - startTime; startTime = endTime; if(msAvg == null){ msAvg = ms; } msAvg = Math.round(((msAvg * 5) + ms) / 6); id = recivedData.id; } ms is the frequency in milliseconds. How can I get to the bottom of this issue?
  4. I see what you mean now. But if I add to timeElapsed like in the stackexchange example timeElapsed seems to increase a bunch (the opposite of what was happening before).
  5. The delta average (when the tab is active) is around 16 milliseconds, the updateFrequency has a minimum of 40 milliseconds. I think we are missing the point of the question though: things only go wrong after the tab is inactive for some time. If you just load the page the values are fine, but when you switch tabs the timeElapsed variable is decreased a bunch. So if I loaded the page then switched to a new tab for 3 minutes, timeElapsed would be around -3000, this is not supposed to happen however.
  6. The frequency by itself is not the problem, its when i switch tabs the timeElapsed variable decreases a bunch (im not sure what this is caused by).
  7. No, if I do it like the stack exchange example, the timeElapsed will increase a bunch when the tab is not active. And delta will always be smaller then update frequency.
  8. Can you explain to me a bit better what a phase locked loop is in this context?
  9. The variable timeElapsed is for a lerp function. I haven't been able to get good results in any other way. I based the lerp function on this: https://gamedev.stackexchange.com/questions/102483/client-interpolation-for-100-serverside-game
  10. I have a counter that subtracts the delta each from and adds the update frequency from the server (at the same frequency) . Here is a simplified version of my code: (function loop(now) { var now = Date.now(); delta = now - Time; Time = now; timeElapsed -= delta; if(frameAvg == null){ frameAvg = delta; } frameAvg = (frameAvg + delta) / 2; counter += frameAvg; if(counter > updateFrequency){ timeElapsed += updateFrequency; counter -= updateFrequency; } console.log(timeElapsed); requestAnimationFrame(loop) })(0); When I load the page and take a look at console it is fine, timeElapsed is around 300. But if I switch tabs for a few minutes timeElapsed will then be far into the negative numbers (around -3000 if you leave it for a few minutes). I don't understand what the problem is, how can I fix it?
  11. Yes, it will go from a steady 60 to a 0 unpredictably. But the problem is all the time stamps on the messages are normal.
  12. The server sends updates around 20 times per second, is this too much? I also tried just printing Date.now(), some times two of the printed dates were the same.
  13. I still get 0 when I use a server running on localhost, I don't think its packet loss.
  14. Okay, I have ruled this out by attaching timestamps from the server to the packets, the timestamp difference is very consistent. This would not be so if there was a missing packet.