Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical "wish"
On Mon, Dec 17, 2007 at 01:15:10PM -0500, Noah Meyerhans wrote: > > > If it were possible, (temporarily) adding a securty.d.o mirror in the > > > 0.0.0.0 - 127.255.255.255 range would be helpful [...] > > > Obviously finding a host that can deal with 13.53 MB/s of sustained > > > traffic with a useful IP address to temporarily test this behaviour > > > might be difficult. :) > > > > Quite. > > We might actually be able to help with this at MIT, where steffani is > already hosted. MIT controls 18.0.0.0/8 and, while the lab where > steffani is hosted doesn't usually use net 18 address space, we do have > some available. I'd have to double check with the network admin, but it > should be trivial to allocate an address for this purpose. Would it > work to simply bring up a separate interface on steffani? Did you mention this to DSA, they'd have to configure it at this end? File an RT ticket? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical "wish"
On Mon, Dec 17, 2007 at 07:51:18PM +0100, Martin Schulze wrote: > > I've asked DSA for server-status already, and mentioned the logs too, > > we'll see (they haven't replied yet). > > Server status is configured on localhost. OK, so I started measuring that too, and the rates for the last half a day or so are: * villa: 20.4 rps, 6.18 Mbps * lobos: 18.9 rps, 6.23 Mbps * steffani: 40.0 rps, 15.92 Mbps The ratios for both parameters are matching the general bandwidth ratios, so the measurements should be correct. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical "wish"
Josip Rodin wrote: > On Mon, Dec 17, 2007 at 01:15:10PM -0500, Noah Meyerhans wrote: > > > > If it were possible, (temporarily) adding a securty.d.o mirror in the > > > > 0.0.0.0 - 127.255.255.255 range would be helpful [...] > > > > Obviously finding a host that can deal with 13.53 MB/s of sustained > > > > traffic with a useful IP address to temporarily test this behaviour > > > > might be difficult. :) > > > > > > Quite. > > > > We might actually be able to help with this at MIT, where steffani is > > already hosted. MIT controls 18.0.0.0/8 and, while the lab where > > steffani is hosted doesn't usually use net 18 address space, we do have > > some available. I'd have to double check with the network admin, but it > > should be trivial to allocate an address for this purpose. Would it > > work to simply bring up a separate interface on steffani? > > Did you mention this to DSA, they'd have to configure it at this end? I may be dumb, but what would another IP address for an existing security mirror that is already the preferred one buy us? I would expect that a second machine in the 128.* zone would be able to spread the load better. Regards, Joey -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical "wish"
On Tue, Dec 18, 2007 at 03:31:13PM +0100, Martin Schulze wrote: > > > > > If it were possible, (temporarily) adding a securty.d.o mirror in the > > > > > 0.0.0.0 - 127.255.255.255 range would be helpful [...] > > > > > Obviously finding a host that can deal with 13.53 MB/s of sustained > > > > > traffic with a useful IP address to temporarily test this behaviour > > > > > might be difficult. :) > > > > > > > > Quite. > > > > > > We might actually be able to help with this > > > > Did you mention this to DSA, they'd have to configure it at this end? > > I may be dumb, but what would another IP address for an existing > security mirror that is already the preferred one buy us? I would > expect that a second machine in the 128.* zone would be able to > spread the load better. See above - just temporary for purposes of demonstration. Though I think that the case is already clear, but to eliminate any doubt whatsoever... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical "wish"
Josip Rodin wrote: > On Tue, Dec 18, 2007 at 03:31:13PM +0100, Martin Schulze wrote: > > > > > > If it were possible, (temporarily) adding a securty.d.o mirror in > > > > > > the > > > > > > 0.0.0.0 - 127.255.255.255 range would be helpful [...] > > > > > > Obviously finding a host that can deal with 13.53 MB/s of sustained > > > > > > traffic with a useful IP address to temporarily test this behaviour > > > > > > might be difficult. :) > > > > > > > > > > Quite. > > > > > > > > We might actually be able to help with this > > > > > > Did you mention this to DSA, they'd have to configure it at this end? > > > > I may be dumb, but what would another IP address for an existing > > security mirror that is already the preferred one buy us? I would > > expect that a second machine in the 128.* zone would be able to > > spread the load better. > > See above - just temporary for purposes of demonstration. > > Though I think that the case is already clear, but to eliminate any doubt > whatsoever... Ok, no objection. Noah, please allocate such an IP, configure an alias eth, keep it for a while and remove it again after max. 1 month (hope that gives Joy enough time). In the long term, it may be helpful to acquire another US (uni) based security mirror. Joy, if you know of a site that had good bw and is willing to sponsor host + bandwidth, please let me know. Regards, Joey -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical "wish"
On Tue, Dec 18, 2007 at 04:04:00PM +0100, Martin Schulze wrote: > Ok, no objection. Noah, please allocate such an IP, configure an alias > eth, keep it for a while and remove it again after max. 1 month (hope that > gives Joy enough time). This is done. Steffani now has interface eth0.64 with address 18.24.0.11 noah signature.asc Description: Digital signature
Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical "wish"
On Tue, Dec 18, 2007 at 12:24:21PM -0500, Noah Meyerhans wrote: > This is done. Steffani now has interface eth0.64 with address 18.24.0.11 Hrm, if you had security.debian.org pointing at: 18.24.0.11 212.211.132.032 212.211.132.250 The rule9-prediction scripts says you get: 000.000.000.000-127.255.255.255: steffani 128.000.000.000-255.255.255.255: villa and/or lobos and the previous maths would predict about: steffani: 13.53 MB/s (down from 14.58 MB/s) villa: 7.53 MB/s (up from 5.33 MB/s) lobos: 3.77 MB/s (down from 4.92 MB/s) If you add 18.24.0.11 to the round-robin twice (ie, steffani, villa, steffani, lobos instead of steffani, villa, lobos), you should get a more even balance between villa and lobos (about 5.65 MB/s each). Leaving them unbalanced allows for more deductions from the maths though (in particular the ability to estimate how many MB/s are due to hosts that just do pure round-robin). Having both steffani's addresses in there would (presumably) give steffani 23.60 MB/s and villa and lobos only 1.23 MB/s combined. Cheers, aj signature.asc Description: Digital signature
Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical "wish"
On Tue, Dec 18, 2007 at 03:35:51PM +0100, Josip Rodin wrote: > On Mon, Dec 17, 2007 at 07:51:18PM +0100, Martin Schulze wrote: > > > I've asked DSA for server-status already, and mentioned the logs too, > > > we'll see (they haven't replied yet). > > Server status is configured on localhost. > OK, so I started measuring that too, and the rates for the last half a day > or so are: > * villa: 20.4 rps, 6.18 Mbps > * lobos: 18.9 rps, 6.23 Mbps > * steffani: 40.0 rps, 15.92 Mbps > The ratios for both parameters are matching the general bandwidth ratios, > so the measurements should be correct. As of, umm, 2007-12-18 08:30 UTC (about 20 hours ago), testing users should be starting to hit each mirror equally. So for future numbers, we should have a noticable change which should result in all the testing users assigned to classes B and C appearing in class A. The numbers so far have gone: villa: 4.29 (19%) -> 5.33 (21%) -> 6.18 (22%) lobos: 3.91 (17%) -> 4.92 (20%) -> 6.23 (22%) steffani: 14.86 (64%) -> 14.58 (59%) -> 15.92 (56%) The calculations give: A = 18.84 MB/s (67%) B = 9.64 MB/s (34%) C-F = -0.15 MB/s (-1%) That's obviously a pretty odd outcome for C-F, and is due to lobos getting more traffic than villa, which shouldn't be happening according to RR+rule9. I guess means that the random factors amongst about 30% of hosts (1/3rd of the hosts in class A/B) are playing a bigger role than the entirety of class C (about 5% of hosts at last estimate), ie, we have an random noise factor of about 17% (about 6.51 MB/s in total)... That's not unreasonable given the usage patterns for security.d.o, though I was hoping they'd cancel out better :( Working with requests rather than b/w, which will have noise due to the number of packages needing an update rather than the total size of the packages and Packages files needing an update, gives: A = 52.2 rps (66%) B = 22.6 rps (28%) C-F = 4.5 rps ( 6%) which is closer to what I'd expect given previous estimates, though still notably different to the earlier 55%/40%/5% split based on bandwidth. Note that A included all unstable users who'd upgraded in the past week or so, as well as 0.0.0.0-127.255.255.255 hosts. In future it will include all testing users who've upgraded since the 18th UTC, up until the DNS change. Cheers, aj signature.asc Description: Digital signature
