Ron Johnson <[EMAIL PROTECTED]>: > > On 01/29/07 22:01, s. keeling wrote: > > Greg Folkert <[EMAIL PROTECTED]>: > >> Has anyone noticed that as of about 3 weeks ago, that keyservers that > >> are typically used (MITs and the other usual candidates) are responding > >> terribly, horrifically slow. If they respond at all, timing out is > > > > (0) heretic /home/keeling_ time gpg --keyserver subkeys.pgp.net --recv-keys > > AC94E4B7 > > gpg: requesting key AC94E4B7 from hkp server subkeys.pgp.net > > gpg: key AC94E4B7: "s. keeling (21Dec2003) <[EMAIL PROTECTED]>" not changed > > gpg: Total number processed: 1 > > gpg: unchanged: 1 > > gpg --keyserver subkeys.pgp.net --recv-keys AC94E4B7 > > 0.03s user 0.01s system 5% cpu 0.605 total > > Your test was possibly not valid. Note the difference in speeds > between when I, moments apart, fetched your keys.
Of course it was valid. What can you expect from a data set with only one data point in it? :-) If Greg is seeing consistently slow responses over a span of weeks, that's pretty comprehensive, and he should be looking to try something else (glad I could help Greg :-). On the other hand, the net was not designed for consistent, instantaneous response. Eg., some mailservers queue every fifteen minutes, some once an hour. Besides, as little as a cron job (or a spam attack) firing up is more than enough to skew response time. System resources are being used by another process. Have patience. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling Linux Counter #80292 - - http://www.faqs.org/rfcs/rfc1855.html Please, don't Cc: me. Spammers! http://www.spots.ab.ca/~keeling/emails.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
