On Mon, Feb 29, 2016 at 11:49 AM, Ivan Khoronzhuk < [email protected]> wrote:
> For some systems sensitive to time deviation, would be better > to have some time backup while testing scheduler time, so increase > it to 3 jiffies. > > https://bugs.linaro.org/show_bug.cgi?id=2076 > > Signed-off-by: Ivan Khoronzhuk <[email protected]> > --- > test/validation/scheduler/scheduler.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/test/validation/scheduler/scheduler.c > b/test/validation/scheduler/scheduler.c > index dcf01c0..cb04209 100644 > --- a/test/validation/scheduler/scheduler.c > +++ b/test/validation/scheduler/scheduler.c > @@ -48,7 +48,7 @@ > #define CHAOS_NDX_TO_PTR(n) ((void *)(uintptr_t)n) > #define CHAOS_WAIT_FAIL (5 * ODP_TIME_SEC_IN_NS) > > -#define ODP_WAIT_TOLERANCE (20 * ODP_TIME_MSEC_IN_NS) > +#define ODP_WAIT_TOLERANCE (60 * ODP_TIME_MSEC_IN_NS) > Do we know that this is a fix or is it just a guess at a "better" number? The original code used unconditional waits. If the concern is simply to avoid the possibility of indefinite stalls then why try to cut things so close? We could agree that a wait of one minute is sufficient to say that something definitely isn't right, but do we care what sort of jitter we may see on a run-by-run basis here? A one minute timeout would mean that tests would always get a result. Implementations that observe waits of that magnitude would clearly be in need of investigation while others would still pass this functional validation. Other tests generate performance numbers and if scheduling waits are unacceptably large they'd be better covered in that context. > > /* Test global variables */ > typedef struct { > -- > 1.9.1 > > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
