Hacker News Reader

Comment by andreareina | Hacker News Reader

Take a 3-bit counter:

    0->A
    1->B
    2->C
    3->A
    4->B
    5->C
    6->A
    7->B

A and B get hit three times while C only twice, so it will see 66% utilization compared to A and B

EDITED s/once/twice/ thanks CyberDildonics

View on HN

while C only once

You listed C twice

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.

Edited, thanks

That doesn't change anything... it's still round robin. You just stopped at an arbitrary number of 8 integers instead of 9.

It's not arbitrary, GP stated it was a 3 bit counter. In GGP (or something, not sure how far down in the thread we are), they were referring to a 32 bit int counter until overflow. If you bin each number from 0 to 2^32 - 1 by mod 3, you don't get 3 bins of equal sizes, 1 bin always comes out smaller.

Smaller by a single number at most, it's effectively insignificant. Not sure where the 3-bit counter assumption came from as the original post said 32bit signed int.

Reply on news.ycombinator.com