Our use case is to use libcurl for high performance ultra-low latency web service calling, with high qps. Our avg latency of the web service is only 2ms (including connection time), and we need to set a strict and aggressive timeout value to ensure the web service does not block the main process path for too long for each request, in case something goes wrong. So, we need to set the timeout to 5ms or 10ms.

I agree that 40ms is very short for most of the regular use cases, but since libcurl is intended to be a general framework for different use cases, I think it'd be better to make this value configurable (either in Makefile, or as a curl easy option).

It does not have to be "perfect" timeout precision, but it at least should not have a lower bound of a hard-coded value (which is coarse for some high-perf use cases).

If I lower the 40ms hard-coded value to 5ms and recompile libcurl, it will work much better for my use case.

A side question: if the timer is indeed faulty, and returns much earlier than expected, say 50ms earlier than the due time, will libcurl be able to set a new timer with the difference?

---
** [bugs:#1228] curl multi timeout does not work with timeout set less than 40ms**
**Status:** open
**Created:** Wed May 22, 2013 09:45 PM UTC by Hang
**Last Updated:** Mon Jun 03, 2013 06:41 PM UTC
**Owner:** Daniel Stenberg
In the latest source code lib/multi.c:
~~~~
2178   now.tv_usec += 40000; /* compensate for bad precision timers that might've
2179                            triggered too early */
2180   if(now.tv_usec >= 1000000) {
2181     now.tv_sec++;
2182     now.tv_usec -= 1000000;
2183   }
2184 
2185   /*
2186    * The loop following here will go on as long as there are expire-times left
2187    * to process in the splay and 'data' will be re-assigned for every expired
2188    * handle we deal with.
2189    */
2190   do {
2191     /* the first loop lap 'data' can be NULL */
2192     if(data) {
2193       do
2194         result = multi_runsingle(multi, now, data->set.one_easy);
2195       while(CURLM_CALL_MULTI_PERFORM == result);
~~~~
"now" has been artificially incremented by 40ms, and then passed in to the multi_runsingle(...) below. 
Then, multi_runsingle() will check for timeouts:
~~~~
964       timeout_ms = Curl_timeleft(data, &now,
965                                  (easy->state <= CURLM_STATE_WAITDO)?
966                                  TRUE:FALSE);
~~~~
so, if the timeout setting is less than 40ms for the curl easy handle, the Curl_tvdiff(*nowp, data->progress.t_startsingle) will return 39ms at the very beginning of the curl easy request, and therefore timeout the request even before it gets started. 
It will always prompt something like this (almost immediately after the first curl_multi_perform() call):
http://foo.com => (28) Connection timed out after 39 milliseconds
---
Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/curl/bugs/1228/>
To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>