Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Efficient game updates

amos.me

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Efficient game updates

#21

Post by pjc50 »

Asooka wrote: post #20
yAnonymous wrote: post #19

Interesting, but I'd like more details on what's happening at the client. Take Steam for example. For some games, downloading the update takes seconds, but calculating diffs and extracting takes 10-20 minutes. That's great for Valve, because little bandwidth is used, but terrible at the client side. On top of that, the update process slows the rest of the system almost to a halt, because of all the hard drive activit…

> On top of that, the update process slows the rest of the system almost to a halt, because of all the hard drive activity As far as I'm aware, that's a problem only on Linux, because Windows has a desktop-grade IO scheduler tuned to interactive usage (whereas in Linux both the CPU and IO schedulers are written for maximum throughput).

Windows is quite capable of messing this one up as well; if your browser profile is on the same disk as you're doing something heavy, it'll end up blocking the browser while waiting to commit.

(Seems to be worst on Firefox)

Re: Efficient game updates

#22

Post by benchaney »

Asooka wrote: post #20
yAnonymous wrote: post #19

Interesting, but I'd like more details on what's happening at the client. Take Steam for example. For some games, downloading the update takes seconds, but calculating diffs and extracting takes 10-20 minutes. That's great for Valve, because little bandwidth is used, but terrible at the client side. On top of that, the update process slows the rest of the system almost to a halt, because of all the hard drive activit…

> On top of that, the update process slows the rest of the system almost to a halt, because of all the hard drive activity As far as I'm aware, that's a problem only on Linux, because Windows has a desktop-grade IO scheduler tuned to interactive usage (whereas in Linux both the CPU and IO schedulers are written for maximum throughput).

This doesn't match my experiences. Linux seems to handle this better because it has competent memory caching.

If this poses an issue anyway you could run steam using ionice.

Re: Efficient game updates

#23

Post by fivesigma »

ZeroClickOk wrote: post #5

I hope Blizzard guys learn something with this article. The Hearthstone android Update/installer is terrible...

Blizzard blew it from the moment they started downloading/syncing their games via BitTorrent - using their customers bandwidth to support games that they paid for.

Re: Efficient game updates

#24

Post by kuriho »

fivesigma wrote: post #23
ZeroClickOk wrote: post #5

I hope Blizzard guys learn something with this article. The Hearthstone android Update/installer is terrible...

Blizzard blew it from the moment they started downloading/syncing their games via BitTorrent - using their customers bandwidth to support games that they paid for.

How exactly did Blizzard "blow it" with this design decision?

Using their customers bandwidth to take off some load of their own patch servers during peak times is (imho) a pretty good use of BitTorrent. You can also quite easily disable this feature in their launcher app.

Re: Efficient game updates

#25

Post by oldrny »

hvidgaard wrote: post #11

Good article. As a note, I love how he uses hand drawn diagrams. I have yet to find any tool that allow me to draw diagrams as fast as I can do it on a piece of paper.

I used to use IPE [1] + GraphViz [2] to draw diagrams for assignments -- perhaps something similar could work for you?

[1]: https://en.wikipedia.org/wiki/Ipe_(software)

[2]: https://dreampuf.github.io/GraphvizOnline/

Re: Efficient game updates

#26

Post by [deleted] »

arjie wrote: post #10

The rsync example confuses me a little bit. If you add a single bit to the front, then all the bytes are shifted into different blocks and nearly none will hash to match. But if you add a single bit, rsync still performs well. Can someone explain why that difference from the explanation? The problem also applies to the binary delta. Adding a prefix will shift everything forward causing a diff in everything. Bsdiff so…

[deleted]

Re: Efficient game updates

#27

Post by Cogito »

I enjoyed this article a lot.

One thing that seemed glossed over, so I'm not sure if it's obvious for their use case, is the trade-off between compress once, distribute many times.

When looking at how long it takes to compress vs transmit, the optimisation was done to make the sum of both as small as possible - minimise(time(compress) + time(transmit)).

Instead it seems like you want to do is - minimise(time(compress) + expected_transmissions * time(transmit))

For any reasonable number of distributed copies of a game, it seems like this time to transmit will quickly come to dominate the total time involved.

I suspect, however, that the time to compress grows extremely quickly, for not much gain in compression, so the potential improvement is probably tiny even if you expect to be transmitting to millions of clients.

Post reply on HN