[syslinux] gpxelinux.0 and slow HTTP performance on VMware ESX VM

[Eric W. Biederman]

syslinux at schlomo.schapiro.org writes:

> Hi,
>
> Am 29.06.2011 22:05, schrieb H. Peter Anvin:
>> On 06/29/2011 11:57 AM, Schlomo Schapiro wrote:
>>>
>>> The core problem is that HTTP transfers by gpxelinux.0 are very slow. Sadly this
>>> problem seems to be somehow related to our VMware ESX environment and I am not
>>> able to pin the problem down.
>>>
>> 
>> The requirement for gpxelinux.0 to support HTTP transfers is going to be
>> dropped in Syslinux 4.10, which is now on the release track.  Could you
>> test out pxelinux.0 (*not* gpxelinux.0) from Syslinux 4.10-pre15 and see
>> if you have any problems?
>> 
>> Other than that, it would be good to get a package trace
>> (tcpdump/wireshark).
>
> I tried your suggestion today (and I think it is a very good thing to
> have native HTTP support in pxelinux).
>
> Unfortunately it does not work. I put together some debug infos and
> traces at http://files.schapiro.org/schlomo/syslinux/index.html
>
> Things to notice:
> * syslinux 4.10 did apparently not try to load vesamenu.c32 but
> immediately tried vesamenu.c32.0 and other variations. The access log
> shows that very nice. First you find there a successful boot with a user
> agent of gPXE from gpelinux.0 4.04. After that the failed boot requests
> from a user agent of Syslinux/4.10
>
> * there are much less network errors in the pcap trace with pxelinux
> 4.10 compared to gpxelinux 4.04, but still some.
>
> * I tried various VM settings with 32 and 64 bit and various NIC types,
> seems to have no effect

It is odd, because at least the pcap shows that 4.10-pre15 completed
the http transfer of /boot/pxelinx.cfg/default and went on to try and=
transfer the next file.  In trying to establish the next tcp connect
pxelinux decided to RST the connection instead of just acking it.

And there it looks like there was a little bit of confusing in the final
handshake of the transfer of /boot/pxelinux.cfg/default

What machine was capturing the packet trace?
I assume you were working against apache given the access log.  Was the
apache server located on another VM?

Eric