Time required to receive a packet

Tomahawk · 2016-08-27 20:22:25

I'm trying to find out the time that elapses between an action happening in EE (i.e. a block being placed, or a player moving), and the packet produced by that action being received by the connected bot.

For instance, will a packet take 10ms to arrive on one day, and 110ms on another, or - more importantly - for two blocks placed consecutively, will the first packet arrive 21ms after the block is placed, and the other 18ms after? With what experimental precision could I reliably record the time elapsed between two actions? Does this time vary depending on the action?

I've found no convenient way to simultaneously do something in EE, and start a stopwatch.

Hexagon · 2016-08-27 20:29:56

Tomahawk wrote:

I've found no convenient way to simultaneously do something in EE, and start a stopwatch.

Would con.send(message) and stopwatch.start() then stopwatch.stop() suffice? I mean, there is a fraction of a fraction of a second for when the stopwatch has to be initialized but I wouldn't worry about that.

Swarth100 · 2016-08-27 20:51:17

Must actually test this.

My guess:

-Initialise the stopwatch
-Start Stopwatch
-Con Send a Block placement
-Detect the "b" message for block placement
-Stop the stopwatch

-Divide the resulted time by 2 (as tecnically we're sending and receiving)

Dunno, though how server latency might influece the outcome

Tomahawk · 2016-08-27 21:28:11

Hexagon wrote:

Would con.send(message) and stopwatch.start() then stopwatch.stop() suffice? I mean, there is a fraction of a fraction of a second for when the stopwatch has to be initialized but I wouldn't worry about that.

The problem with this is that it adds another uncertainty into the final recorded time: the time elapsed between executing the con.Send line and e.g. the sent block appearing in the world.

Swarth100 wrote:

-Divide the resulted time by 2 (as tecnically we're sending and receiving)

We can't assume that it takes the same amount of time to send a packet as it takes to receive it.

Triggering an action with con.Send won't work for the kind of precision I'm looking for.

Hexagon · 2016-08-27 21:41:22

Tomahawk wrote:

Hexagon wrote:
Would con.send(message) and stopwatch.start() then stopwatch.stop() suffice? I mean, there is a fraction of a fraction of a second for when the stopwatch has to be initialized but I wouldn't worry about that.
The problem with this is that it adds another uncertainty into the final recorded time: the time elapsed between executing the con.Send line and e.g. the sent block appearing in the world.

It would probably be better to use a packet sniffer to see exactly when the packet leaves your network, and then find the exact time it comes back (maybe Wireshark.) This only addresses the roundtrip time and not the individual components, though.

Out of curiosity, why are you measuring this? I did a quick test with some blocks (sent 1000 with no delays) and the PlayerIO protocol seemed to have buffered them automatically (no Thread.Sleep's), and all the blocks were written on the world.

Tomahawk · 2016-08-27 21:54:26

Hexagon wrote:

Out of curiosity, why are you measuring this?

▼Spoiler

Hexagon · 2016-08-27 22:08:37

Tomahawk wrote:

Hexagon wrote:
Out of curiosity, why are you measuring this?
▼Spoiler
I'm doing a race-type BAL where players speedrun minis as quickly as possible, and the fastest time is recorded on a sign. I need to know to what precision I can record a player's time, and therefore how reliably I can say that one player was faster than another.

You'd probably be better off getting a VPS for this, preferably one close to the PlayerIO servers (San Diego perhaps.) This would vastly reduce packet jitter (bad) and packet latency (bad).

For intra-race comparisons (player A and B do the same race) PlayerIO will output the "winner" in the correct order, but the times might be off. If you're doing inter-race comparisons the only thing I can think of is halving the round trip time. Maybe you could run traceroute to one of their servers to see an average latency. Before and after the race you could send a few blocks to playerio and get the round trip time and average those out.

EDIT: check out how the NTP protocol works (used to synchronize computer time with remote servers to a fraction of a second) http://stackoverflow.com/questions/1228 … tocol-work might be sort of useful.

Koya

den3107 · 2016-08-28 00:32:35

Tomahawk wrote:

Swarth100 wrote:
-Divide the resulted time by 2 (as tecnically we're sending and receiving)
We can't assume that it takes the same amount of time to send a packet as it takes to receive it.
Triggering an action with con.Send won't work for the kind of precision I'm looking for.

It's called calculating an average.
Technically you should do this ~1000 times, add all the measured times together (already divided by 2) and divide it by 1000 and you got a more reliable average. The more test packets you sent, the "better" the average.

I do think the initialization of starting to stop watch and stopping it etc. is taken into account when processing the actual time passed.

And yes, one second you might have a delay of 100ms, the next of only 10 (although this big of a difference is rather unlikely unless you already get lag spikes (not fps spikes) really often (unreliable internet provider)).

Off topic:
@ Hexagon:
Curse your avatar. Just kill it.

hummerz5 · 2016-08-28 00:38:40

I might not have read this whole thing

Can you have PlayerIO send a timestamp along with when it gets the packet? Then you can determine where the two trip times stand.

Tomahawk · 2016-08-28 01:02:45

den3107 wrote:

Tomahawk wrote:
Swarth100 wrote:
-Divide the resulted time by 2 (as tecnically we're sending and receiving)
We can't assume that it takes the same amount of time to send a packet as it takes to receive it.
Triggering an action with con.Send won't work for the kind of precision I'm looking for.
It's called calculating an average.
Technically you should do this ~1000 times, add all the measured times together (already divided by 2) and divide it by 1000 and you got a more reliable average. The more test packets you sent, the "better" the average.

That's called being patronising.

On top of that, you're still assuming that dividing by two is acceptable when neither the approximate send or receive times are known, and have no reason to be similar.

@Hexagon:
I'm not prepared to set up a VPS to run tests on.

@Humvee
I've never heard of packet timestamping in EE.

hummerz5 · 2016-08-28 01:05:53

^ They don't packettimestamp at all. But, playerio runs all its crap on the same-ish servers and connections (right?) the results should be comparable. OF course, if you want any sort of reliable in-time precision related to your connection with that room specifically, I've got nothing.

den3107 · 2016-08-28 13:17:15

Tomahawk wrote:

That's called being patronising.

I meant with that not to order you to do that, it was a completion of the action mentioned beforehand (the dividing by 2 thing) to make it more accurate.

Tomahawk wrote:

On top of that, you're still assuming that dividing by two is acceptable when neither the approximate send or receive times are known, and have no reason to be similar.

You can't know for certain what JUST the sent time is or JUST the receive time is, unless you indeed get that VPS/webserver/friend/whatever with a similar setup as the actual PlayerIO server, this including location, internet speed, machine you are sending and receiving messages from/to and more.

Now if we use some logical thinking... If you'd sent a package. It takes a certain route that takes a certain amount of time. Now obviously the response will attempt to take that same route (since it's the shortest), if not a slightly longer/shorter route (I assume giving you a faulty margin of max ~10 ms (worst case scenario, excluding lagspikes (because then it'd be ~100 for anywhere on the world)) when in Europe), meaning that both the sent time and receive time, are roughly the same, meaning you are perfectly fine to just take the average.

There is absolutely no way for sending and receiving packages to take a considerable difference in latency (again, keep the fault margin in mind), unless important infrastructure gets damaged (resulting in way longer routes) or the protocol magically being different between sending and receiving (meaning they would take completely different routes).

P.S. The reason why I'm certain the shortest path (TCP) and not a random path (UDP) will be taken is because packages always come in order, which isn't guaranteed when using UDP.
P.P.S. If you still don't believe the average stuff works (to a certain degree), then look around. It would still be your best bet of getting an average.

Also, just thought of this: You cannot give 100% reliable times for races.
Imagine: You are person A (receiving), and person B to F are players (sending).
Again imagine: You have a constant receiving latencyof 70 ms (expecting you're in Europe, dunno why).
B to F will have an unknown sending latency.
Aside from that, B can be right next to the servers and have a latency of 10 ms while D can be in Latvia and have the worst of internet providers and infrastructure (not saying Latvia actually has that) and have a latency of 300 ms.
Now technically the race would already be unfair! Since D starts the race 290 ms AFTER B, and his finish time will also be 290 ms LONGER than B's.
Conclusion. If you're not sure time estimation would be accurate enough to make it worth it with such small latencies (aside from that son-of-a-b████ D), then don't make the race at all, since it'll be an unfair race by the exact same small latencies.

God this post is a mess...

hummerz5 · 2016-08-28 13:29:03

^Your race point is interesting. Assuming a relatively constant latency, all you have to do is record the start time individual to that user (hit a coin e.g.) and the end time. Then both stamps are offset eaually.

Does UDP actually take the random route? I thought TCP and UDP operated over IP but TCP required the packet order, but UDP was just hit and miss?

Hexagon · 2016-08-28 14:24:14

Well, the problem with the internet is that you don't know which route your packet will take. These all add unexpected latencies to whatever you're trying to send/receive.

From a concrete standpoint, at least connect directly to your router, preferably the router with ethernet.

hummerz5

Tomahawk · 2016-08-28 15:42:28

hummerz5 wrote:

Your race point is interesting. Assuming a relatively constant latency, all you have to do is record the start time individual to that user (hit a coin e.g.) and the end time. Then both stamps are offset eaually.

My stopwatch will start and stop when the player hits a purple switch, and yeah - both will be offset. However, if they're offset by different amounts due to lag etc, the final time is always a little bit inaccurate. I'm attempting to find out this inaccuracy, which will let me set a reliable precision on the player times - i.e. 1.1s instead of 1.108ms.

So I tried this yesterday:
Approximate test setup

▼Image Link

I sat in there and held down the right arrow, and used a bot to start a stopwatch when I hit the first switch (or received the "ps" packet), and stop it when I hit the second.
[In the BAL there'll be a few hooks/some parkour/etc. between those two switches, and I need a high precision for things that will take less than a second to do (i.e. a single 1x1 hook).]

I got 108 results between 308ms and 356ms. After fiddling with a histogram, I found the most frequently occurring times were between 326ms and 333ms (54 of them), and the modal value was 327ms (occurring 15 times).

After removing outliers, the highest result was 349ms, the lowest was 310ms, and the mean value 329.7ms, which sits in the middle of the cluster of most frequent times. The difference between this mean value and the min/max values is about 20ms.

Perhaps, from the results of this test, I can measure my own completion times to a precision of 20ms, and so round the stopwatch time to the nearest 20ms. I'll need to run tests on other players in different countries (I'm in England) to see if their times have a much larger spread. Let's hope it doesn't go above 100ms, because 0.1s precision isn't very satisfying.

hummerz5 · 2016-08-28 16:10:39

lol while we're throwing UDP and TCP around, IIRC PlayerIO sometimes lumps your new messages together into one TCP packet, which means you could run the risk of unreliable tempo in that case (I think)

those outliers you remove could possibly be the undoing of whatever you're building

you might just have to give up on the precision you want. Am from the americas, for the record

Tomahawk · 2016-08-28 16:38:00

Welp, I tested the stopwatch again on a conveyor that takes a constant time to complete, and even rounded to 0.1s there were 2 and even sometimes 3 different possible results each run.

I'll have to limit myself to difficult minis that take at least 5 seconds to do, so that the uncertainty is only a small fraction of the overall time. Either that or rip this BAL idea.

Shame.

den3107 · 2016-08-28 21:24:56

May I ask, out of curriousity, why you're measuring time of real small minis anyway? Are those like checkpoints, or will it be a hundred races (randomly organised?) that just come real quick after each other?

hummerz5 wrote:

lol while we're throwing UDP and TCP around, IIRC PlayerIO sometimes lumps your new messages together into one TCP packet, which means you could run the risk of unreliable tempo in that case (I think)

I don't have any actual knowledge about this, so just dropping an assumption here:
I assume some games made in Player.IO actually are dependent on a "reliable tempo" and I generally think something like this is also something like "reliable uptime" or something.
Or perhaps those games are forced to add timestamps to their messages and I'm putting way too much thought into this...

hummerz5

hummerz5 · 2016-08-28 21:37:27

Tomahawk wrote:

Welp, I tested the stopwatch again on a conveyor that takes a constant time to complete, and even rounded to 0.1s there were 2 and even sometimes 3 different possible results each run.
I'll have to limit myself to difficult minis that take at least 5 seconds to do, so that the uncertainty is only a small fraction of the overall time. Either that or rip this BAL idea.
Shame.

More information might trigger the constructive people of the world, but your logic there seems sound. If you're going for overall times of one second, but you could be +- 1 second, you're not going to have anything useful.

As you said, something like five seconds would be better. Keep in mind the most extreme of your outliers of course; if you occasionally jump 2 seconds out of the five in either direction, you're still not going to have enough de facto (comparative?) precision.

den3107 wrote:

hummerz5 wrote:
lol while we're throwing UDP and TCP around, IIRC PlayerIO sometimes lumps your new messages together into one TCP packet, which means you could run the risk of unreliable tempo in that case (I think)
I don't have any actual knowledge about this, so just dropping an assumption here:
I assume some games made in Player.IO actually are dependent on a "reliable tempo" and I generally think something like this is also something like "reliable uptime" or something.
Or perhaps those games are forced to add timestamps to their messages and I'm putting way too much thought into this...

Perhaps the info they lump together legitimately came at the same time, and they buffer the output by a few milliseconds? Your "reliable uptime" consideration could fit here; they lower the buffer's delay to keep things hopping.

hummerz5 wrote:

Does UDP actually take the random route? I thought TCP and UDP operated over IP but TCP required the packet order, but UDP was just hit and miss?

Yes, me, that's how it seems to be. Sort of. Apparently UDP and TCP don't give a hoot about the path; they both operate on IP, which DOES somewhat not really care about the path.

Tomahawk · 2016-08-28 21:44:45

den3107 wrote:

May I ask, out of curriousity, why you're measuring time of real small minis anyway?

That's (or was) the intended BAL idea; to find who can do a single hook - or other simple mini - the fastest. The quickest time and the player who achieved it would be displayed on a sign next to the mini, and updated if someone beat their record.

Given the variation in received packet latency, it doesn't seem to be possible to accurately record players' completion times. If I continued anyway, the players closest to PlayerIO servers - or who lagged the least - would probably have an advantage over the rest, and it wouldn't be fair.

EDIT:
@Hummerz
Having thought about it, I don't think making longer minis would make the timer any more reliable, as the intention is that they'd be played over and over again until they were being completed pretty much as quickly as possible, at which point 0.1s or less might make the difference between fastest time and the second fastest - and I can't accurately record that difference.

hummerz5 · 2016-08-28 21:54:41

hey tomahawk that sounds like a new game suggestion: timer block. (Actually I bet it's been suggested for those race levels)... just have to get the switch-esque timer suggestion thread going.

But I disagree. Making longer minis still opens the door to more improvement issues; it'll take that much more time to actually achieve whatever level of perfection you envision.

Further, if we step outside the realm of fairness... you mention users play "over and over again" ... so, the unpredictable nature of network lag could also be a fun little factor... sure, the minis are 90% skill, but also 10% luck.

I'm not sure i have the words to rationalize this, but I'm guessing at some point your minis come down to luck of hitting everything perfectly while at a dead sprint. That in itself is rather attributable to luck. What's another layer of luck detached from the user's ability?

Tomahawk · 2016-08-28 22:17:46

hummerz5 wrote:

if we step outside the realm of fairness

=3

I could always say "to hell with it" and give players their times to 1ms precision, and it's true that if one player did a mini as fast as possible 50 times, one of those runs would have the least packet lag and they'd set their personal record.

Despite this, the next player's fastest runs could always be at least 10ms faster due to PlayerIO stuffs and TCP/IP thingies. Are they luckier, or is this not a distinct advantage which screws up the results?

Hexagon · 2016-08-28 22:19:37

I know your budget is tight, but Amazon has nano instances for $0.0065 USD/hour, and you get a free year trial for a micro instance. https://aws.amazon.com/blogs/aws/ec2-up … available/

This will reduce a lot of the uncertainty with network lag. If you want to, I could boot up an instance and tell you how the pings are.

hummerz5 · 2016-08-28 22:19:43

But I thought we took care of the whole changing delay thing? By getting a verified start and stop point, over many trials, the timing difference normalizes, right? Combined with the larger overall run time I don't think it'd be an issue.

Tomahawk · 2016-08-28 22:32:33

hummerz5 wrote:

But I thought we took care of the whole changing delay thing? By getting a verified start and stop point, over many trials, the timing difference normalizes, right? Combined with the larger overall run time I don't think it'd be an issue.

The runtime is small - it's small minis or nothing at all.

0_o The timing difference normalises for a single player, but not for all players. People lag by different amounts, and this ruins the timing.

Hexagon wrote:

I know your budget is tight

It's my patience and willingness to use a VPN which is missing. I cba, because my bots last a few weeks before I get bored and start another one. My project folder is like a graveyard for neglected ideas. ^^

Official Everybody Edits Forums

#1 2016-08-27 20:22:25

Time required to receive a packet

#2 2016-08-27 20:29:56

Re: Time required to receive a packet

#3 2016-08-27 20:51:17

Re: Time required to receive a packet

#4 2016-08-27 21:28:11

Re: Time required to receive a packet

#5 2016-08-27 21:41:22

Re: Time required to receive a packet

#6 2016-08-27 21:54:26, last edited by Tomahawk (2016-08-27 21:55:30)

Re: Time required to receive a packet

#7 2016-08-27 22:08:37, last edited by Hexagon (2016-08-27 22:10:01)

Re: Time required to receive a packet

#8 2016-08-28 00:32:35

Re: Time required to receive a packet

#9 2016-08-28 00:38:40

Re: Time required to receive a packet

#10 2016-08-28 01:02:45, last edited by Tomahawk (2016-08-28 01:06:49)

Re: Time required to receive a packet

#11 2016-08-28 01:05:53

Re: Time required to receive a packet

#12 2016-08-28 13:17:15

Re: Time required to receive a packet

#13 2016-08-28 13:29:03

Re: Time required to receive a packet

#14 2016-08-28 14:24:14

Re: Time required to receive a packet

#15 2016-08-28 15:42:28, last edited by Tomahawk (2016-08-28 15:44:36)

Re: Time required to receive a packet

#16 2016-08-28 16:10:39

Re: Time required to receive a packet

#17 2016-08-28 16:38:00

Re: Time required to receive a packet

#18 2016-08-28 21:24:56

Re: Time required to receive a packet

#19 2016-08-28 21:37:27

Re: Time required to receive a packet

#20 2016-08-28 21:44:45, last edited by Tomahawk (2016-08-28 21:54:57)

Re: Time required to receive a packet

#21 2016-08-28 21:54:41

Re: Time required to receive a packet

#22 2016-08-28 22:17:46, last edited by Tomahawk (2016-08-28 22:18:43)

Re: Time required to receive a packet

#23 2016-08-28 22:19:37

Re: Time required to receive a packet

#24 2016-08-28 22:19:43

Re: Time required to receive a packet

#25 2016-08-28 22:32:33, last edited by Tomahawk (2016-08-28 22:33:59)

Re: Time required to receive a packet

Board footer