Network problem - Gradually getting slower after time.

Joel Sherrill <joel@OARcorp.com> joel.sherrill at OARcorp.com
Tue Nov 22 15:11:44 UTC 2005


Ian Caddy wrote:
> Hi Jonas,
> 
> We recently upgraded our RTEMS from 4.5.0 to 4.6.2 and also went from a 
> non-optimised build to an optimised build.
> 
> This exact problem was identified in the SMC91111 driver.  I will send 
> you a patch outside the list.  The problem was that a particular 
> variable was not marked volatile and the newer optimisation in the newr 
> GCC (for us) caused the driver to miss packets, effectively delaying them.
> 
> There have probably been other minor changes to the driver since I sent 
> it to you as well, so I will zip up the whole thing and pass it over to 
> you.

If you can figure out if this modification applies to the current 
version of the driver on either the 4.6 branch or head, it would be 
greatly appreciated.  If there is an issue, it needs to be addressed
in the main source.

> I hope this helps.
> 
> regards,
> 
> Ian Caddy
> 
> 
> Jonas Moberg wrote:
> 
>> Dear RTEMS friends,
>>
>> We are in the final stage of releasing our product based on RTEMS 4.6.0,
>> Coldfire MCF5249
>> and the SMSC91C111 network controller when "suddenly" a problem has 
>> arised.
>> Could anybody please help or come up with ideas on what could be the
>> problem.
>> We have stripped all our application code and are running only the 
>> network
>> tasks having the init
>> task to terminate. After hours (6 - 8) of uptime the network slows 
>> down and
>> a "ping" reply degrades to about
>> 2 to 4 seconds. After additional uptime (2-3 days) the "ping" reply time
>> down to 30 to 60 seconds but still working.
>> The SMSC driver is based on Ian Caddys work and has proven to be rock 
>> solid
>> in our application (heavy RTP VOIP traffic
>> plus several TCP and UDP sessions open).
>> We have not had any buffer exhausted problem other than that after a long
>> uptime the transmit buffers will run out due to
>> the slowdown problem. However this will recover as network load is 
>> reduced
>> and there is "sufficient" time to send the transmit buffers.
>> I still can't see (although it might be) this is a driver problem as the
>> network performance is excellent during the first hours of operation.
>> The timer tick is still ticking with a 1 ms period.
>> Having worked around the clock for a few days we would very much 
>> appreciate
>> a few good ideas.
>>
>> Best Regards
>> Solid Software AB
>> Jonas Moberg
>>
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985




More information about the users mailing list