[En-Nut-Discussion] TCP FFlush slow on Ethernut 3 - solved

[Thiago A. Corrêa]

Are you using the CVS code?

Harald commited a fix to that a while a go, he does caching of the
value now to avoid querying the chip all the time.

On Tue, Feb 17, 2009 at 5:39 AM, ml <mludwig at adc-elektronik.de> wrote:
>
> Hi Ole,
>
> that´s it.  In tcpout i see that every second time this code is executed.
>
> sock->so_retran_time = (u_short) NutGetMillis();
>
> I don´t know why retran is set but this causes the problems because
> NutGetMillis calls NutGetClock and this is rather slow and i think not
> needed again and again. I read the thread about NutGetMillis and i think
> there will be a solution in future. Only Reading one time at system start
> would be enough and later get the value from variable. This var needs only
> to be changed if one reprogramms the clock at runtime.
>
> Anyway i´ve switched the configurator to fixed value and all is well. It´s
> the turbo for my application, because it´s based on many small
> transmissions.
>
> FFlush now tooks only 2ms (instead of 40ms) in ROM Mode and only 800µs in
> RAM Mode. And there are other locations in the tcp-stuff which uses
> NutGetClock because even the transmision after the retran setting is
> accelerated significantly. For example the arp functions use it and may be
> some more.
>
> thank you for your helpfull hint
>
> Martin
> --
> View this message in context: http://www.nabble.com/TCP-FFlush-slow-on-Ethernut-3-tp22002262p22052853.html
> Sent from the MicroControllers - Ethernut mailing list archive at Nabble.com.
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>