Re: Arcturus uCDimm + TFTP

[John Dobbins <john.dobbins@cornell.edu>]

On 2/15/2011 4:13 PM, Eric Norum wrote:
> The problem is that the network stack provided by the uCDIMM bootstrap has a *very* small receive queue.    If you have any significant broadcast traffic on the network segment you'll start losing TFTP packets resulting in massive slowdowns.
>
> Possible workarounds:
> 1) Burn your first application into the ColdFire using TFTP on a quiet network segment -- I did this by connecting the ColdFire directly to my laptop -- with only two device on the network the TFTP transfers run very fast.

That is just what I did to get around this.


> 2) From then on use the EPICS flash memory driver to update your application.  The RTEMS network stack is much more robust and doesn't drop packets so easily.

I don't know about this EPICS flash memory driver. Is there something I 
should have read?

Thanks,

John Dobbins





> What's really annoying is that the bad behaviour could be fixed with a small change in the bootstrap code -- once TFTP has begun, turn off reception of broadcast packets in the network hardware then turn reception back on when the TFTP command is terminated.   This would completely fix the problem while still allowing RARP/etc. to continue to work.   I suggested this to Arcturus several times, but they clearly haven't fixed things yet.
>
>
> On Feb 15, 2011, at 1:01 PM, John Dobbins wrote:
>
> > Hello All,
> >
> > I have just built EPICS base and an example IOC for an RTEMS-uC5252 target (EPICS R3.14.11, RTEMS 3.9.3), which I can say went swimmingly well. However tftp problems are sucking all the fun out of it. The Arcturus uCDimm comes with a TFTP server which I am using with a 255.255.0.0 netmask. File transfer takes forever and usually ends in a time-out error. We have some evidence that things work much better on a subnet with a 255.255.255.0 mask. Can anyone shed light on any of this?
> >
> > Regards,
> >
> > John Dobbins
> >
> > Cornell University