FOG : PXE slow transfert



  • Hi guys,

    Installing fresh Ubuntu 14.04 on ESXI 5.5 with a Lenovo server AND a brand new Lenovo i5 PC. Installing last version of FOG 1.0.1. First i got a problem with the tftp service who’s dont start with the pc, need to restart sometime coming up something no … anyway i see a lot of post and look to delay the service start.

    The main problem is the speed and i cannot figure why.

    Booting on pxe on 3-4 differents PC and on both server isolated on a HP 1810-24G switch.

    Booting on PXE and loading Hiren v14 (2G iso file) it’s take 4m12 with 1000 switch and 1000 NIC on the pc (try 4 diferent pc and 2 differents server 1VM/1Native)

    Connecting to the TFTP server with Filezilla on Windows tranfering the 2G iso, its take 20 seconds on both server.

    Why the PXE transfert speed is so slow ? when trying to load an iso image.



  • That’s wild, I’m on a Dell PowerEdge R900 ESXi, these are my specs.

    PowerEdge R900 4 X 6 Hex core (24 Cores)
    128Gb memory in failover mode ( Shows 64Gb)
    H700 Raid on a MD1000 3Tb X 4 Raid0 ( Cloned nightly as it is RAID 0 ) 7200RPM SATA III
    ESXi 5.5 U2
    Using Fog 1.2.0 Ubuntu 13.10 X64 ( 6Gb memory, 2 Virtual Sockets, 2 Cores Per Socket )
    Brocade 1Gb Layer 3 switch

    Fog seems fast, no issues uploading and downloading images. I can deploy between 4-5 Gb Per Minute.
    Uploads are now slower, but I’m at max compression as I have a ton of images. I need the deploy speed fast after I create the master image. When I was at default my upload was about 1.5 to 2Gbps. At max I’m sitting just under 1Gbps

    However my FTP is maxed at 100Mbps, everything else runs at 1000Mbps ?

    I can live with it as everything else seems great. However when I figure whats up with the FTP transfer speed I’ll relay it in hopes it may help ?

    Booting to Hirens takes about 20 seconds at most Hirens 15.2 Restored( 2.7Gb ) Hirens maxes my brocade switch out.

    Here is how I boot to ISO in advanced boot

    :hirens
    initrd http://10.10.10.1/ISO/hirens.iso
    chain memdisk iso raw ||
    goto MENU

    Hope it helps !


  • Senior Developer

    @Cliff Williams,

    Every environment is different. I too experience little problems using ESXi and also I use LSI Logic Parallel SCSI controlelrs, though I use E1000 for my NIC.

    It’s all a matter of preference and should really be.

    That said, there was a period where the LSI drivers weren’t included in the kernel. This has now been fixed in every kernel I release. So hopefully, from a pure imaging standpoint, this is no more an issue.



  • @Jaymes Driver, post: 28846, member: 3582 said:

    Don’t use VMWare, FOG doesn’t exactly like VMWare SCSI drivers or the nic cards for that matter. The NIC is not so much of a problem as the SCSI drives are, and this causes a slowness with FOG.

    You can take my recommendation with a grain of salt, I’m not climbing on a soap box to claim the issues doesn’t exist but rather try different platforms of visualization before you rule the issue as a problem with FOG, please.

    I had FOG installed on ESXI and I experienced nothing but slowness and problems in my network. We haven’t the licensing and I haven’t the understanding of ESXI to change the settings to better work with FOG.

    I have not had good experiences with FOG and ESXI.

    I know your not on a soap box an all but I have had excellent performance with FOG on ESXi. No issues with SCSI drivers or NICS. I used CentOS 6.4 to 6.5. I always use the LSI Logic Parallel SCSI controller and VMXNET3 NIC. Yum Update right after install of the OS. We run a master FOG server and 4 remote storage nodes all on ESXi.



  • If you would like to DEV on a ESXI server i can provide you a server with a PPTP VPN. I will try with a different switch on my Lenovo I5 Workstation just to be sure it’s not network hardware related.


  • Developer

    Don’t use VMWare, FOG doesn’t exactly like VMWare SCSI drivers or the nic cards for that matter. The NIC is not so much of a problem as the SCSI drives are, and this causes a slowness with FOG.

    You can take my recommendation with a grain of salt, I’m not climbing on a soap box to claim the issues doesn’t exist but rather try different platforms of visualization before you rule the issue as a problem with FOG, please.

    I had FOG installed on ESXI and I experienced nothing but slowness and problems in my network. We haven’t the licensing and I haven’t the understanding of ESXI to change the settings to better work with FOG.

    I have not had good experiences with FOG and ESXI.



  • FYI : I continu some test to try to understand where is the problem.

    I boot a Fresh install of Windows 2012 on the same ESXI server than the FOG (Unbuntu 14.04 + FOG 1.0.1). The download URL in the Windows 2012 (with internet explorer) work like a charm. Goiing to PXE the iso download take 6 minutes. This test prove this is not a hardware switch problem related.


  • Senior Developer

    @YanViau, post: 28803, member: 24420 said:

    im the network admin and i dont put any limitation on the switch … thx for your help.

    We don’t put any configuration on apache. It downloads and installs, and we copy over the web gui files, that’s it. No configuration on apache.

    We, do however, generate the FTP file on the fly. Though you state this is perfectly fine.

    I don’t know where your issue lies then. Do you only have one switch? Is FOG Server hosting other web pages? Have you tried packet tracing to see if you can find out what’s happening?

    FOG hasn’t made any configuration changes within apache. It, also, hasn’t set any restrictions for http traffic on your network.



  • im the network admin and i dont put any limitation on the switch … thx for your help.


  • Senior Developer

    So my thinking YanViau is this isn’t specifically a FOG issue. I’d check with your network admin’s and find out if maybe they have bandwidth limiting within your switches for http traffic?

    It sounds to me that if ftp is fast, but http is slow as you stated above, that it’s a network problem, not something FOG is doing (or not doing) specifically.



  • With the nic boot, dhcp wait, pxe menu wait and a 4
    min waitime vs usb key or a cd … i would like to deploy os and other tool of 8G i dont want to wait 16min … i want to accelerate the production and this test is 1 pc loading 1 image on a server. anyway this is not the main point.

    Why ftp transfert take 20sec and http take 4min from the same laptop on windows to the same server ? try this on 3 differents server, 2 os and 4 differents clients.


  • Developer

    i’m having a hard time understanding when and where a 4 minute wait time for a diagnostic disk to load is not viable for production



  • Brand new install on CentOS and same speed on the ipxe with http you guys have any advice ? Because with 4min wait time for a 2G file it´s not viable for my production.



  • FYI i will give a try today with CentOS and FOG 1.0.1, just to be sure it’s not an OS problem related.



  • Morning Guys,

    I did more test with both server same conclusion. On the iPXE i see the link http://ip/iso/Hiren14.iso so i give a try with this URL from my windows to FOG server box.

    FTP downloading and uploading (windows to fog server) i got the full 1000mbits speed, something like 20 seconds for 2G image.
    HTTP downloading (fog server to windows) im stuck with the 100mbits took near 3 minutes.

    Do you have any uploading restriction in the apache config or something ?



  • if i look in my setings - fog_tftp kernel i got ipxe so i would said ipxe … the fog is currently brand new with no settings exept the advanced pxe menu i add some iso.

    for other server no i test only with two server ubuntu last version, updated and fog 1.0.1.


  • Senior Developer

    When this system is “downloading” the Hiren CD, how is it doing it, through PXE or iPXE, do you have another FOG Server


Log in to reply
 

476
Online

38710
Users

10537
Topics

99776
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.