Message boards :
Number crunching :
Panic Mode On (65) Server problems?
Message board moderation
Previous · 1 · 2 · 3 · 4 · 5 · 6 . . . 9 · Next
Author | Message |
---|---|
kittyman Send message Joined: 9 Jul 00 Posts: 51468 Credit: 1,018,363,574 RAC: 1,004 |
You are missing my original point.....(now obscured since AP is filling the pipe again). Amen.... "Freedom is just Chaos, with better lighting." Alan Dean Foster |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14649 Credit: 200,643,578 RAC: 874 |
Hey - I just downloaded 21jn11ac.5207.7025.3.10.244 - seems like an ordinary MB job. But the datafile is 2,794 kilobytes. So what's with that, then? Answers on a postcard..... Edit - the header looks normal, but then we get to <data length=2839876 encoding="x-setiathome"> A normal WU has <data length=354991 encoding="x-setiathome"> Spooky! |
Cosmic_Ocean Send message Joined: 23 Dec 00 Posts: 3027 Credit: 13,516,867 RAC: 13 |
Interesting indeed. Are all the other parameters the same (like FFTs or whatever it is that controls how much crunching there is)? Maybe it's just one of those oddballs at the end of a tape that can't be chopped up anymore. Linux laptop: record uptime: 1511d 20h 19m (ended due to the power brick giving-up) |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14649 Credit: 200,643,578 RAC: 874 |
Interesting indeed. Are all the other parameters the same (like FFTs or whatever it is that controls how much crunching there is)? Maybe it's just one of those oddballs at the end of a tape that can't be chopped up anymore. Too late to investigate tonight - I'm on UTC, and headed for bed. Host has a three-day cache, so we have a bit of leeway. But I've made a safety copy anyway, and I'll have a look in the morning. Edit again - looks like I may have two more of those dodgy WUs, from the same tape. They'll do wonders for the download bandwidth - not. |
Gatekeeper Send message Joined: 14 Jul 04 Posts: 887 Credit: 176,479,616 RAC: 0 |
I've got about 30 or so of the 2.7MB tasks on a couple of my boxes. Their completion times seem to be the same as the other MB tasks, so if they take much longer, they will play havoc with the DCF. Are these an unannounced drop of the "new" WU's? |
Cosmic_Ocean Send message Joined: 23 Dec 00 Posts: 3027 Credit: 13,516,867 RAC: 13 |
I've got about 30 or so of the 2.7MB tasks on a couple of my boxes. Their completion times seem to be the same as the other MB tasks, so if they take much longer, they will play havoc with the DCF. That's kind of what I was wondering when I heard about it a few minutes ago. Kind of like how way back, the precision was doubled making twice the computation, but the data size stayed the same. There's been talks of increasing either the precision or the data size to make computation time take longer. I think these WUs from that tape are just special. Linux laptop: record uptime: 1511d 20h 19m (ended due to the power brick giving-up) |
arkayn Send message Joined: 14 May 99 Posts: 4438 Credit: 55,006,323 RAC: 0 |
|
Wiggo Send message Joined: 24 Jan 00 Posts: 34744 Credit: 261,360,520 RAC: 489 |
I picked up a few of these today as well (all CUDA work). Cheers. |
zoom3+1=4 Send message Joined: 30 Nov 03 Posts: 65709 Credit: 55,293,173 RAC: 49 |
I have to wait until maybe August 2012 before I can replace the half dead EVGA GTX295 v2 card, any other brand I have no problem with as they generally don't come overclocked. The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's |
Cruncher-American Send message Joined: 25 Mar 02 Posts: 1513 Credit: 370,893,186 RAC: 340 |
I've got 25 of the King Size MBs on one machine, 0 on the other. If there are a lot of these being created, it is a sure way to eat up all the bandwidth, especially if they take as long to compute as the old 366K ones. Score another one for the SETI Team. |
Lint trap Send message Joined: 30 May 03 Posts: 871 Credit: 28,092,319 RAC: 0 |
The one comparison I am looking at shows the <subband_desc> <number> is 107 for the XL wu and just 87 for the normal sized MB. Of course the data_length is different; 2839876 for the XL and 354991 for the regular. I've no idea what <subband desc> or <number> are or how that might affect anything. Subband makes me think of radio. More radio data means... Are these maybe GBT wu's?? (updated: Nope...they're from Arecibo) I'm still looking to see if there might be any other significant diffs. Lt adding: Many changes in splitter_cfg and analysis_cfg also. |
Tim Send message Joined: 19 May 99 Posts: 211 Credit: 278,575,259 RAC: 0 |
are they 23oc11ah.32500.10292.xxxxxxxx ? I have about 15. All start with 21jn..... |
Belthazor Send message Joined: 6 Apr 00 Posts: 219 Credit: 10,373,795 RAC: 13 |
I've got 18 WUs named 21jn11ac, all of them are normally 365 kb |
Fred E. Send message Joined: 22 Jul 99 Posts: 768 Credit: 24,140,697 RAC: 0 |
I ran one to see what it would do. It was on track for a normal runtime for GPU other-than-shorties, but exited with a -9 result overflow after 9.6 minutes. Hope they don't all do that. Even if they run for normal times, it won't help the bandwith issue. http://setiathome.berkeley.edu/result.php?resultid=2284335011 Another Fred Support SETI@home when you search the Web with GoodSearch or shop online with GoodShop. |
Belthazor Send message Joined: 6 Apr 00 Posts: 219 Credit: 10,373,795 RAC: 13 |
As I remebber, before his departure Matt said that there is some experiment on the splitters software. May be 21jn11ac is a testing tape? |
Cosmic_Ocean Send message Joined: 23 Dec 00 Posts: 3027 Credit: 13,516,867 RAC: 13 |
As I remebber, before his departure Matt said that there is some experiment on the splitters software. May be 21jn11ac is a testing tape? Here's what was said: Another project I've been working on is to get the splitters (the programs that make workunits out of raw data) to become sensitive to VGC (voltage gain control) values available in the raw data headers so that we can avoid splitting areas with low VGC values (and therefore loud noise). In layman's terms: we're trying to set everything up to automatically reject noisy workunits before sending them out. We know one or two beams (out of fourteen) are sometimes flaky, and keeping those workunits out of the pipeline will help reduce network competition for downloads. Basically it's what I've been suggesting for those AP WUs that take 16MB of download bandwidth and error out in 20 seconds due to 100% blanking. Find a way server-side to find these before they get sent out. It's being worked on, but I don't think that is what is going on with these huge MB WUs. Linux laptop: record uptime: 1511d 20h 19m (ended due to the power brick giving-up) |
ivan Send message Joined: 5 Mar 01 Posts: 783 Credit: 348,560,338 RAC: 223 |
I've been getting a lot of download errors today, but only on the big iron at work, it would seem. Nothing to do with the big MB WUs as far as I can tell. I'd guess it's something to do with our network, unless others are seeing it too -- a couple of days ago I could only get 30 kB/s upgrade downloads from CERN, where I normally get 2 MB/s or more. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14649 Credit: 200,643,578 RAC: 874 |
The one comparison I am looking at shows the <subband_desc> <number> is 107 for the XL wu and just 87 for the normal sized MB. Of course the data_length is different; 2839876 for the XL and 354991 for the regular. Well, I've just done a comparison of 21jn11ac.5207.16432.3.10.154 (mega size WU) 21jn11ac.14219.16432.6.10.73 (normal size WU) All the mega WUs seem to have .5207. as the second element of the name: those two match as closely as I can find in my cache for the other elements. The mega WU was split from Beam 0, Polarisation 0: the normal one from Beam 1, Polarisation 1. That leads to minor differences in the telescope aiming point at identical coordinate times, which is to be expected - the seven separate antennae which make up our "multibeam" signal sit side-by-side at (or near) the telescope's focal point, so naturally they have a slighly different field of view - that's the whole idea. There are different array_ellipse values, probably again because of the different beams in use: and the subband numbers differ - they are 154 and 73 respectively, as you'd expect from the final elements of the WU names. Apart from that, there seem to be no significant differences at all - certainly nothing to explain the different data lengths. But I'll keep the WU files, just in case. |
Kevin Olley Send message Joined: 3 Aug 99 Posts: 906 Credit: 261,085,289 RAC: 572 |
Hey - I just downloaded 21jn11ac.5207.7025.3.10.244 - seems like an ordinary MB job. Got 13 here, 12 for GPU and 1 for CPU. I have made backup copies, if anyone's interested. They should be processed tomorrow. Kevin |
David S Send message Joined: 4 Oct 99 Posts: 18352 Credit: 27,761,924 RAC: 12 |
....I can tell you this. The Crickets' hiccups this week (another one starting now) notwithstanding, my best rig is rebuilding its cache and is now within 10 of its limit. (OTOH, the wifi here at work is having major fits today; this is the third time I've typed this message.) David Sitting on my butt while others boldly go, Waiting for a message from a small furry creature from Alpha Centauri. |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.