search

CommunityDragon / Data

A place for keeping and discussing additional data we plan to provide through CDragon.
47 stars 13 forks source link

Update patches.json #2

Closed Canisback closed 6 years ago

jjmaldonis commented 6 years ago

Thanks!!

Canisback commented 6 years ago

I put the date on when the server is up, and maintenance is not always the same time, hence not round number. Would it be better the put the time the server goes down and round it up to 30 minutes?

stelar7 commented 6 years ago

When the server is back up is when the other timestamps are (i think?), but since we round all the other numbers it makes sense to round the new ones aswell. (and the difference is only about 3min)

jjmaldonis commented 6 years ago

I'd prefer to be accurate rather than round, especially because rounding after computing the timestamps the way @Canisback did will result in errors in some cases. For example (and to use easy numbers), if the server comes up at timestamp ...151 and we are rounding to the nearest 50 seconds, this would round up to ...200. Then any match that starts between ...151 and ...200 would get labeled as having the wrong patch. That's not a huge deal, but it's something we can avoid. We could always round down I guess; that would be a solution.

The way I was computing these timestamps was by finding a set of matches whose start times were 1) just before and 2) just after a new patch. Then I'd pick 1) the match whose timestamp was the largest before the new patch hit, and 2) the match whose timestamp was the smallest after the new patch hit. Averaging these two timestamps gives a middle-time when the server should have been down. Doing this for multiple regions helped me narrow in on the correct time. I then rounded to the nearest 15 minutes, because the downtime of the servers is usually more than 30 minutes, but really I probably shouldn't have done this.

My opinion is that it doesn't matter whether we round or not. It's pretty much irrelevant. And therefore worrying about rounding is just a matter of whether you care about it enough to spend time on it. I personally don't want to put in the time to worry about rounding since it doesn't really matter to me. If you want to, that's fine, but don't make it more work for me than clicking the "Merge" button and saying Thanks! :)

I'm more concerned with the fact that we are now using 2 different methods to calculate these timestamps. Both have their drawbacks, and that means there can be inconsistencies in the numbers. But really, these numbers aren't incredibly accurate anyways and are mostly meant as a guide, so I'm not concerned enough to spend time on it.

stelar7 commented 6 years ago

I doubt that someone will start a match in the 3~ min difference from the times in the PR, but in that case we should rather specify a timestamp inside the downtime to garantee that its before the current patch?

jjmaldonis commented 6 years ago

Exactly

Canisback commented 6 years ago

For the record, for now I'm based on EUW server for up/down time. In some cases, there might have delays for specific server, should I begin to track up and downtime for each server? And as I keep timestamp for when the server goes down and up, getting a round timestamp from the downtime span should not be a problem.

jjmaldonis commented 6 years ago

should I begin to track up and downtime for each server?

Our decision in CDragon a while back was that keeping track of the timestamp for every server was more pain than it was worth (it's pretty hard to do that unless you are constantly monitoring the server somehow, and if your monitoring app goes down then you're screwed). So we decided that we were okay with the numbers being reasonably accurate rather than precise. I'd guess that most of the patch times are accurate to within 2-3 hours, and at most to within 12 hours. Over the course of a 2 week timespan, that's not too bad. Plus, the main reason for using this data is to pull matches for a specific patch, and when doing that the user can always check the match.version in the returned json to check if that match is for the patch they want.

That's a long way of saying 1) we didn't think we needed to be super accurate, in part because each match has it's own version that provides duplicate information, and 2) as a result we decided we weren't going to track up/downtime for each server and instead we would use the offset functionality that we are using currently.