-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The SRV records are currently used for the sub-pools eu.pool and > na.pool. Before implementing a new approach with a higher degree of > complexity, that require more effort to implement, I'd appreciate > feedback on the current implementation. Are the sub-pools being > actively used? are they performing as it should? Or could it be > modified in a simpler way and achieve the same real-world benefits?
Dear Kristian, Although I don't use the subpools I'd like to comment the document you wrote. :-) 1. As section 2.2 discusses the the current weigth calculation is misleading a bit. You measure response time from your location, so average subpool clients will use the nearest 10 servers to you. It would better to do this measurement from several points of the network. 2. You wrote | In addition the size | of the SKS status page is typically less than 3 KiB, | which doesn't provide enough information for a proper | measurement of the bandwidth capacity of the server. I'm afraid there is a little confusion here. What do you want to measure at all? a) the network delay (i.e. round trip time, "ping time"), b) the bandwidth bottleneck c) processor/disk speed of the remote key server I think it is no worth to do a very complicated, multifactor measurement. We need no hair cutting accuracy but an "average responsiveness" value. So I suggest to recruit a small group of volunteers worldwide who are willing to run a measurement station. They would install a simple CGI script that receives two parameters: a key server name and a key ID and replies the time of downloading the given key from the given server. After all this time is more important than how long time takes to download index.html. Your central data acquiring software can compute SRV values from these times. Additionally local keyserver operators may bias it by adding advertising a number via TXT records of their key server. Some similar possibility is required beacause they know better the actual local network and HW resource policy/status. E.g. keys.niif.hu. 3600 TXT "SKS Pool weight factor=30%" where the allowed range is 0-150 percent. Regards Gabor -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Made with pgp4pine 1.76 iEYEARECAAYFAk+mG+MACgkQd2oiOrtquzh/MACeM3B/3DhPrhHd8r4uuaEvngJs ErgAn0qlala5wryAiJFHimP10WP34/hY =3rl6 -----END PGP SIGNATURE----- _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel