I'm trying to image a lab's worth of new Dell 7680 laptops which won't talk
to our Ghost server. I'm using the image master as the server and
massively deploying via bittorrent to the clients. So far I've done eight at a time and found each
client says it has 2 peers. Only two clients will receive data at a time,
and when the first two finished, everything else froze for about twenty
minutes. Eventually the others completed, about the same time I added and
removed another client, not sure if there's any correlation.
Is there a way to remove the apparent two peer cap, or is that just how
this works?
Thanks.
(edited to fix the completely wrong info I wrote the first time)
The machines in question have the resources to handle more peers/connections than 2, so it would be nice to be able to up that limit to allow the entire swarm to progress faster.
Is there a way to do that without editing the source?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I ran test sessions with four machines - one server and three clients. With the latest version they capped their peers at two and one of the clients took about 60% longer than the others.
After repeating the same setup with 3.1.1-27 the clients all eventually showed three peers and finished in basically the same amount of time.
It looks like rolling back to a version where the ezio_add_torrent scripts don't have the connection/peer limits was likely the fix.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, I'll try it next time (hopefully not until August for these particular devices). I finished the initial imaging job yesterday using the current version. I couldn't really detect a pattern, some of the clients would complete in twenty minutes, others took three and a half hours.
My first day with it I was skipping mounting the Clonezilla image directory, I only saw two clients out of seven passing data at a time, all of it download. Yesterday I used the RAM disk option, and out of eight clients, four would be passing data up and down. Might be coincidental, but tech has made me superstitious.
On the balance it worked really well, and absolutely saved me more time than I can even think about without getting queasy.
I'm going to be using this again for sure. Thanks! (And thanks for the reply)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, ezio was updated.
Please give testing Clonezilla live >= 3.1.2-11 or 20240227-* a try: https://clonezilla.org///downloads.php
Please let us know the results. Thanks.
Steven
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm trying to image a lab's worth of new Dell 7680 laptops which won't talk
to our Ghost server. I'm using the image master as the server and
massively deploying via bittorrent to the clients. So far I've done eight at a time and found each
client says it has 2 peers. Only two clients will receive data at a time,
and when the first two finished, everything else froze for about twenty
minutes. Eventually the others completed, about the same time I added and
removed another client, not sure if there's any correlation.
Is there a way to remove the apparent two peer cap, or is that just how
this works?
Thanks.
(edited to fix the completely wrong info I wrote the first time)
Last edit: David Benston 2024-02-22
(I'm looking at this issue with OP)
Following the trail through
sbin/ocs-ezio*and ezio'sezio_add_torrent*.pyI believe each script hard-codes the peer and connection limit to 2:https://github.com/tjjh89017/ezio/blob/master/utils/ezio_add_torrent.py#L28-L29
https://github.com/tjjh89017/ezio/blob/master/utils/ezio_add_torrent_seed.py#L29-L30
The machines in question have the resources to handle more peers/connections than 2, so it would be nice to be able to up that limit to allow the entire swarm to progress faster.
Is there a way to do that without editing the source?
Ideally, connection limit to 2 will be the best in theory.
But it seems it not the best choice if we leave the BT swarm running on their own.
I will check if we could meet the theory.
Thank you for the report.
I had reverted the commit.
Steven will create a new release.
So how about older version of Clonezilla live, e.g., 3.1.1-27?
https://sourceforge.net/projects/clonezilla/files/clonezilla_live_stable/3.1.1-27/
Does it work for you?
Steven
I ran test sessions with four machines - one server and three clients. With the latest version they capped their peers at two and one of the clients took about 60% longer than the others.
After repeating the same setup with 3.1.1-27 the clients all eventually showed three peers and finished in basically the same amount of time.
It looks like rolling back to a version where the
ezio_add_torrentscripts don't have the connection/peer limits was likely the fix.Thanks!
Thanks for your feedback.
OK, we will try to fix this issue recently.
Steven
Thanks, I'll try it next time (hopefully not until August for these particular devices). I finished the initial imaging job yesterday using the current version. I couldn't really detect a pattern, some of the clients would complete in twenty minutes, others took three and a half hours.
My first day with it I was skipping mounting the Clonezilla image directory, I only saw two clients out of seven passing data at a time, all of it download. Yesterday I used the RAM disk option, and out of eight clients, four would be passing data up and down. Might be coincidental, but tech has made me superstitious.
On the balance it worked really well, and absolutely saved me more time than I can even think about without getting queasy.
I'm going to be using this again for sure. Thanks! (And thanks for the reply)
OK, ezio was updated.
Please give testing Clonezilla live >= 3.1.2-11 or 20240227-* a try:
https://clonezilla.org///downloads.php
Please let us know the results. Thanks.
Steven