Network problem - Gradually getting slower after time.

[Joel Sherrill <joel@OARcorp.com>]

Ian Caddy wrote:
> Hi,
> 
> A colleague just pointed out to me my mistake.  I should have said that 
> I checked the 4.6.4 and head, instead of 4.6.5.
> 
> I just looked in 4.6.5 and found it.  I quickly looked at the section of 
> the driver, and the problem reported does not relate to the driver in 
> the rtems source tree.
> 
> It was just an artifact of how the driver that we use was coded.

That's good to here.

It would be interesting to see how your driver performs compared to the 
one in the tree. If there are any performance tricks left to apply to 
the driver in the tree, we want to make sure they are in it.

> Talk to you soon,
> 
> Ian C.
> 
> 
> Ian Caddy wrote:
> 
>> 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
>>>>>
>>>>
>>>
>>>
>>
> 


-- 
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