> >> I have managed (with a lot of effort) to track down the apparent
> >> cause of the regression failures I was seeing. They appear to be
> >> directly related to the degree of parallelism with which the tests
> >> are run. I can reliably get a 100% clean run on the serial tests,
> >> and on the parallel tests with MAX_CONNECTIONS=5. But if I run at
> >> MAX_CONNECTIONS=10 I (almost) always get failures, which for some
> >> reason that is beyond me start with the copy test, which
> isn't even
> >> run in parallel with other tests.
> >>
> >> This is all quite worrying, and suggests that we will need
> to do some
> >> careful stress testing before we can release this.
> >>
> >> Is there some W2K parameter I can tweak in the TCP stack
> that might
> >> alleviate the problem?
> >
> > Is this the extra newline regression failure you were seeing?
> >
>
> No, this is running with the patch that suppresses that.
> Basically, for some reason that I have been unable to find,
> and which leaves no log trace, copy just stops after about 4
> or 5 lines, and then there are a bunch of consequent
> failures. I can't account for it yet. All I do know is that
> it happens when the tests are run with high parallelism and
> doesn't with no or low parallelism.
>
> (tests are all run from MSys)
Does this mean they work when you run the tests from cygwin, or that you
haven't tried it there? I've always run it with the defualt, which
should be unlimited, with no problems.
Could it simply be another issue with the infamous stdout/stderr
buffering on the msys console, that causes the script to get results in
the wrong order or something? [assuming this *is* a client-side problem,
of course]
//Magnus