If there was a large amount of upload (or download) data going on at the same time, this would cause congestion and serialisation latency, which could dramatically increase the instantaneous apparent latency on the link at tkmedia's broadband connection depending on the type of traffic (packet size), QoS, queuing mechanisms and tx-ring size of the router.
Either way, a 1 second timeout is so far from a "world view" (as Wikipedia would call it!) of Internet connectivity its not funny! Especially, because we have no idea where Google's virutal access points are relative to your location. With no traffic, I get 240ms RTTs to Google and I am on a 20M/2.5M ADSL2+ Annex M connection.
1. The timeout should be increased to at least 5 seconds
2. The test should be repeated at least 3 times with early-exit based on success, with 1 second in between to account for momentary fluctations and dropped SYN/ACK packets.
Best case, this makes no difference to speed of detection, worst case 17 seconds to confirm that there really is a network issue - but doesn't declare Internet no available, for normal everyday variations, poor configuration, being half way around the world, etc.
BTW - judging by the latency tkmedia is getting and the number of times it fails in a row, I think something else is going on for him, I'm sure he would know if there was a massive download going on at the same time (or worse, upload, if he is using ADSL).
tk - can you try repeatedly running the script directly and see what the error output you can get when it fails?
EDIT: BTW I notice that nc reports a number of DNS forward/reverse lookup mismatches (probably due to their acceleration system) before attempting to connect. If your DNS cache doesn't already have the responses to these queries, this would insert a substantial delay that could cause nc to time out... not sure on this one, because logically this means the second time you try it (if you do it quickly) it would work...
