[...]<br><br>Hey Eric,<br><br>That's a lot for all your incomes.<br><br>I'll try to answer all your questions.<br><br>1°) Why do we need a particular behaving<br>My "cluster" is in a very particular network & power industrial environment.<br>
Those low-power nodes are yes, booted in the same time and they do have to load some content from a central server.<br>The network bandwidth is really low (100mbit) and each system have to load some content to boot as we are running diskless at that point.<br>
The last point is our "main" server is very very light so I'd like to not load it too much.<br><br>2°) Why I'm using a 30sec delay<br>While computing a random to sleep to avoid collisions, I have to insure that few systems aren't in the same time-stamp.<br>
Let's say a random 15s delay with 720 systems booting at the same time, if random thing generates too close bets (let's image an average distance of 7sec between systems), we'll face the collisions problems.<br>
So my first guess is 30sec is enough to avoid too much systems trying to download stuff at the same time.<br>This value will surely be changed while increasing our experience in our environment.<br><br>3°) Adding more randomization<br>
Agree with you, we have some improvements to do in the random() call and I think that's pretty efficient using part of the MAC address to generate some seed.<br>What do you think about using the cmos time too ?<br><br>
4°) GPXE integration<br>I perfectly understand my need isn't common at all and doesn't have to be integrated as it in gPXE.<br>That said, this patch would have been made with a default value of MAX_RANDOM_SLEEP_TIME set to 0 to disable this behavior.<br>
<br>Cheers,<br>Erwan<br>