My mondays are generally spent (a) figuring out what went wrong over the weekend (if anything), (b) cleaning up the data pipeline which has been running on its own for three days, and (c) preparing for or sitting in meetings. Today wasn't so different.

Between my radar blanking tests, Jeff's NTPCkr tests, Josh's astropulse development, and Eric's hydrogen studies we're suddenly finding ourselves woefully low on CPU/memory power. Sure, we have 100 CPUs in our closet, but I'm kind of a fuddy-duddy when it comes to running non-critical processes on our high-availability public facing machines. This is frustrating to others as these machines are the ones best suited for the testing/development we're doing. Luckily, we have one server, maul, which can never be a critical system as it has a test motherboard which would be fine except it intermittently loses contact with the keyboard. So this is our one CPU server which is now usually overloaded to the point of unusability.

We do have two machines coming to the rescue: One from Intel, actually donated around the same time as maul. We haven't gotten around to installing an OS on it until today. Why? Well, that means also needing an IP address for it. The university charges us monthly per IP address we use, so to conserve funds we've been keen on only bringing systems online we actually intend to use, preferably to replace a current system. The second machine is a similarly powerful one that we received from a private donor last week.. but the motherboard was DOA. At least that's our theory. We'll get that replaced soon. Both systems will go a long way towards reducing our current development/testing constraints - something we haven't been worried about too much over the past decade because we've been mostly in a mode of data collection/reduction instead of final data analysis... in case you haven't noticed. I'm happy this is changing (or at least portending to change).

- Matt-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

One thing though, what is going on with the pending WUs awaiting validation? A lot of them have been completed by both parties but are still waiting in pending. This has been going on for a couple of days now. I figured someone would have put the boot to it by now. :)

One thing though, what is going on with the pending WUs awaiting validation? A lot of them have been completed by both parties but are still waiting in pending. This has been going on for a couple of days now. I figured someone would have put the boot to it by now. :)

Standard issue stuff: lack of resources on the upload server (bruno). Being that's where the results are directly stored, this is where the validators and file deleters run as well - the assimilators run elsewhere but also consume disk i/o resources reading files from bruno. So once any of these processes falls behind, it eats up resources on bruno trying to catch up, which in turn slows everything down. In any case, it's all working, albeit slowly. It should push through faster after the weekly mysql "compression" tomorrow.

- Matt-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

We do have two machines coming to the rescue: One from Intel, actually donated around the same time as maul. We haven't gotten around to installing an OS on it until today. Why? Well, that means also needing an IP address for it. The university charges us monthly per IP address we use, so to conserve funds we've been keen on only bringing systems online we actually intend to use, preferably to replace a current system.
- Matt

Are you restricted in use in-lab local network too?
Cant' imagine that campus will charge 192.168.0.x like IPs too ;)

And having local in-lab network between PCs is not bad idea in general.

