Boot UEFI mode slow
-
Please help
I’m using Boot Lagacy mode Speed 7-8GB/min
but
New Device force Boot UEFI mode Only Speed 2-3 GB/mini’m try update fog 1.5.8 to 1.5.9 it’s same
-
@KeanKung I doubt this is a general issue. Probably a particular hardware you see this happening, right? Please let us know which one.
-
Machine Dell OP3080 HDD & Latitude 3420 SSD it’s slow 3-4 GB/Min
it’s use UEFI Mode Only -
@keankung said in Boot UEFI mode slow:
Machine Dell OP3080 HDD & Latitude 3420 SSD it’s slow 3-4 GB/Min
Well this sounds like a hardware specific issue. Searching the forums for these I find a few hints on people using those but I don’t see any request for them being slower than other machines.
While 3-4 GB/Min is not super fast it’s not that bad either. Possibly some newer chipset which is not yet supported at full speed?!
-
Try updating the Kernel drivers? I’ve seen varying ipxe performance from different hardware. For example, I’ve seen ipxe boot faster on an Optiplex 7020 vs 3020 which is a newer model.
-
Hi, I know this topic is quite old but we are experiencing exactly same issue with Optiplex 3000 series.
On any other serie we deploy at between 7-8GB/Min and 15GB/Min (Depends on harddrives, cables, unicast multicast etc)
On 3000 series, we never go above 2.4GB/min in multicast and 4-5 in unicast.
It does not help a lot, but your are not alone.
-
Has anyone come to a solution for this problem.
We’re a school with over 60 of these Dell 3000 & 3080 units - with more to come.
Older Dell 3010, 7010, 790 units all run at higher speed, over 8Gb/min in legacy.
New Dell in UEFI slow, again between 2-3Gb/min.We’ve tried updating the Kernel & running latest Fog 1.5.10, same issue.
Is the problem the new chipset, NIC, or NVME drives??
Any help of pointers will be appreciated.
Thanks.
-
@miyaqub said in Boot UEFI mode slow:
Has anyone come to a solution for this problem.
I’m pretty sure that neither the developers or myself have one of these Dell 3000 systems handy to test. So they will rely on the user community to help debug this issue.
The issue/problem with the partclone speed, is that its a composite speed of timing or the fog server to read the file off from disk, send that file to the target computer, then the target computer to receive that file, expand it in memory and then write it to the disk. Any one of the steps in the sequence can cause a performance issue.
As you have seen, a 1GbE network link has a theoretical max bandwidth if about 7.5GB/min (assuming ideal and non realistic conditions). In practice if you are getting 6.1GB/min the entire process is working as intended and very efficiently.
So if you look at the problem logically. If you setup a test, from the same network cable. Test a 7010 (or older kit) and a Dell 3000. If the 3000 is slower you can probably rule out the fog server and network infrastructure as the problem. So that leaves something inside the 3000 as cause of the slowness. So if you look at the data flow now all you have left is the target computer intake of the image, expanding it in memory and writing it to disk as the potential problems.
To try to understand where out of the 3 is the problem, schedule a task for the target computer (capture or deploy doesn’t matter) but before you hit the schedule task button tick the debug checkbox. Now pxe boot the target computer. After several screens of text is displayed where you need to press enter to clear it, you will be dropped at the FOS linux command prompt. Of the three remaining steps, you can probably rule out the expanding the image in memory as the problem. So that leaves you will network intake of the image and writing to disk. I won’t go into the steps you need but you can look at this article about benchmarking FOG. https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast
So basically you use iperf3 to test network bandwidth between the target computer and the FOG server. Then test using dd to write a 1GB file to the hard drive (note you may need to create a partition and format it for a linux file system). But those benchmark hopefully tell us where to look.
-
Another thing to consider which I have observed in my environment is network congestion. If you are imaging on your production network, especially if the subnets aren’t segmented, you may experience slower than normal imaging speed. If your FOG server is connected to the network at 1Gbps, keep in mind that if you are trying to image 10 workstations connected at 1Gbps, the server will only be able to send/receive at 1Gbps. The more imaging that happens at once, the slower they will all be. That is why I have been looking into getting my FOG server connected at 10Gbps so that it can handle at least 10x1Gbps connections without slowing down.
