[syslinux] Problem with 90MB Initrd

Patrick Masotta masottaus at yahoo.com
Thu Oct 1 05:18:19 PDT 2015


>>>>>I do not understand.Are we parsing a configuration file and potentially
>>starting new TFTP transfers while downloading it? How can we do this on
>>a single thread?We cannot stop/resume a TFTP transfer then I cannot
>>imagine how to detect an INCLUDE during TFTP transfer N to launch TFTP
>>transfer N+1 if TFTP transfer N is not finished yet, all in a single
>>thread and with none of the TFTP transfers timing out.
>>
>>I might be wrong but I think syslinux TFTP transfers are "atomic" (they
>>transfer the whole configuration file) later the parsing action on the
>>received file defines if other/s TFTP+parsing actions are required in
>>case the INCLUDE command was previously found. If this is correct then
>>there is never more than one TFTP file transfer at any given time (and
>>we could use PXEbc).
>>Please let me know if I'm wrong. Thanks.
>>
>>Best,Patrick



On Wed, Sep 30, 2015 at 1:42 AM, H. Peter Anvin <hpa at zytor.com> wrote:
>
> We can, and do, suspend a TFTP transfer simply by delaying the ACK packet as necessary.

Observing this behavior appears to be all about buffer sizing.  I had
a 19 kiB config, first line a SAY, second line an INCLUDE and it
loaded 13 data blocks (0-12) before delaying the ACK, loading the next
file completely (0-6), and resuming the first with the ACK and loading
the remaining blocks (13-15).  It still appears to be the same IO
rate.

Aside from potentially needing smaller buffers for config files before
parsing (which seems trivial and unnecessary), what other benefits are
there to this strategy?

-- 
-Gene<<<
Considering any editing/buffering benefits are only marginal (AFAIK) there are not benefits with the current approach.On the other hand the list of potential problems includes:
1) We cannot use the ubiquitous EFI PXEbc protocol forcing us to rely on the (not always present) EFI Binding Services.
2) We cannot implement i.e. TFTP windowsize option (RFC 7440)3) Linked timeouts; a timeout situation while downloading a nested file impacts the whole download chain. I wonder how many times this schema was responsible for random non-recoverable TFTP errors while loading conf files (specially on congested networks) leading to client reboot.4) etc.
If there is not some hidden constrain (please Peter let us know) we should probably think of replacing this schema.
Best,Patrick







 

  


More information about the Syslinux mailing list