Hacker News Reader

Comment by woodruffw | Hacker News Reader

That's a typo. You can still see they're correct about the ratio (two "C"s for every three "A"s and "B"s).

There's no ratio. It's even across all of them, as long as the integer keeps incrementing. One more number (9) instead of stopping at 8 and there would be an even spread.

Not when the counter overflows back to 0. If it's a 3 bit counter, 0 is A again, not C.

The comment says a 32-bit signed int. Where is the 3-bit assumption coming from?

The comment starts with that assumption for the sake of a concise example. do you expect them to write the whole sequence out using a 32bit counter? :-D

Then it's irrelevant. The point is that the remainders are evenly distributed as the integer is incremented, with at most a single round being short. That's just how the math works.

"A single round being short" is exactly what they're talking about.

Edit to add: whether that's a big enough effect for the use case they're talking about, I don't know. This sort of thing is definitely significant in cryptographic code, though.

When you divide 2^32 across 3 machines, you get 1431655766, 1431655765, 1431655765. They're nearly identical, just an itsy bitsy bit different. This isn't going to cause one machine to have noticeably less load than the others.

That's not what's being discussed here though.

Then what is being discussed? I thought this thread was about 3 servers, of which one has lower load due to an int32 overflowing.

Reply on news.ycombinator.com