Re: Problem with function select on kernel 2.6.29.6-rt23

["Jürgen Mell" <mell@hedrich-winders.com>]

The slow clock was caused because the kernel suspected a defective ACPI 
PM timer. After fixing that, 2.6.31-rt11 runs up to now without problems.

       Jürgen

Jürgen Mell schrieb:
> No, I do not think that this is intentional. Some lines later, you 
> will find
>
> "Some code calls *select*() with all three sets empty, /n/ zero, and a 
> non-NULL /timeout/ as a fairly portable way to sleep with subsecond 
> precision."
>
> This cannot make any sense, if I have to call select several times to 
> get the full delay period. The overhead for calling the function 
> several times is significant. I have modified the test program 
> according to your proposal to run the loop 2000 times with 10000 us 
> delay and get - depending on the speed of the computer - times between 
> 22 and 24 seconds total.
>
> I understand that the timeout argument of select is updated when 
> select returns after one of the monitored file descriptors is ready 
> for the selected operation.
>
> I have tested this issue now with the kernel 2.6.31-rt11 and got a new 
> problem: this time select does not abort prematurely any more but now 
> each second of computer time is about three seconds in reality (the 
> computer clock is extremely slow). NTP is running.
>
> Somehow fiddling with NTP causes very strange side effects...
>
> Bye,
>           Jürgen
>
> Sujit K M schrieb:
>> this seems to be normal functionality.
>>
>> As quoted from
>>
>> http://linux.die.net/man/2/select
>>
>> (ii)
>> select() may update the timeout argument to indicate how much time was
>> left. pselect() does not change this argument.
>>
>>
>>
>> On Sun, Sep 20, 2009 at 3:50 PM, Sujit K M <sjt.kar@gmail.com> wrote:
>>  
>>> Hi,
>>>
>>> One thing at the onset I would like you to check is that what happens
>>> to the program when the loop
>>> count is made more like 1000/10,000/100000 - 1 Million/10 Million.
>>> Does the Time Graph Increase.
>>> Try Plotting the Difference with actual time start. Try Making Use of
>>> Some scripting language like TCL/TK.
>>>
>>> There is some info regarding the select system call. I think it is
>>> pertaining to this problem.
>>> http://linux.die.net/man/2/syscalls. Basically It is an Optimization
>>> that the Current Kernels Look Into.
>>>
>>> Thanks,
>>> Sujit
>>>
>>> On Sat, Sep 19, 2009 at 1:10 AM, Jürgen Mell 
>>> <mell@hedrich-winders.com> wrote:
>>>    
>>>> Meanwhile I have dug a little deeper into this problem. The problem
>>>> occurs under the following conditions:
>>>> - the BIOS clock must be slow
>>>> - the NTP daemon is used to adjust the system time
>>>> The problem can be reproduced on real hardware as well as on a virtual
>>>> machine running under VMware. Set the BIOS clock back about ten 
>>>> minutes
>>>> against the 'real' time. Then start the NTP daemon and then run the
>>>> little test program:
>>>>
>>>> #include <stdio.h>
>>>> #include <stdlib.h>
>>>> #include <time.h>
>>>> #include <errno.h>
>>>> #include <sys/select.h>
>>>>
>>>> int main(int argc, char *argv[])
>>>> {
>>>>   time_t t;
>>>>   struct timeval timeout;
>>>>   int i;
>>>>   int ret;
>>>>
>>>>   t = time (NULL);
>>>>   printf ("Current time before = %s", ctime (&t));
>>>>
>>>>   for (i = 0; i < 20; i++)
>>>>   {
>>>>      timeout.tv_sec  = 1;
>>>>      timeout.tv_usec = 0;
>>>>
>>>>      if ((ret = select (FD_SETSIZE, NULL, NULL, NULL, &timeout)) < 0)
>>>>      {
>>>>         printf ("select returned %d, errno = %d\n", ret, errno);
>>>>         return EXIT_FAILURE;
>>>>      }
>>>>   }
>>>>   t = time (NULL);
>>>>   printf ("Current time after = %s", ctime (&t));
>>>>   return EXIT_SUCCESS;
>>>> }
>>>>
>>>> On a virtual machine under VMware I got the following result after 
>>>> some
>>>> minutes of system run time:
>>>>
>>>> hws@cwc-vmware:/home/hws > 
>>>> /space/software/select_test/debug/src/select_test
>>>> Current time before = Fri Sep 18 20:05:51 2009
>>>> Current time after = Fri Sep 18 20:06:11 2009
>>>> hws@cwc-vmware:/home/hws > 
>>>> /space/software/select_test/debug/src/select_test
>>>> Current time before = Fri Sep 18 20:14:29 2009
>>>> Current time after = Fri Sep 18 20:14:33 2009
>>>> hws@cwc-vmware:/home/hws > 
>>>> /space/software/select_test/debug/src/select_test
>>>> Current time before = Fri Sep 18 20:14:57 2009
>>>> Current time after = Fri Sep 18 20:14:57 2009
>>>> hws@cwc-vmware:/home/hws > 
>>>> /space/software/select_test/debug/src/select_test
>>>> Current time before = Fri Sep 18 20:15:20 2009
>>>> Current time after = Fri Sep 18 20:15:40 2009
>>>> hws@cwc-vmware:/home/hws >
>>>>
>>>> Normally, the time distance between 'before' and 'after' should be 20
>>>> seconds as in the first and last run of the program. For the second 
>>>> run
>>>> the time difference is only 4 seconds and for the third run it is 
>>>> even zero.
>>>>
>>>> On the real hardware I have also some other time-related issues 
>>>> when the
>>>> problem occurs. Keyboard input will often 'bounce' - key presses are
>>>> detected two or more times and some delay times are prolonged (!). I
>>>> could not yet reproduce this in the virtual machine.
>>>>
>>>> The problem will not always occur immediately after the system is
>>>> started but it may take several minutes until the first effects 
>>>> occur. I
>>>> have not tested this issue with other kernels yet but I will do so
>>>> during the weekend.
>>>>
>>>> Are there any ideas what to do about this (beside buying a better BIOS
>>>> clock)? I would really like to have the NTP daemon running to keep the
>>>> system time accurate, but somehow it seems to effect wait queues in 
>>>> the
>>>> kernel pretty badly.
>>>>
>>>> Bye,
>>>>           Jürgen
>>>>
>>>> Jürgen Mell schrieb:
>>>>      
>>>>> Hi,
>>>>>
>>>>> I have an application which connects via a network socket to a server
>>>>> running on the same machine (IP 127.0.0.1) This application uses the
>>>>> function 'select' to wait for new data from the server or until a two
>>>>> seconds timeout. This works well until there is network traffic on 
>>>>> the
>>>>> external network interfaces (eth* or WLAN). When there is network
>>>>> traffic on the external interfaces, the select function does not wait
>>>>> anymore but it returns with a return code of zero, indicating not 
>>>>> data
>>>>> available on the socket. This happens nearly immediately (after 8 
>>>>> to 9
>>>>> microseconds) and not after the specified two seconds interval. The
>>>>> timeout parameter of select is updated accordingly (it shows eg. 1 s
>>>>> 999991 us).
>>>>> Up to now I could not test this with another kernel but I will try to
>>>>> do it this afternoon. Are there any known problems with select? Is
>>>>> there any way to circumvent this?
>>>>>
>>>>> Any help would be greatly appreciated!
>>>>>
>>>>>        Jürgen
>>>>>
>>>>>         
>>>> -- 
>>>> Jürgen Mell (Software-Entwicklung)       mell@hedrich-winders.com
>>>> Tel.:  +49-511-762-18226                 
>>>> http://www.hedrich-winding.com
>>>> FAX :  +49-511-762-18225
>>>> Mobil: +49-160-7428156
>>>> ---------------------------------------------------------------------------- 
>>>>
>>>> HEDRICH winding systems GmbH
>>>> An der Universität 2 (im PZH)
>>>> D-30823 Garbsen (GERMANY)
>>>> ---------------------------------------------------------------------------- 
>>>>
>>>> Geschäftsführer: Karsten Adam
>>>> Handelsregister: Wetzlar, HRB 4768
>>>> Steuernr.: 020/235/20110                 USt-IdNr.: DE 258258279
>>>> ---------------------------------------------------------------------------- 
>>>>
>>>>
>>>> -- 
>>>> To unsubscribe from this list: send the line "unsubscribe 
>>>> linux-rt-users" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>>       
>>>
>>> -- 
>>> -- Sujit K M
>>>
>>> blog(http://kmsujit.blogspot.com/)
>>>
>>>     
>>
>>
>>
>>   
>
>


-- 
Jürgen Mell (Software-Entwicklung)       mell@hedrich-winders.com
Tel.:  +49-511-762-18226                 http://www.hedrich-winding.com
FAX :  +49-511-762-18225
Mobil: +49-160-7428156
----------------------------------------------------------------------------
HEDRICH winding systems GmbH
An der Universität 2 (im PZH)
D-30823 Garbsen (GERMANY)
----------------------------------------------------------------------------
Geschäftsführer: Karsten Adam
Handelsregister: Wetzlar, HRB 4768
Steuernr.: 020/235/20110                 USt-IdNr.: DE 258258279
---------------------------------------------------------------------------- 


--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html