Network problem - Gradually getting slower after time.
ianc at goanna.iinet.net.au
Wed Nov 23 07:17:18 UTC 2005
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,
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.
>> 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
>>> Could anybody please help or come up with ideas on what could be the
>>> We have stripped all our application code and are running only the
>>> 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
>>> 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
>>> uptime the transmit buffers will run out due to
>>> the slowdown problem. However this will recover as network load is
>>> 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
>>> a few good ideas.
>>> Best Regards
>>> Solid Software AB
>>> Jonas Moberg
Goanna Technologies Pty Ltd
+61 8 9221 1860
More information about the users