delaywrite test failures

[Stefan (metze) Metzmacher]

Am 07.02.2014 00:40, schrieb Jeremy Allison:
> On Wed, Feb 05, 2014 at 04:57:58PM +1300, Andrew Bartlett wrote:
>> Many of our flaky and autobuild failures are this one:
>>
>> [353/1598 in 17m5s] samba3.base.delaywrite(plugin_s4_dc)
>>
>> Running test_delayed_write_update1b
>> Initial write time Wed Feb  5 04:41:02 2014 CET
>> write time Wed Feb  5 04:41:02 2014 CET
>> write time Wed Feb  5 04:41:02 2014 CET
>> write time Wed Feb  5 04:41:02 2014 CET
>> write time Wed Feb  5 04:41:02 2014 CET
>> write time Wed Feb  5 04:41:02 2014 CET
>> write time Wed Feb  5 04:41:02 2014 CET
>> write time Wed Feb  5 04:41:02 2014 CET
>> write time Wed Feb  5 04:41:02 2014 CET
>> write time Wed Feb  5 04:41:02 2014 CET
>> Server updated write time on close (correct)
>> UNEXPECTED(failure): samba3.base.delaywrite.update of write time using SET_END_OF_FILE(plugin_s4_dc)
>> REASON: _StringException: _StringException: After SET_END_OF_FILE truncate server updated write_time
>> after 0.10 seconds(1 sec == 0.25)(wrong!)
>>
>> FAILED (1 failures, 0 errors and 0 unexpected successes in 0 testsuites)
>>
>> Anybody know what the issue is, do we just need to make it more relaxed?
> 
> The relevent code (I remember 'cos I wrote it :-) is checking that
> a SET_END_OF_FILE truncate updates the write time happens 'immediately',
> where immediately is set as:
> 
>         int used_delay = torture_setting_int(tctx, "writetimeupdatedelay", 2000000);
>         int normal_delay = 2000000;
>         double sec = ((double)used_delay) / ((double)normal_delay);
> 
> (where sec ends up as 0.25 probably due to the writetimeupdatedelay setting
> in the test scripts)
> 
>         if (diff > (0.25 * sec * 0.75)) { /* 0.75 to cope with vmware timing */
> 			ERROR....
> 
> So I'm guessing this needs relaxing some for the test
> environment - looks like our 'immediately' is too strict
> in the test harness. (0.25 * 0.25 * 0.75 == 0.0625),

0.25 * 0.25 = 0.0625

0.25 * 0.25 * 0.75 = 0,046875

I'm wondering why * 0.75 because of vmware timing,
shouldn't that be + 0.75?

(0.25 * sec) + (0.75 * sec) should be much better

with sec = 0.25, it would be 0,25
with sec = 1, it would be 1.

There're 2 cases:

- we need to make sure the server updates without delay,
  (we should check that the responses comes after <= half of
   the writetimeupdatedelay time)
- or we need to make sure response is received after >= writetimeupdatedelay

Then we might want to add hack for crazy clocks.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140207/a774a2f2/attachment.pgp>