On Wed, Sep 23, 2015 at 4:24 PM, Patrick Masotta <masottaus at yahoo.com> wrote:>>>> > > > BTW if you take a minute and read the first report > > https://communities.vmware.com/message/2536774 > > You'll realize that VMWare TFTP "surprisingly" does not present slow TFTP transfers > > when they are driven by MS "bootmgfw.efi"; instead the problem is only shown when > > transfers are driven by syslinux.efi; At the moment, despite probably VMware not handling > > the net driver "polling" correctly, I started to wonder if "we" are really handling the EFI Event > > engine correctly when performing TFTP transfers within syslinux.efi > > > > It might be a difference > between using the TFTP and using the UDP > interfaces, or somesuch. > > -hpa > <<< > > Sure "bootmgfw.efi" is doing something better than we do about TFTP transfers. > They: > 1) do not rely on Service Binding Protocols then old EFI firmware PCs do not complain. > 2) I think they do better when handling EFI Events and Timers. > > The key to see how they do what they do is this bootmgfw.efi function: > TftppGetImageRegular > but the task is time consuming; efi environment functions are only referenced by an index > on a pointer table then knowing what functions they are really calling is not very easy > to see.My current inclination is that there's a bug in Syslinux's TFTP+UDP implementation. If it's in the TFTP implementation, lpxelinux.0 should also exhibit issues with larger files (which I seem to recall but can't be certain at the moment). -- -Gene
>>>>>>>>> > > > BTW if you take a minute and read the first report > > https://communities.vmware.com/message/2536774 > > You'll realize that VMWare TFTP "surprisingly" does not present slow TFTP transfers > > when they are driven by MS "bootmgfw.efi"; instead the problem is only shown when > > transfers are driven by syslinux.efi; At the moment, despite probably VMware not handling > > the net driver "polling" correctly, I started to wonder if "we" are really handling the EFI Event > > engine correctly when performing TFTP transfers within syslinux.efi > > > > It might be a difference > between using the TFTP and using the UDP > interfaces, or somesuch. > > -hpa > <<< > > Sure "bootmgfw.efi" is doing something better than we do about TFTP transfers. > They: > 1) do not rely on Service Binding Protocols then old EFI firmware PCs do not complain. > 2) I think they do better when handling EFI Events and Timers. > > The key to see how they do what they do is this bootmgfw.efi function: > TftppGetImageRegular > but the task is time consuming; efi environment functions are only referenced by an index > on a pointer table then knowing what functions they are really calling is not very easy > to see.My current inclination is that there's a bug in Syslinux's TFTP+UDP implementation. If it's in the TFTP implementation, lpxelinux.0 should also exhibit issues with larger files (which I seem to recall but can't be certain at the moment). -Gene <<<<< It seems today most of the EFI FW producers test their stuff mainly against MS bootmgfw.efi. If everything works well with it then no deeper testing is performed. If this is really the case it would be very difficult to determine if the problem is located in syslinux.efi or in some not compliant firmware (i.e. HP, VMware, etc). For all of the above I think we should really understand what bootmgfw.efi does and avoid (when possible) other experiments in the EFI arena. In the past few days I have been comparing bootmgfw.efi and syslinux.efi TFTP strategies and these are differences I've found so far: 1) bootmgfw.efi uses the UDP capabilities of EFI_PXE_BASE_CODE_PROTOCOL (PXEbc is layered on top of an EFI_MANAGED_NETWORK_PROTOCOL protocol in order to perform packet level transactions) _UdpFunctionTable _UdpOpen() _UdpClose() _UdpRead() _UdpWrite() _UdpGetInformation() _UdpSetInformation() on the other hand syslinux.efi uses EFI_UDP4_SERVICE_BINDING_PROTOCOL/EFI_UDP4_PROTOCOL instead. About PXEbc Peter has recently said:> The problem with the pxebc is that it only supports one concurrent TFTP > connection, and Syslinux expects to be able to keep multiple files open > at the same time. > http://www.syslinux.org/archives/2015-August/024025.htmlI wonder why should syslinux.efi ever need to TFTP transfer more than one file simultaneously? 2) when receiving TFTP blocks bootmgfw.efi uses asynchronous "timers" per block without "any" callback function and the timeout seems to be constant; always 2 seconds. On the other hand syslinux.efi uses a combination of synchronous timers (TimerPeriodic) with callback function to calculate "jiffies" which is used to determine the increasing receive timeout (based on a table). The reception of every block also creates an event triggered by EFI_EVENT_NOTIFY which calls a callback function (udp4_cb()) just to change a status (cb_status). Next we keep polling the cb_status variable while calling EFI_UDP4_PROTOCOL.Poll()to speed things up. So far I have been focusing my analysis on the EFI/UDP side of things because Wireshark traffic captures shown a pretty constant heavy delay (under VMware) between the reception of a data block and the corresponding ACK hitting the wire; that doesn't look like a problem on the TFTP algorithm. I think we should probably reconsider the EFI/UDP approach of syslinux.efi. What do you guys think? Best, Patrick
On 09/26/2015 10:36 AM, Patrick Masotta via Syslinux wrote:> > About PXEbc Peter has recently said: >> The problem with the pxebc is that it only supports one concurrent TFTP >> connection, and Syslinux expects to be able to keep multiple files open >> at the same time. >> http://www.syslinux.org/archives/2015-August/024025.html > > I wonder why should syslinux.efi ever need to TFTP transfer more than one file simultaneously? >Consider the case of INCLUDEd configuration files, for example. -hpa
On Wed, Sep 23, 2015 at 4:58 PM, Gene Cumm <gene.cumm at gmail.com> wrote:> On Wed, Sep 23, 2015 at 4:24 PM, Patrick Masotta <masottaus at yahoo.com> wrote: >>>>> >> >> > BTW if you take a minute and read the first report >> > https://communities.vmware.com/message/2536774 >> > You'll realize that VMWare TFTP "surprisingly" does not present slow TFTP transfers >> > when they are driven by MS "bootmgfw.efi"; instead the problem is only shown when >> > transfers are driven by syslinux.efi; At the moment, despite probably VMware not handling >> > the net driver "polling" correctly, I started to wonder if "we" are really handling the EFI Event >> > engine correctly when performing TFTP transfers within syslinux.efi >> > >> >> It might be a difference >> between using the TFTP and using the UDP >> interfaces, or somesuch. >> >> -hpa >> <<< >> >> Sure "bootmgfw.efi" is doing something better than we do about TFTP transfers. >> They: >> 1) do not rely on Service Binding Protocols then old EFI firmware PCs do not complain. >> 2) I think they do better when handling EFI Events and Timers. >> >> The key to see how they do what they do is this bootmgfw.efi function: >> TftppGetImageRegular >> but the task is time consuming; efi environment functions are only referenced by an index >> on a pointer table then knowing what functions they are really calling is not very easy >> to see. > > My current inclination is that there's a bug in Syslinux's TFTP+UDP > implementation. If it's in the TFTP implementation, lpxelinux.0 > should also exhibit issues with larger files (which I seem to recall > but can't be certain at the moment).lpxelinux.0 seems clear of this issue. I did a transfer of ~76MB and didn't see any decay. I'm thinking either UDP or memory allocation bug/misuse. -- -Gene
76 MB would be less than the rollover threshold. On September 30, 2015 3:45:23 AM PDT, Gene Cumm <gene.cumm at gmail.com> wrote:>On Wed, Sep 23, 2015 at 4:58 PM, Gene Cumm <gene.cumm at gmail.com> wrote: >> On Wed, Sep 23, 2015 at 4:24 PM, Patrick Masotta ><masottaus at yahoo.com> wrote: >>>>>> >>> >>> > BTW if you take a minute and read the first report >>> > https://communities.vmware.com/message/2536774 >>> > You'll realize that VMWare TFTP "surprisingly" does not present >slow TFTP transfers >>> > when they are driven by MS "bootmgfw.efi"; instead the problem is >only shown when >>> > transfers are driven by syslinux.efi; At the moment, despite >probably VMware not handling >>> > the net driver "polling" correctly, I started to wonder if "we" >are really handling the EFI Event >>> > engine correctly when performing TFTP transfers within >syslinux.efi >>> > >>> >>> It might be a difference >>> between using the TFTP and using the UDP >>> interfaces, or somesuch. >>> >>> -hpa >>> <<< >>> >>> Sure "bootmgfw.efi" is doing something better than we do about TFTP >transfers. >>> They: >>> 1) do not rely on Service Binding Protocols then old EFI firmware >PCs do not complain. >>> 2) I think they do better when handling EFI Events and Timers. >>> >>> The key to see how they do what they do is this bootmgfw.efi >function: >>> TftppGetImageRegular >>> but the task is time consuming; efi environment functions are only >referenced by an index >>> on a pointer table then knowing what functions they are really >calling is not very easy >>> to see. >> >> My current inclination is that there's a bug in Syslinux's TFTP+UDP >> implementation. If it's in the TFTP implementation, lpxelinux.0 >> should also exhibit issues with larger files (which I seem to recall >> but can't be certain at the moment). > >lpxelinux.0 seems clear of this issue. I did a transfer of ~76MB and >didn't see any decay. I'm thinking either UDP or memory allocation >bug/misuse.-- Sent from my Android device with K-9 Mail. Please excuse my brevity.