[syslinux] R: Re: R: Re: PXEbooting very slow

H. Peter Anvin hpa at zytor.com
Sat Jun 6 10:53:18 PDT 2009


Sebastian Herbszt wrote:
> H. Peter Anvin wrote:
>> Sebastian Herbszt wrote:
>>>
>>> I am able to reproduce the problem in qemu and here are my results:
>>> With 3.75 and 3.82-pre4 i am getting delays with tftpd32 v3.10. Both
>>> syslinux
>>> versions seem to work better, but not perfect, with tftpd32 v3.33.
>>>
>>> This seems to be a tftpd32 problem since i never saw such delays with
>>> atftp-0.7.0-66.
>>>
>>
>> Interesting.  Could you post a wireshark trace?
> 
> Find 3.82-pre4-tftpd32-3.10beta.pcap attached.
> 

The only anomaly I see in that trace is that tftpd32 3.10 seems to have
issues on retransmission of RRQ.  This isn't entirely surprising:
duplicated RRQs can *only* be distinguished from a new request from the
same source by the fact that the port number is the same; however, in a
forking tftp server design one will already have spawned a new process
and as a result won't even know what there is a new connection (tftp-hpa
has the same problem, however, it's basically harmless since the replies
will go unacknowledged.)

Combine that with the fact that tftpd32 seems to have an absolutely
glacial startup delay: the first RRQ is sent at t=0.313659, and by the
time tftpd32 answers, *five seconds* later (t=5.319610), pxelinux has
already retransmitted the RRQ 13 times.  All of them eventually turn
into attempted transactions, with the last one at t=13.412729, or over 8
seconds after transmission.

It would probably be nicer if pxelinux would respond to those additional
connections with an ERROR.  I think I'll let that wait until we get this
code recoded in C later this summer.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.




More information about the Syslinux mailing list