OK to lower timeout for test_timeout's testConnectTimeout test?
I am actually getting failures from test_timeout's testConnectTimeout since the Net connection I have at school lets me connect to Google in under the .001 connection timeout value. If I push it to .00000001 (a hundred-millionth of a second) it then fails consistently. Now the problem is that the second part of the test uses this and a fuzz value (currently at 2) to see if the test timed out within the proper amount of time. The comparison is basically if the amount of time it took to do the timed out failure is less than timeout + fuzz. So lowering this number could possibly affect the test, although at .001 seconds, I am doubting that will occur. But since these types of timing tests can be touchy I thought I would double-check. So if anyone thinks it is bad to lower the value to .00000001 then please let me know. Otherwise I will lower the value before the next alpha goes out. -Brett P.S.: the only other failures I have on OS X right now is test_curses (because I used -uall) and test__locale . Should we disable test__locale on OS X to shut it up since Martin seems to think the test isn't all that useful and won't work for OS X ever?
[Brett Cannon]
I am actually getting failures from test_timeout's testConnectTimeout
It would have helped if you had been specific about the failures you're seeing, and whether you get them all the time, or just some of the time.
since the Net connection I have at school lets me connect to Google in under the .001 connection timeout value. If I push it to .00000001 (a hundred-millionth of a second) it then fails consistently.
What fails? The test fails? The socket fails to connect? Note that .0000001 is the same as passing, e.g., 1e-200. select() only accepts arguments at microsecond granularity, so any positive non-zero timeout value < 1e-6 gets chopped to exactly 0.0. tv.tv_sec = (int)s->sock_timeout; tv.tv_usec = (int)((s->sock_timeout - tv.tv_sec) * 1e6); The test really doesn't intend to pass a timeout of exactly 0 to select(), so we can't change this to less than 1e-6.
Now the problem is that the second part of the test uses this and a fuzz value (currently at 2) to see if the test timed out within the proper amount of time. The comparison is basically if the amount of time it took to do the timed out failure is less than timeout + fuzz. So lowering this number could possibly affect the test, although at .001 seconds, I am doubting that will occur. But since these types of timing tests can be touchy I thought I would double-check.
Na, 2.0 is gigantic compared to .001 already. For the purposes of the test, 2 isn't really more gigantic compared to 1e-6.
So if anyone thinks it is bad to lower the value to .00000001 then please let me know.
Changing it to 1e-7 is out, for the reason explained earlier. I'd like to keep .001, because while the interface to select() *allows* specifying microsecond resolution, there's no guarantee that it can use that much precision. Most (all?) implementations should be able to deal with millisecond resolution, though. Perhaps we could pick on something other than www.google.com. Maybe www.python.org (everyone in America is far from that <wink>).
Tim Peters wrote:
[Brett Cannon]
I am actually getting failures from test_timeout's testConnectTimeout
It would have helped if you had been specific about the failures you're seeing, and whether you get them all the time, or just some of the time.
Sorry about that; almost filed a bug report and pasted it in there; just plain forgot to paste into here: ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 116, in testConnectTimeout self.addr_remote) AssertionError: error not raised ---------------------------------------------------------------------- And it always fails.
since the Net connection I have at school lets me connect to Google in under the .001 connection timeout value. If I push it to .00000001 (a hundred-millionth of a second) it then fails consistently.
What fails? The test fails? The socket fails to connect?
The test. No connection error is reported.
Note that .0000001 is the same as passing, e.g., 1e-200.
I actually meant 1e-08, but apparently that is a moot point.
select() only accepts arguments at microsecond granularity, so any positive non-zero timeout value < 1e-6 gets chopped to exactly 0.0.
tv.tv_sec = (int)s->sock_timeout; tv.tv_usec = (int)((s->sock_timeout - tv.tv_sec) * 1e6);
The test really doesn't intend to pass a timeout of exactly 0 to select(), so we can't change this to less than 1e-6.
That's weird because if I do the test with sock.settimeout(0.0) and then sock.connect(('www.google.com', 80)) I get:: Traceback (most recent call last): File "<stdin>", line 1, in ? File "<string>", line 1, in connect socket.error: (36, 'Operation now in progress') But if I do the exact same thing (new socket, etc.) after closing the previous one but with sock.settimeout(0.00000001) I get:: Traceback (most recent call last): File "<stdin>", line 1, in ? File "<string>", line 1, in connect socket.timeout: timed out which is what the test expects. Could this be a platform difference? Or is the conversion happening else where and thus not the equivalent of passing 0 to settimeout()?
Now the problem is that the second part of the test uses this and a fuzz value (currently at 2) to see if the test timed out within the proper amount of time. The comparison is basically if the amount of time it took to do the timed out failure is less than timeout + fuzz. So lowering this number could possibly affect the test, although at .001 seconds, I am doubting that will occur. But since these types of timing tests can be touchy I thought I would double-check.
Na, 2.0 is gigantic compared to .001 already. For the purposes of the test, 2 isn't really more gigantic compared to 1e-6.
I figured as much.
So if anyone thinks it is bad to lower the value to .00000001 then please let me know.
Changing it to 1e-7 is out, for the reason explained earlier. I'd like to keep .001, because while the interface to select() *allows* specifying microsecond resolution, there's no guarantee that it can use that much precision. Most (all?) implementations should be able to deal with millisecond resolution, though. Perhaps we could pick on something other than www.google.com. Maybe www.python.org (everyone in America is far from that <wink>).
=) I like that idea of changing of the site we hit. Seems slightly rude to be eating Google's bandwidth with our regression suite when we have our own server we can pound (relatively speaking; obviously the test suite is not run by *that* many people). I will go ahead and do that. -Brett
[Brett Cannon]
That's weird because if I do the test with sock.settimeout(0.0) ...
That's very different. If you set the socket timeout to exactly 0, Python never calls select(). If you set it to anything > 0, Python does call select(), but may truncate the timeout to exactly 0 in order to call select.
and then sock.connect(('www.google.com', 80)) I get::
Traceback (most recent call last): File "<stdin>", line 1, in ? File "<string>", line 1, in connect socket.error: (36, 'Operation now in progress')
But if I do the exact same thing (new socket, etc.) after closing the previous one but with sock.settimeout(0.00000001) I get::
Traceback (most recent call last): File "<stdin>", line 1, in ? File "<string>", line 1, in connect socket.timeout: timed out
It will all be obvious <wink> if you read sock_connect(). In particular, the message you got there is produced by if (timeout) { PyErr_SetString(socket_timeout, "timed out"); return NULL; } and you'll find that it's impossible for that to trigger if you set the socket timeout to exactly 0. I'd call that a bug, except it's not worth anyone's time to fix ...
Brett Cannon <bac@OCF.Berkeley.EDU> writes:
P.S.: the only other failures I have on OS X right now is test_curses (because I used -uall) and test__locale . Should we disable test__locale on OS X to shut it up since Martin seems to think the test isn't all that useful and won't work for OS X ever?
ONE of these days, I'll get around to doing something about test_curses... the test is being silly (or at least, that's what I remember from the last time I dug into this). I'm still seeing test_socket fail on OS X, though (Jaguar, testGetServByName). Cheers, mwh -- Ignoring the rules in the FAQ: 1" slice in spleen and prevention of immediate medical care. -- Mark C. Langston, asr
"A.M. Kuchling" <amk@amk.ca> writes:
On Fri, Aug 06, 2004 at 12:40:23PM +0100, Michael Hudson wrote:
ONE of these days, I'll get around to doing something about test_curses... the test is being silly (or at least, that's what I remember from the last time I dug into this).
What's test_curses doing wrong?
I think the problem is that it sometimes calls "curses.curs_set(1)" which doesn't work (returns ERR) when certain definitions (cuvis, I guess) aren't in the terminfo database, which gets translated into a Python exception. Cheers, mwh -- All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. -- IBM maintenance manual, 1925
Michael Hudson <mwh@python.net> writes:
"A.M. Kuchling" <amk@amk.ca> writes:
On Fri, Aug 06, 2004 at 12:40:23PM +0100, Michael Hudson wrote:
ONE of these days, I'll get around to doing something about test_curses... the test is being silly (or at least, that's what I remember from the last time I dug into this).
What's test_curses doing wrong?
I think the problem is that it sometimes calls "curses.curs_set(1)" which doesn't work
Argh; it *always* calls curses.curs_set(1) which *sometimes* doesn't work...
(returns ERR) when certain definitions (cuvis, I guess) aren't in the terminfo database, which gets translated into a Python exception.
-- About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead. -- E.W.Dijkstra, 18th June 1975. Perl did not exist at the time.
Brett Cannon wrote:
I am actually getting failures from test_timeout's testConnectTimeout since the Net connection I have at school lets me connect to Google in under the .001 connection timeout value. If I push it to .00000001 (a hundred-millionth of a second) it then fails consistently.
Now the problem is that the second part of the test uses this and a fuzz value (currently at 2) to see if the test timed out within the proper amount of time. The comparison is basically if the amount of time it took to do the timed out failure is less than timeout + fuzz. So lowering this number could possibly affect the test, although at .001 seconds, I am doubting that will occur. But since these types of timing tests can be touchy I thought I would double-check.
So if anyone thinks it is bad to lower the value to .00000001 then please let me know. Otherwise I will lower the value before the next alpha goes out.
-Brett
P.S.: the only other failures I have on OS X right now is test_curses (because I used -uall) and test__locale . Should we disable test__locale on OS X to shut it up since Martin seems to think the test isn't all that useful and won't work for OS X ever?
Some time ago I submit patch for test_timeout.py: http://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=728815 In my patch testConnectTimeout try connect to www.google.com:21 which seems like black hole. :) -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru
participants (6)
-
A.M. Kuchling -
Brett C. -
Brett Cannon
-
Dmitry Vasiliev -
Michael Hudson -
Tim Peters