Furniture Shortage (Jan 03 2008)

Spreading the workunit creation over several files at once seems to be helping create a healthier mix of fast/slow workunits. However, adding a second download server seems to have confirmed a suspicion of mine (key word: "seems"): that somewhere down the pike we're being capped at 60 Mbits/sec. For a while there we had two download servers and a workunit storage server with plenty I/O capacity to spare, but still we were hitting a hard 60 Mbit ceiling outbound. Inquiries are being drafted/sent to the appropriate parties. It still could be a local problem, but we're not sure what else to try (given our current hardware).

We are in the middle of building another helpful index on the science database. Looks like Bob's magic informix incantations are working - we can keep the project running simultaneously (though the assimilators might back up a bit). It is always happier around here when work is flowing. To be safe we increased the ready-to-send queue size to one million - we have the disk space now to keep more workunits around. The only downside is that this inflates the result table in the database by approximately 5-10%, which may exercise the RAM on the BOINC database server that much more.

There is another problem Dave and I were poking at today: excessive "out of range" failures on our public web sites. Here's the deal: BOINC clients have a nice GUI which shows you icons, pictures, etc. from different projects as you select which to run on your computer. Where does it get these files? From the project's web servers. This is all well and good, but there are several (hundreds? thousands?) older clients out there making such requests but are being met with 416 "range not satisfiable" errors. Why? Because they have already downloaded the image file, but are making requests for more bytes beyond the file boundaries as if there was more to download. Obviously a bug somewhere, or a change in the way apache handles such things, but there's not much we can do about it. Even though this activity is creating bursts of heavy load on our web servers, this is a fire we're going to let burn for now.

