Network problem - Gradually getting slower after time.

[Ian Caddy]

Hi Joel,

The driver Jonas was talking about was not in the main source tree, as I 
never got around to cleaning it up to make it processor 
independant...sorry.  I gave him a copy of our driver some time ago 
which he has put to use in his system.

Since then, Kevin Kirspel (I think) has also created an SMC driver 
independantly and I have seen it in the main tree, although I must be 
having a bad day, as I can't seem to find it in 4.6.5 or the head.

I don't think the bug will be in this driver as it was specific to the 
way I had coded the original driver.

I have sent Kevin a copy of our driver, as he requested, but I would 
also be happy to look through the mainline driver, if someone will point 
me to it.

Talk to you soon,

Ian C.


Joel Sherrill <joel at OARcorp.com> wrote:
> 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
>>>
>>
> 
> 

-- 
Ian Caddy
Goanna Technologies Pty Ltd
+61 8 9221 1860