Of course we can have a set of private IPs, but these are reserved for low-level appliance type stuff (service processors, UPS's, etc.) that never needs to be "seen" outside our server closet. We don't charged for those. However in the interest of administrative ease for us, and trackability (and therefore security) as well as fund raising for campus, we are pretty much obliged to have real static IPs for all our servers, desktops, NAS boxes, etc.

- Matt-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

Too bad it isn't like we are billed. We can get a static IP or dynamic IP via DHCP. If we want a static IP, then we need to supply the MAC address. However when it comes to billing, we are billed on the number of ports that are in use on the main switch.

We have gotten around this by buying a $40 5 port switch and plugging that into the wall jack before the main switch. Works great for our users that have a desktop PC for in the office and a Tablet PC for use in the field. Otherwise we would have to get another jack wired and get billed for another port in use on the main switch for when they get back to the office and do all the data synching.

10/8 is used a lot because it is usually easy to remember 10.1.1.1 since most people don't need the entire 10/8 addressable space. 192.168/16 is commonly used thanks to most household routers - but even more so because it is the smallest non-routable network segment supported in RFC1918, so it is more likely to converse without wasting space (not as if there's a shortage of RFC1918's since they can be used on any private network).

... Or any RFC1918 net block. Aside: Why are 192.168.x.x and 10.x.x.x the most often used out of all the many others?...

Back in the day, before netmasks were invented, the "size" of a network was based solely on the first two bits of the address.

If the first two bits were "00" the network was a "Class-A" network, and there are 64 possible Class-A networks with 16,777,214 hosts.

Class "B" networks started with "01" and something like 1024 of those, with 65,534 hosts.

Class "C" networks start with "11" and there are a bunch of those with 254 hosts each.

10.x.x.x. is a class-A block. 172.16.x.x through 172.31.x.x are in the class-B range, and 192.168.x.x. is class-C.

Under classful routing, if you have a small network, the 192 blocks work, and are the right size, and if your network is big, the 10-block is best.

... but the most important thing to remember about classful routing is that it is dead. CIDR solves so many problems, not the least of which is the fact that classful routing wastes so much address space.

I stay away from 192.168.0.1 and 192.168.1.1 because these blocks are so commonly used in small offices and homes, and private addresses on those networks leak into DNS, sometimes with unanticipated results. I steer clear of the 10.0.0.0/16 range for the same reason.

There really are only three RFC-1918 blocks. The 169.254.x.x block is reserved for a different purpose, and under a different RFC.

10/8 is used a lot because it is usually easy to remember 10.1.1.1 since most people don't need the entire 10/8 addressable space. 192.168/16 is commonly used thanks to most household routers - but even more so because it is the smallest non-routable network segment supported in RFC1918, so it is more likely to converse without wasting space (not as if there's a shortage of RFC1918's since they can be used on any private network).

Thanks to classless (CIDR) routing, you can carve a tiny block out of any of these address ranges.

I've been known to use 10.0.42.0/24 just to stay out of 192.168.1.0/24.

The 169.254.x.x block is reserved for a different purpose, and under a different RFC.

APIPA, or Automatic Private IP Addressing. Used when a host cannot find a Dynamic Host Configuration Protocol server (DHCP server). APIPA addresses are non-routable on the internet, just like all three RFC1918 classes.

10/8 is used a lot because it is usually easy to remember 10.1.1.1 since most people don't need the entire 10/8 addressable space. 192.168/16 is commonly used thanks to most household routers - but even more so because it is the smallest non-routable network segment supported in RFC1918, so it is more likely to converse without wasting space (not as if there's a shortage of RFC1918's since they can be used on any private network).

Thanks to classless (CIDR) routing, you can carve a tiny block out of any of these address ranges.

I've been known to use 10.0.42.0/24 just to stay out of 192.168.1.0/24.

I've been using 192.168.10.0/8 for a while now. Its different enough from home networks that I don't run into problems, but still in the Class C range. Sure, you can always subnet a Class A or Class B range, but I'm keeping it simple for now.

The 169.254.x.x block is reserved for a different purpose, and under a different RFC.

APIPA, or Automatic Private IP Addressing. Used when a host cannot find a Dynamic Host Configuration Protocol server (DHCP server). APIPA addresses are non-routable on the internet, just like all three RFC1918 classes.

... as a general rule, when I see APIPA addresses, it is a symptom of some other problem. I've never found it to be useful.

The 169.254.x.x block is reserved for a different purpose, and under a different RFC.

APIPA, or Automatic Private IP Addressing. Used when a host cannot find a Dynamic Host Configuration Protocol server (DHCP server). APIPA addresses are non-routable on the internet, just like all three RFC1918 classes.

... as a general rule, when I see APIPA addresses, it is a symptom of some other problem. I've never found it to be useful.

I find them to be very useful. When I see one, I start inspecting cables and switches for problems, and I have always found one.BOINC WIKI

I've been using 192.168.10.0/8 for a while now. Its different enough from home networks that I don't run into problems, but still in the Class C range. Sure, you can always subnet a Class A or Class B range, but I'm keeping it simple for now.

192.168.10.0/8 grabs more address space outside the RFC-1918 space than inside, including space allocated to BBN and to Level3.

Classful routing is dead, so there is no practical difference between 192.168.10.0/24 and 10.10.10.0/24.

The only time I see issues is where someone has a mail server internally on 192.168.1.2 and a spam appliance with a public IP. The "old school" way is give the lowest MX the private IP, and if that happens to be reachable on my network, mail goes to the wrong place.

The 169.254.x.x block is reserved for a different purpose, and under a different RFC.

APIPA, or Automatic Private IP Addressing. Used when a host cannot find a Dynamic Host Configuration Protocol server (DHCP server). APIPA addresses are non-routable on the internet, just like all three RFC1918 classes.

... as a general rule, when I see APIPA addresses, it is a symptom of some other problem. I've never found it to be useful.

I find them to be very useful. When I see one, I start inspecting cables and switches for problems, and I have always found one.

If you disable APIPA, you generally get 0.0.0.0 instead, which is just as useful.

The 169.254.x.x block is reserved for a different purpose, and under a different RFC.

APIPA, or Automatic Private IP Addressing. Used when a host cannot find a Dynamic Host Configuration Protocol server (DHCP server). APIPA addresses are non-routable on the internet, just like all three RFC1918 classes.

... as a general rule, when I see APIPA addresses, it is a symptom of some other problem. I've never found it to be useful.

I find them to be very useful. When I see one, I start inspecting cables and switches for problems, and I have always found one.

If you disable APIPA, you generally get 0.0.0.0 instead, which is just as useful.

Except in some networks where if a DHCP server is down for a subnet, the entire subnet will default to APIPA and still be able to communicate with each other because 169.254.x.x is still a valid IP address, whereas 0.0.0.0 is not. In some cases, having APIPA can keep limited productivity for employees whereas without APIPA they're forced to call someone in to check on it sooner rather than later. Either way, its definitely a problem, one just keeps thinks moving and the other does not.

The 169.254.x.x block is reserved for a different purpose, and under a different RFC.

APIPA, or Automatic Private IP Addressing. Used when a host cannot find a Dynamic Host Configuration Protocol server (DHCP server). APIPA addresses are non-routable on the internet, just like all three RFC1918 classes.

... as a general rule, when I see APIPA addresses, it is a symptom of some other problem. I've never found it to be useful.

I find them to be very useful. When I see one, I start inspecting cables and switches for problems, and I have always found one.

If you disable APIPA, you generally get 0.0.0.0 instead, which is just as useful.

Except in some networks where if a DHCP server is down for a subnet, the entire subnet will default to APIPA and still be able to communicate with each other because 169.254.x.x is still a valid IP address, whereas 0.0.0.0 is not. In some cases, having APIPA can keep limited productivity for employees whereas without APIPA they're forced to call someone in to check on it sooner rather than later. Either way, its definitely a problem, one just keeps thinks moving and the other does not.

In my environment, if the DHCP server is down, I've got bigger problems, and the other stuff doesn't matter.