-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 David Shaw wrote, On 04/06/2010 10:46 PM: > On Apr 6, 2010, at 3:17 PM, Jeff Johnson wrote: > >> On Apr 6, 2010, at 2:37 PM, David Shaw wrote: >>> Just rig it up similarly to how DNS does it. Rank things in >>> order of performance, and then artificially penalize the fastest >>> ones on each iteration until they aren't the fastest any more. >>> Then repeat. The goal isn't perfection - it's just to be better >>> than round robin :) >>> >> No disagreement that "round robin" isn't feeble, even if "fair". >> >> It would certainly be nice if there was some means to get at DNS >> metrics from outside. >> >> Off the top of my head (i.e 2minutes of thought), I can't think of >> an easy way to get at those DNS metric "innards" in spite of having >> used DNS professionally for like 30 years. > > I think you can get them by dumping the nameserver cache (dumpdb). > They're in there as comments, so parsing them out might be a bit odd. > > > Even so, I wasn't very clear - I didn't mean to literally use the DNS > values, but rather hit each SKS server periodically and time the > transaction (only similar to how DNS does it). Kristian already > checks each server periodically - I was thinking if he added > performance measurements to his current tests, it could be used to > rank things in the SRV list. Of course, this is measuring things > from his particular network perspective, so it might be wrong for > everyone else... > >> But I'm sure there's something that could be hacked up and whacked >> together, there always is in uglix ;-) > > But of course! > > David > >
Hi again Been slightly preoccupied at work lately, so been some time since we last looked at this, but at least I've gotten around to implementing some performance testing and weighting the SRV records now. That said, it is still a very simplistic approach by timing the connection speed (in seconds) and doing a weight = (int)(1/responsetime * 100). After this I have manually overwritten the weight of the local keyserver (keys.kfwebs.net) to 200. I have added the weights into the table at http://sks-keyservers.net/status/ ;; ANSWER SECTION: _pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 509 11371 keys.wuschelpuschel.org. _pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 1026 11371 keyserver.ftbfs.org. _pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 693 11371 keyserver.nijkamp.net. _pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 597 11371 barbadine.canonical.com. _pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 597 11371 esperanza.canonical.com. _pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 593 11371 sks.karotte.org. _pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 577 11371 sks-peer.spodhuis.org. _pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 574 11371 keys.syn.co.uk. _pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 543 11371 keyserver.kim-minh.com. _pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 541 11371 pgp.uni-mainz.de. At this point, what is the preferred approach? 1) keep the weights as they are 2) group them into intervals / steps in order to get some additional load balancing other than that I'll look into penalizing upon request / use when I get some more spare time. Have a nice evening! - -- - ---------------------------- Kristian Fiskerstrand [email protected] http://www.sumptuouscapital.com - ---------------------------- Ne nuntium necare Don't kill the messenger - ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this, visit: http://www.secure-my-email.com - ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iQIcBAEBCAAGBQJMduEZAAoJEAt/i2Dj7frjOMAQAIAspgv5E/gmq2vrVB0qKUrM PwPioCf0ngmge/kuvESiQVqElld8HtxLWdv/ouXSdPI/3ZoNyuI6r+UX8/DB0+8z 81vUeCeEtCEB1o77q7ZZMYPw0iDjKLN5W0WPJqY/s0DI/FsPKWE6Zwmznavp+vVM gbdcoAfD7Vj1VCWo35QYpIwNsfyaTJHKI3/lAkPia2c9E0EnAT+2312frmYMciQ+ 8T05qBnbYEzC7Vps0mL8+ly7ZDblXOy/o4YO4tu1vTUofQMzJ5SBx0LVsvqRSTmc fkNlPEnFHrB3KiSOvuywe+NV1lwWc9xEvNi0O2JSNpwIwfcyVOODJCwwW13/m/7+ k/8UstFIRrsd8F2RQaBMVlfqCj6MoQlsIhzfSk8A0euFq66K3eHYDTAtjuDca3t3 +VDqUdhtLntutWZW2zIZIRadDZ2xVtxkoqdQRJkc4aD4tdiN3Bhs1I3msgvDzM0c g9OYpvX3XXxy2W9OqMyjI+QxUqSr1rNc6Ak3/8ojesY7eynhDzo2+wH8gcY9KvB+ xg7hEi19nkvjlh2byF7nmSM/qus0RtUxI1gvNks/AdfWLq+FpZPq/sSdphT8/qEy SAf0VIiFOpKP6ntWfJzQPSiuMTGvDfDNYGQgNS89X38p81R/OkjlUYjTjtCRpJz7 RxpYKCPMYOgOqyOnj4Nh =cXsq -----END PGP SIGNATURE----- _______________________________________________ Sks-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/sks-devel
