Hi,
Steven Rostedt:
> Not sure if it would help you trace this down further but have you tried
> running your load with the Latency Tracer configured in?
Not yet, I'll give it a try.
> Is the thread that needs to gain CPU time dependent on the accessing of
> the serial and ethernet ports?
If you by this question suppose that the thread may get blocked because of the
ports, the answer is no: all ports are configured asynchronous. I'm all one
thread anyway.
> Can you post the code to your program somewhere, and also show us
> exactly where you see the latency?
I'm afraid I can't post the code due to industrial reasons but it's probably
possible to show some snippets.
It looks like this, commented where necessary:
-----------------------------------------------------------------------
get_rt_priority();
while (1)
{
if (begin_timer)
{
clock_gettime(CLOCK_REALTIME, &now);
begin_timer = 0;
}
prev = next = now;
next.tv_nsec += RT_DELAY; // RT_DELAY is 980000 ns by default
tsnorm(&next);
[...]
if (sleep_allowed)
clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &next, NULL);
// read klok
clock_gettime(CLOCK_REALTIME, &now);
// Few calculations to time cyclic jobs
handle_timers(calcdiff(now, prev));
[...various data handling...]
ioctl(zlvStatus[port].fd, TIOCMGET, &flags); // this ioctl is to blame
[...some more tinkering with data...]
#ifdef _SHOWTIMER_
if (!begin_timer)
{
/* Now we remember the longest cycle runtime */
clock_gettime(CLOCK_REALTIME, &next);
tmp = calcdiff(next, now);
if (tmp > runtime)
runtime = tmp;
}
#endif
}
------------------------------------------------------------------------
The symptom is that latency can kick in anywhere within this while() loop.
After timestamping almost every single line, I was unable to bind the delay to
one location. Sometimes a simple variable assignment was shown to last 2-3
milliseconds. This led me to believe that the latency is not directly related
to the code but rather an interruption of the running code at "random"
locations.
The latency is not present with the ioctl() call busted out, but the ioctl()
itself is completed in a few microseconds or so.
> The only real thing that happens in get_mctrl that I see is a wake_up.
> So if something is sleeping on an ioctl TIOCMWAIT, it will wake up and
> run. Do you have something that does this? Your latency that you are
> seeing, might just be another thread taking up the CPU.
My task is the only one toying with the serial ports, kind of. I generated the
high interrupt load with a ping -f and copying over NFS.
> Your personal server or are you talking about the server to download the
> patch?
The server I'm running the code on is the one under use.
But I think it's all the same for the different versions anyway.
> As I said, check your application. I think there's another thread you
> may have that is competing with the thread you are timing.
I'll then try to prevent multiple opens on the serial ports then to avoid race
conditions. (Do I have to modify the serial driver for that?)
Thanks for the tips,
s.
-----------------------------------------------------------------
| You are one of those bad things that happen to good people. |
-----------------------------------------------------------------
Attachment:
pgpKUNusM8x2Q.pgp
Description: PGP signature