The official press release about multi-beam is finally out. This should help on many levels (though I'll be busier making sure the servers can handle any significant load increase). I guess I'll also be shaving every morning in case there is interest from the national television news media.

I guess this is "technical" news: Our desks/chairs/furniture are mostly ancient hand-me-downs, some pieces older than I. We did get some new chair donations recently, but one of them broke - it came loose from its base, causing unsuspecting sitters to suddenly fall forward if their balance wasn't particularly keen. It's been lurking in our lab way too long, coaxing uninformed standers with tired legs to rest upon its comfortable and seemingly stable cushion base. I came to the lab this morning and that evil chair was by my desk with a note taped to it: "Matt - can you please toss this chair?" I guess enough was enough. I dragged it to the dumpster and sent it back to the dark void from whence it came.

- 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

There is another problem Dave and I were poking at today: excessive "out of range" failures on our public web sites. Here's the deal: BOINC clients have a nice GUI which shows you icons, pictures, etc. from different projects as you select which to run on your computer. Where does it get these files? From the project's web servers. This is all well and good, but there are several (hundreds? thousands?) older clients out there making such requests but are being met with 416 "range not satisfiable" errors. Why? Because they have already downloaded the image file, but are making requests for more bytes beyond the file boundaries as if there was more to download. Obviously a bug somewhere, or a change in the way apache handles such things, but there's not much we can do about it. Even though this activity is creating bursts of heavy load on our web servers, this is a fire we're going to let burn for now.

The gui-image-files doesn't include <nbytes> as they should, client therefore has no idea how large these apparently zero-byte-files really are.

..interesting. I just added those fields to our project_files.xml and restarted all the servers. No immediate effect.

Matt I know things get old I set in a chair that sounds just the same as you had there, thanks for telling errors where coming from your end, after I just spent 500 bucks on new ram, And another 1500 bucks for a new processor thinking that it was coming my unit.. I Could have gotten a new chair for thee butt.
____________

looks like the Technical news page has php issues

http://setiathome.berkeley.edu/tech_news.php



Parse error: syntax error, unexpected T_STRING, expecting ')' in /disks/setifiler1/home/boincadm/projects/sah/html/project/flat_tech_news.inc on line 5
____________

I'd guess the science status page is cosmetically acting up too -- Due to the science database table juggling going on maybe?
-256,129,382 Gaussians inserted in the last 24 hours. (for a grand total of 0)

Jason

____________
"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change."
Charles Darwin

Matt...very much appreciate your updates,
But can you explain why the forum response has been so poor lately, even though the total bandwidth as displayed by the Cricket Graphs seems back down to reasonable levels?
____________
******

"Ask not, what your kitty can do for you. Ask what you can do for your kitty."

As it is kitten, so shall it be done.

So off the home page I hit the link for technical news and
"Parse error: syntax error, unexpected T_STRING, expecting ')' in /disks/setifiler1/home/boincadm/projects/sah/html/project/flat_tech_news.inc on line 5"

As for that data rate throttle, I think elsewhere you indicated that the fiber to the lab was shared by others up on the hill. Could be something is being held in reserve for other users even if they aren't using it, which someone should know about. Or there could be campus equipment that simply is maxing out somewhere on the path, which no one knows has either failed or wasn't spec'd right to begin with. The only way to know is test. You do have dead time to test while you do the weekly pipe cleanup.

Gary

Spreading the workunit creation over several files at once seems to be helping create a healthier mix of fast/slow workunits. However, adding a second download server seems to have confirmed a suspicion of mine (key word: "seems"): that somewhere down the pike we're being capped at 60 Mbits/sec. For a while there we had two download servers and a workunit storage server with plenty I/O capacity to spare, but still we were hitting a hard 60 Mbit ceiling outbound. Inquiries are being drafted/sent to the appropriate parties. It still could be a local problem, but we're not sure what else to try (given our current hardware).

We are in the middle of building another helpful index on the science database. Looks like Bob's magic informix incantations are working - we can keep the project running simultaneously (though the assimilators might back up a bit). It is always happier around here when work is flowing. To be safe we increased the ready-to-send queue size to one million - we have the disk space now to keep more workunits around. The only downside is that this inflates the result table in the database by approximately 5-10%, which may exercise the RAM on the BOINC database server that much more.

There is another problem Dave and I were poking at today: excessive "out of range" failures on our public web sites. Here's the deal: BOINC clients have a nice GUI which shows you icons, pictures, etc. from different projects as you select which to run on your computer. Where does it get these files? From the project's web servers. This is all well and good, but there are several (hundreds? thousands?) older clients out there making such requests but are being met with 416 "range not satisfiable" errors. Why? Because they have already downloaded the image file, but are making requests for more bytes beyond the file boundaries as if there was more to download. Obviously a bug somewhere, or a change in the way apache handles such things, but there's not much we can do about it. Even though this activity is creating bursts of heavy load on our web servers, this is a fire we're going to let burn for now.

The official press release about multi-beam is finally out. This should help on many levels (though I'll be busier making sure the servers can handle any significant load increase). I guess I'll also be shaving every morning in case there is interest from the national television news media.

I guess this is "technical" news: Our desks/chairs/furniture are mostly ancient hand-me-downs, some pieces older than I. We did get some new chair donations recently, but one of them broke - it came loose from its base, causing unsuspecting sitters to suddenly fall forward if their balance wasn't particularly keen. It's been lurking in our lab way too long, coaxing uninformed standers with tired legs to rest upon its comfortable and seemingly stable cushion base. I came to the lab this morning and that evil chair was by my desk with a note taped to it: "Matt - can you please toss this chair?" I guess enough was enough. I dragged it to the dumpster and sent it back to the dark void from whence it came.

- Matt

I'd guess the science status page is cosmetically acting up too -- Due to the science database table juggling going on maybe?
-256,129,382 Gaussians inserted in the last 24 hours. (for a grand total of 0)

Jason

Can somebody please explain the overflow rate?

Thanks Matt and Seti again for the hard work!

[quote]For a while there we had two download servers and a workunit storage server with plenty I/O capacity to spare, but still we were hitting a hard 60 Mbit ceiling outbound.

I think I have an answer to some problems and a solution, I using a quad chip and ran the ting using all of it to run in Boinc for points as the heat want higher in this room too I got errors in my stats I did find out that if I tuned Boinc to use only two of the Processors I got no stats errors, its cooler in this room, and the computer run smoother, the only thing here is I have 1000kbps net and piping all of the information back through a bottle neck 10Mbps set to 768Kbps upload system. I can’t wait tell they put Fiber wire here. if all of us clents looked in this matter we would stop loading bad infomation back into your drives.

Can somebody please explain the overflow rate?

Thanks Matt and Seti again for the hard work!