From: Walton Hoops <walton@...>
Date: 2010-04-28T06:55:45+09:00
Subject: Re: Networking: select() blocks for seconds (> timeout)

On 4/27/2010 12:01 PM, Raul Parolari wrote:
> Bill Kelly wrote:
>   
>>> ... blocked for 5 seconds without signaling the 50 msec timeout.
>>>       
>> Hi,
>> Here was an original discussion of the issue:  (something like, select 
>> may
>> have already succeeded, before a bad UDP checksum is detected by the 
>> kernel)
>>
>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/148443
>>
>> .. 
>> Bill
>>     
> Thanks, Bill, I will look in more detail what happens between the 
> "select()" return, and the socket.recvfrom.
>
> I must tell you that from other tests I did, simpler, not talking to 
> firmware, just 2 ruby programs sending a packet continuously to each 
> other inside a regular Mac (not on ubuntu, which is quite faster) I 
> noticed this:
> a) in average the round trip of a packet was 2.6 msec (good, taking in 
> account that the sw prints something per packet, computes the min, avg 
> and max round trip, etc).
> b) but the maximum roundtrip time was 70 msec (the minimum was an 
> astonishing 0.148msec, i.e. 148 microseconds).
> c) when I increased the number of exchanges (from 1 million to 10 
> millions) the average time was just a bit higher (from 2.6 msec to 2.89 
> msec), but the maximum roundtrip time jumped to 93 msec. So the 
> distribution is still close to the the average, but the "queue of the 
> bell" (I am not sure how to say this exactly in English, but I think you 
> understand) expands significantly, although very low.
>
> So, Ruby is above our hopes ("in average") for high speed comm, but it 
> is not predictable (the maximum delay in the above example being 25 
> times the average, which would force us to set the timeouts absurdly 
> high). Something happens inside Ruby once in a while which freezes it; 
> from here, my suspicion of the garbage collector.
>   

A quick way to confirm that would be to disable garbage collection via
GC.disable().  Of course this will result in a memory leak, but is the
best way to test for sure if the GC is the problem.  If it turns out
that it is, indeed the GC, you could just disable it for the critical
sections.

> In any case, I will look carefully at what you mentioned and I will 
> repeat my tests more rigorously (I should not do them on my dear Mac, 
> because who knows what the os may do from time to time).
>
> I appreciated your input very much
>
> Raul
>
>
>
>