Evolution (Feb 09 2009)

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. :)

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

... Why? Well, that means also needing an IP address for it. The university charges us...

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

Aside: Why are 192.168.x.x and 10.x.x.x the most often used out of all the many others?...

... 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?...

Aside: Why are 192.168.x.x and 10.x.x.x the most often used out of all the many others?...

As far as I'm aware, there are only three: 10.x.x.x (or 10/8 CIDR), 172.16.x.x (or 172.16/12 CIDR) and 192.168.x.x (or 192.168/16 CIDR.

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).

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

Aside: Why are 192.168.x.x and 10.x.x.x the most often used out of all the many others?...

As far as I'm aware, there are only three: 10.x.x.x (or 10/8 CIDR), 172.16.x.x (or 172.16/12 CIDR) and 192.168.x.x (or 192.168/16 CIDR.

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.

My router actually is up in 192.168.254.x area.
____________

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.

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'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.

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.

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.