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

[Gene Cumm]

On Thu, Jun 30, 2011 at 16:08, Eric W. Biederman <ebiederm at xmission.com> wrote:
> 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.

Looks like the same "christmas tree" I've been seeing.

Is it possible that the closing of the first connection leaves things
inconsistent to open the next?  Is it possible the error I see after
an aborted TFTP transfer is related?

-- 
-Gene