From: Raul Parolari on
Mark T wrote:
> Wow Raul,
> You know how to write a thriller at least!
>
>> We are not running any more the experiment where this problem occurred,
>> so I cannot say now if this fixed it. But thanks for the tip.
>
> Does this mean the story is unfinished?
>
> MarkT

Mark, you made my day with your line.

It will remain an unsolved thriller for a while; not only the
experiment is not running any more (the structure that was moved is
being replaced) but I am also leaving that work, and I will not have
the chance to verify it.

However, I can't stand the thought of leaving that story unfinished. It
was so damning, because everything worked for 99% of the time, every
packet delivered with millisecond precision by ruby 1.9.2 keeping the
pace up perfectly with C/Assembler firmware, and then this "Time thief"
appearing every hour and taking away chunks of 5 or 10 seconds... only a
sudden flash of that conversation with the JPL engineer ("the GC misses
Mars landing!") gave me a clue (and kept me sane, barely).

I will recreate the example using 2 macs connected via Ethernet (I must
rewrite the code though, as it stays with the company). I will use Ruby
on one side and C on the other, and hopefully it will happen again; and
then I will disable/enable the Gc (not that those statements fix
anything as some seem to think, as they will just shift the problem from
one place to another of the program, but they will indicate if it is the
GC).

I will let you know the outcome (in 2-3 weeks). I appreciated your note

Raul Parolari
raulparolari(a)gmail.com


--
Posted via http://www.ruby-forum.com/.

From: Brian Candler on
Raul Parolari wrote:
> and then this "Time thief"
> appearing every hour and taking away chunks of 5 or 10 seconds... only a
> sudden flash of that conversation with the JPL engineer ("the GC misses
> Mars landing!") gave me a clue (and kept me sane, barely).
>
> I will recreate the example using 2 macs connected via Ethernet (I must
> rewrite the code though, as it stays with the company). I will use Ruby
> on one side and C on the other, and hopefully it will happen again; and
> then I will disable/enable the Gc (not that those statements fix
> anything as some seem to think, as they will just shift the problem from
> one place to another of the program, but they will indicate if it is the
> GC).

I cannot see any possible mechanism how the GC would pause for exactly a
multiple of 5 seconds. But a DNS query, if it loses a packet or two,
could certainly pause for exactly 5 or 10 seconds until it retries.
--
Posted via http://www.ruby-forum.com/.

From: Raul Parolari on
Brian Candler wrote:
> Raul Parolari wrote:
>> and then this "Time thief"
>> appearing every hour and taking away chunks of 5 or 10 seconds... only a
>> sudden flash of that conversation with the JPL engineer ("the GC misses
>> Mars landing!") gave me a clue (and kept me sane, barely).
>>
>> I will recreate the example using 2 macs connected via Ethernet (I must
>> rewrite the code though, as it stays with the company). I will use Ruby
>> on one side and C on the other, and hopefully it will happen again; and
>> then I will disable/enable the Gc (not that those statements fix
>> anything as some seem to think, as they will just shift the problem from
>> one place to another of the program, but they will indicate if it is the
>> GC).
>
> I cannot see any possible mechanism how the GC would pause for exactly a
> multiple of 5 seconds. But a DNS query, if it loses a packet or two,
> could certainly pause for exactly 5 or 10 seconds until it retries.

So we have either:
a) a GC problem
b) or that to read a packet from a queue, Ruby 1.9.2 makes a reverse dns
query.

The second is so sad (and so unlike what I have seen from Ruby) that I
almost prefer the first (although it can't be fixed).

But enough speculation.

Raul Parolari
--
Posted via http://www.ruby-forum.com/.

From: Roger Pack on
> So we have either:
> a) a GC problem
> b) or that to read a packet from a queue, Ruby 1.9.2 makes a reverse dns
> query.
>
> The second is so sad (and so unlike what I have seen from Ruby) that I
> almost prefer the first (although it can't be fixed).

I don't think it's the second, since 1.9.2 sets
BasicSocket.do_not_reverse_lookup to true by default.
Jruby doesn't yet, though I'm sure they'll get around to it sometime.
-r
--
Posted via http://www.ruby-forum.com/.

From: Raul Parolari on
Roger Pack wrote:

>> So we have either:
>> a) a GC problem
>> b) or that to read a packet from a queue, Ruby 1.9.2 makes a reverse dns
>> query.
>>
>> The second is so sad (and so unlike what I have seen from Ruby) that I
>> almost prefer the first (although it can't be fixed).
>

> I don't think it's the second, since 1.9.2 sets
> BasicSocket.do_not_reverse_lookup to true by default.
> Jruby doesn't yet, though I'm sure they'll get around to it sometime.
> -r

Yes; I will anyhow use that line (although on the socket instance, not
on the class) so that there are no doubts.

[ btw: for anyone interested, the test will be done by July 12 or so,
as by then I will have my 2nd mac ]

Raul Parolari
--
Posted via http://www.ruby-forum.com/.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Threading with Activerecord
Next: Aliasing classes