max. download speed over TFTP on MCF5475 with dBUG?

[woel]

Hello,

what is the max. speed over TFTP? I have a 100Mbit connection directly to my PC. A download of a 15MB file has a duration of 75s (ca. 200kB/s). Is this normal? Or how can I speed up it?

Thank you.

[TomE]

The "T" in TFTP stands for "Trivial". It is meant for downloading a boot which can then use a REAL protocol to download the rest of the system. Can you download something small that runs FTP or SSH?

TFTP usually sends one 512-byte packet at a time. So to transfer 15M your PC and Coldfire boards have batted the ball back and forth over the Ethernet 60,000 times (30,000 512-byte data backets and 30000 matching "ack" packets). So you're getting almost 1000 packets/second over 75 seconds. You're probably running into the context-switch limits of the PC.

http://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol

"Note that Windows 2008 introduced pipelined TFTP as part of Windows Deployment Services (WDS) and uses an 8 packet window by default."

So to speed it up you want "pipelined TFTP" or you could do with "large block TFTP" support on both ends, on your PC and in the embedded code:

http://tools.ietf.org/html/rfc2348

[wrostek]

I'm working along with the original poster.

The awkward thing was that an MPC8536 eval tower downloaded the same file in identical scenario in less than 10s (but uboot instead of dBug).

A Freescale remark was that the different cores will cause this gap.  We did not expect that this has so much impact here.

regard

Wolfgang R.

[TomE]

> The awkward thing was that an MPC8536 eval tower downloaded the same file in

> identical scenario in less than 10s (but uboot instead of dBug).

Find out why. Maybe your u-boot supports the "larger block" or "Windowed" options. Check u-boot/net/tftp.c.

Run Etherial on the PC hosting the TFTP server and examine the packets. if you don't see large blocks or windowing, then there's probably a scheduling difference - maybe the slow one is only polling the Ethernet at a slow rate.

> A Freescale remark was that the different cores will cause this gap.

Unlikely. It is possible DBUG is running the CPU in a very slow mode, slow clock with the caches off or something, and maybe executing directly from FLASH instead of from RAM like u-boot often does.

[wrostek]

> Find out why. Maybe your u-boot supports the "larger block"

This is exactly the (major) point. u-boot is supporting 'don't fragment' and 1514 block size instead of 558.

Thanks

Wolfgang R.