Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: 8.3.0: test1474 fails every time
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 19 Sep 2023 01:53:39 -0700
On Mon, Sep 18, 2023 at 01:13:34PM +0200, Christian Weisgerber via curl-library wrote:
> Dan Fandrich:
> > I wanted to try this patch on NetBSD to see if it's related
> > to Nagle's algorithm, but couldn't get to the point where I could try it:
>
> > -http://%HOSTIP:%HTTPPORT/we/want/%TESTNUMBER -T %LOGDIR/test%TESTNUMBER.txt --limit-rate 64K --expect100-timeout 0.001
> > +http://%HOSTIP:%HTTPPORT/we/want/%TESTNUMBER -T %LOGDIR/test%TESTNUMBER.txt --limit-rate 64K --expect100-timeout 0.001 --tcp-nodelay
>
> This makes no difference, the test fails the same way.
After much pain I was finally able to install OpenBSD under KVM and reproduce
this problem. I verified that curl was correctly sending the first 65536 bytes
of data to the socket in a call to send(2), but the OS reports that only 32716
bytes were actually sent. The test assumes that the OS will send all 65536
bytes, so the test fails.
I tried adjusting all the relevant sysctl parameters I could find, and couldn't
change this behaviour. Typically, pattern is the first three 64 KiB sends only
actually send 32716 bytes each, then the next couple send 65432 bytes, then
finally the kernel sends all 65536 bytes, as requested (with the occasional
65432 one). I also tried using write(2) instead of send(2) with no effect.
The OS is free to do this of course, but the test depends on the OS sending
all the data at once in order to set up the specific conditions needed to make
the test work. I don't see any reasonable alternative to just disabling this
test on NetBSD and OpenBSD.
Dan
Date: Tue, 19 Sep 2023 01:53:39 -0700
On Mon, Sep 18, 2023 at 01:13:34PM +0200, Christian Weisgerber via curl-library wrote:
> Dan Fandrich:
> > I wanted to try this patch on NetBSD to see if it's related
> > to Nagle's algorithm, but couldn't get to the point where I could try it:
>
> > -http://%HOSTIP:%HTTPPORT/we/want/%TESTNUMBER -T %LOGDIR/test%TESTNUMBER.txt --limit-rate 64K --expect100-timeout 0.001
> > +http://%HOSTIP:%HTTPPORT/we/want/%TESTNUMBER -T %LOGDIR/test%TESTNUMBER.txt --limit-rate 64K --expect100-timeout 0.001 --tcp-nodelay
>
> This makes no difference, the test fails the same way.
After much pain I was finally able to install OpenBSD under KVM and reproduce
this problem. I verified that curl was correctly sending the first 65536 bytes
of data to the socket in a call to send(2), but the OS reports that only 32716
bytes were actually sent. The test assumes that the OS will send all 65536
bytes, so the test fails.
I tried adjusting all the relevant sysctl parameters I could find, and couldn't
change this behaviour. Typically, pattern is the first three 64 KiB sends only
actually send 32716 bytes each, then the next couple send 65432 bytes, then
finally the kernel sends all 65536 bytes, as requested (with the occasional
65432 one). I also tried using write(2) instead of send(2) with no effect.
The OS is free to do this of course, but the test depends on the OS sending
all the data at once in order to set up the specific conditions needed to make
the test work. I don't see any reasonable alternative to just disabling this
test on NetBSD and OpenBSD.
Dan
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-09-19