[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Network problem - Gradually getting slower after time.



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.

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