Evolution (Feb 09 2009)


log in

Advanced search

Message boards : Technical News : Evolution (Feb 09 2009)

1 · 2 · Next
Author Message
Profile Matt Lebofsky
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar
Send message
Joined: 1 Mar 99
Posts: 1389
Credit: 74,079
RAC: 0
United States
Message 863912 - Posted: 9 Feb 2009, 22:48:18 UTC

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

Profile perryjay
Volunteer tester
Avatar
Send message
Joined: 20 Aug 02
Posts: 3377
Credit: 15,214,705
RAC: 11,857
United States
Message 863922 - Posted: 9 Feb 2009, 23:41:07 UTC - in response to Message 863912.

Thanks for the update Matt.

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


PROUD MEMBER OF Team Starfire World BOINC

Profile Matt Lebofsky
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar
Send message
Joined: 1 Mar 99
Posts: 1389
Credit: 74,079
RAC: 0
United States
Message 863928 - Posted: 9 Feb 2009, 23:56:36 UTC - in response to Message 863922.

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

John G
Send message
Joined: 29 Dec 01
Posts: 63
Credit: 10,142,278
RAC: 0
Canada
Message 863931 - Posted: 10 Feb 2009, 0:10:17 UTC - in response to Message 863928.

Makes a little sense to me Matt

Keep up the great work

Gldd the real science is going to finally get done

Regards

john

Profile Raistmer
Volunteer developer
Volunteer tester
Avatar
Send message
Joined: 16 Jun 01
Posts: 3386
Credit: 46,244,256
RAC: 7,246
Russia
Message 864038 - Posted: 10 Feb 2009, 9:57:22 UTC - in response to Message 863912.

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.


Profile ML1
Volunteer tester
Send message
Joined: 25 Nov 01
Posts: 8359
Credit: 4,097,850
RAC: 1,216
United Kingdom
Message 864092 - Posted: 10 Feb 2009, 15:50:49 UTC - in response to Message 864038.
Last modified: 10 Feb 2009, 15:51:32 UTC

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

SSsssshhhhhhh!... ;-)

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


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

Just an admin headache for tunnelling in from outside of the lab for remote access... Rather a pain for the R&D type working!


Regards,
Martin
____________
See new freedom: Mageia4
Linux Voice See & try out your OS Freedom!
The Future is what We make IT (GPLv3)

Profile Matt Lebofsky
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar
Send message
Joined: 1 Mar 99
Posts: 1389
Credit: 74,079
RAC: 0
United States
Message 864094 - Posted: 10 Feb 2009, 16:02:45 UTC - in response to Message 864092.

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

P51 Mustang
Send message
Joined: 7 Sep 99
Posts: 7
Credit: 8,633,002
RAC: 0
United States
Message 864422 - Posted: 11 Feb 2009, 21:11:54 UTC - in response to Message 864094.

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

OzzFan
Volunteer tester
Avatar
Send message
Joined: 9 Apr 02
Posts: 13566
Credit: 29,795,877
RAC: 16,628
United States
Message 864434 - Posted: 11 Feb 2009, 22:12:18 UTC - in response to Message 864092.

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

1mp0£173
Volunteer tester
Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 864467 - Posted: 12 Feb 2009, 0:27:41 UTC - in response to Message 864092.

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

1mp0£173
Volunteer tester
Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 864468 - Posted: 12 Feb 2009, 0:28:48 UTC - in response to Message 864434.

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

OzzFan
Volunteer tester
Avatar
Send message
Joined: 9 Apr 02
Posts: 13566
Credit: 29,795,877
RAC: 16,628
United States
Message 864481 - Posted: 12 Feb 2009, 1:03:43 UTC - in response to Message 864467.
Last modified: 12 Feb 2009, 1:08:09 UTC

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

OzzFan
Volunteer tester
Avatar
Send message
Joined: 9 Apr 02
Posts: 13566
Credit: 29,795,877
RAC: 16,628
United States
Message 864483 - Posted: 12 Feb 2009, 1:06:02 UTC - in response to Message 864468.

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.


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

Profile arkaynProject donor
Volunteer tester
Avatar
Send message
Joined: 14 May 99
Posts: 3615
Credit: 48,268,934
RAC: 36,309
United States
Message 864492 - Posted: 12 Feb 2009, 1:41:16 UTC

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

1mp0£173
Volunteer tester
Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 864522 - Posted: 12 Feb 2009, 2:22:48 UTC - in response to Message 864481.

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

John McLeod VII
Volunteer developer
Volunteer tester
Avatar
Send message
Joined: 15 Jul 99
Posts: 24240
Credit: 519,558
RAC: 57
United States
Message 864524 - Posted: 12 Feb 2009, 2:25:43 UTC - in response to Message 864522.

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

1mp0£173
Volunteer tester
Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 864526 - Posted: 12 Feb 2009, 2:27:28 UTC - in response to Message 864483.

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

1mp0£173
Volunteer tester
Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 864527 - Posted: 12 Feb 2009, 2:29:09 UTC - in response to Message 864524.
Last modified: 12 Feb 2009, 2:29:25 UTC

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

OzzFan
Volunteer tester
Avatar
Send message
Joined: 9 Apr 02
Posts: 13566
Credit: 29,795,877
RAC: 16,628
United States
Message 864543 - Posted: 12 Feb 2009, 3:20:39 UTC - in response to Message 864527.

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

1mp0£173
Volunteer tester
Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 864552 - Posted: 12 Feb 2009, 3:44:24 UTC - in response to Message 864543.

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.

____________

1 · 2 · Next

Message boards : Technical News : Evolution (Feb 09 2009)

Copyright © 2014 University of California