Prev: [PATCH] gainfar.c : skb_over_panic (kernel-2.6.32.15)
Next: [PATCH] gainfar.c : code cleanup
From: Xianghua Xiao on 29 Jun 2010 12:00
On Tue, Jun 29, 2010 at 4:06 AM, Zhang, Yongchao (GE Healthcare)
<Yongchao.Zhang(a)ge.com> wrote:
> Hi,
>   We have some problems about serial port. We need your expertise. The
> detail is like this:
>
> 1.Our Goal:
>   We want to make test on serial port, and want to know whether the
> serial port communication is still OK  under heavy system load.
>
> 2.Environment:
>     1). Two computer,one is as server,another is as client.
>         The "Server" sends data to serial port. We use a serial port
> tool run on WINXP as server.
>         The "Client" reads the data from serial port,and run on Linux.
>
> 3.The way access serial port for "client" program:
>     During test procedure, we use  two kinds of way to "read" data from
> serial port. One way is "select +none block read" ,another is  "block
> read".
>     The code slice  is as the follwoing:
>         (1).select+none block read. like this:
>                   ......
>                   while(num_of_bytes < len)
>                   {
>                           //wait till notified.
>                           while((select(m_fileDescriptor+1,&m_readSet,
> NULL, NULL, NULL)) == -1 && errno == EINTR)
>                           {
>                                  usleep(1000);
>                           }
>
>                           //read data
>                           if((readBytes = ::read(m_fileDescriptor,
> (buff+num_of_bytes), (len-num_of_bytes))) == -1)
>                           {
>                                  close();
>
> printf("CS_ERR_READ_SERIAL_PORT_FAIL");
>                                  exit(0);
>                           }
>                           else
>                           {
>                                  num_of_bytes += readBytes;
>                           }
>                 }
>                 ......
>
>        (2).block read
>                first set paramer c_cc as this during init.
>                    port_settings.c_cc[VMIN ]  = 1 ;
>                    port_settings.c_cc[VTIME] = 0 ;
>                second,read directly
>                    readBytes = ::read(m_fileDescriptor,
> (buff+num_of_bytes), (len-num_of_bytes))) == -1
>
> 4. The heavy load simulation program.
>          Here we write a program to simulate heavy CPU load in linux
> system. This "heavy load program" create one thread and promote thread
> prority to 99, which is the top most in system. This thread did nothing
> but empty loop and never release CPU resource actively.The code slice as
> following:
>
>           //create this thread
>           ....
>           pthread_create(&m_hThread[1],NULL,fifo_99_1  ,(void*)&trans)
>           ....
>
>           //thread proc
>           void* fifo_99(void *para)
>           {
>               struct sched_param param;
>
>               //adjust prority to FIFO 99.
>               pthread_t thread_t     = pthread_self();
>               param.sched_priority = 99;
>               pthread_setschedparam(thread_t,SCHED_FIFO,&param);
>
>               //only cost CPU resource
>               while(1)
>               {
>                   for (int z = 0; z < 10000; z++)
>                   {
>                   }
>               }
>           }
>
> 5. Test procedure
>    (1).
>         Procedure:
>            Run serial port client program,the program is just waitting
> serial port data.  The "client" program is run with normal priority.
>            Run 99 FIFO emluator,so the CPU cost is 100% almost now.
>            Run serial tool in WindowXP,and send data to client,total
> send several groups of data.
>
>         Test result:
>            Find the "client" program could not recevie the data during
> FIFO 99 emluator running. But if break the emluator , the "client"
> program could read out all the data
>  immediately. We get know that it is "select" statement that always
> blocked without waken up if FIFO 99 running . So it seems the system
> could not notify the "serial port data received signal" to "select"
> statement in time.
>
>         Analysis &  Question:
>            Why FIFO 99 could affect on serial port read? Could you
> please point out the detail code position(maybe in serial port driver)?
> And how to avoid this to let "serial port reading" could not be
> disturbed by any other thread or process even if FIFO 99?
>
>   (2).
>        Procedure
>           The same procedure with (1). But this time we also promote
> the "client" program to FIFO 99.
>        Test result:
>           The same with (1).
>        Analysis & Question:
>           Once we doube that the thread priority of the "client"
> program is too low to get CPU resource, so we promote "client" program
> also to FIFO 99.
>           But also could not read out the data until heavy load is
> over. Maybe even high priority for "client" program have no effect on
> this.
>
>   (3).
>         Procedure:
>            The same with (1). But this time change FIFO 99 to FIFO 98,
> and also "client" program is run with normal priority.
>         Test result:
>            The "client" program could read the data in time,all is OK.
>         Analysis & Question:
>            FIFO 99,98 are both high prority in system. But 98 could not
> affect on the serial port,99 could. FIFO 99,98 are both high priority,
> why is it so much difference for serial port reading?
>
>   (4).
>         Procedure:
>            The same with (3). But this time we run two heavy load
> programs i.e. two FIFO 98 in linux system.
>         Test result:
>            There is much difference with (1) and (3).  We will find
> "client" program could receive the data but have some delay(about 2~4
> seconds delay)
>         Analysis & Question:
>            Two FIFO98 are also heavy load to system,but compared with
> FIFO 99,FIFO 98 is not so rigorous. So system maybe give "some running
> slice" to notify the "select" statement though could not be in time but
> still have opportunity to notify. Right?
>
>
>   From our tests, we want to consult with you following questions:
>
>   1. Why FIFO 99 could affect on serial port read? Could you please
> point out the detail code position(maybe in serial port driver)?  And
> how to avoid this to let "serial port reading" could not be disturbed by
> any other thread or process even if FIFO 99?
>
>   2. From procedure (2),To FIFO 99,98,why is there so much difference
> for serial port reading?
>
>
> Thanks!
>
> Best Regards!
>
> -------------------------
> Philip
> 2010.06.29
> -------------------------
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
which kernel/rt-patch are you using to do this test?
can you also list all the RT threads with their priorities, e.g.
softirqs etc, say: ps -e -o pid,rtprio,comm | grep sirq


Xianghua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH] gainfar.c : skb_over_panic (kernel-2.6.32.15)
Next: [PATCH] gainfar.c : code cleanup