Message boards :
Technical News :
Working as Expected (Jul 13 2009)
Message board moderation
Previous · 1 . . . 7 · 8 · 9 · 10 · 11 · Next
Author | Message |
---|---|
Gundolf Jahn Send message Joined: 19 Sep 00 Posts: 3184 Credit: 446,358 RAC: 0 |
Has he been run over by a bus, has he got swine flu, on holiday or what? "Holiday" it is. And there have been several posts (in other threads) to mention that. Gruß, Gundolf |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
Observation FWIW. I'm getting consistently: 22/07/2009 11:16:55||[http_debug] [ID#0] info: Empty reply from server 22/07/2009 11:16:55||[http_debug] HTTP error: server returned nothing (no headers, no data) That sounds like a server problem, not a network problem. |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13727 Credit: 208,696,464 RAC: 304 |
On uploads or downloads? There's (effectively) no network traffic of mention at the moment, but my uploads are having greater difficulty getting through than when things were previously at their absolute limits. Grant Darwin NT |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
Uploads. |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13727 Credit: 208,696,464 RAC: 304 |
I'm thinking something got tweaked during the outage, and hasn't worked quite as expected. EDIT- Another result just joined the queue. Tried manaully retrying it, most times it will time out instantly (like with the tweak to kill off excess connections when under heavy load instead of queueing them). When it doesn't time out instantly, it takes about 30 seconds for the download to actually start. Grant Darwin NT |
OzzFan Send message Joined: 9 Apr 02 Posts: 15691 Credit: 84,761,841 RAC: 28 |
I'm happy to hand the issue over to the mods for comment. Ah, but I did read him saying something, only it was where you guys can't see it. ;) |
ML1 Send message Joined: 25 Nov 01 Posts: 20258 Credit: 7,508,002 RAC: 20 |
Wow! About 70Mbit/s on the downloads, and: All http connections look sweet and smooth and fast. A complete change for the better from previous days. Either everyone has gone on holiday or some data-rate management fixes have been implemented. (Or?) Good stuff, Happy crunchin', Martin See new freedom: Mageia Linux Take a look for yourself: Linux Format The Future is what We all make IT (GPLv3) |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
Wow! Is that both directions, or just downloads? I'm just getting the very occasional successful upload - all others get the 'empty server reply'. If your http upload works differently from the Windows one, I may just have to consider Linux after all..... :-) |
PhonAcq Send message Joined: 14 Apr 01 Posts: 1656 Credit: 30,658,217 RAC: 1 |
Things aren't that good. I've had about 3h of frequent rejected communications after a large upload/download cycle. Cricket implies there is headroom, but my message log is full of failures. |
ML1 Send message Joined: 25 Nov 01 Posts: 20258 Credit: 7,508,002 RAC: 20 |
Wow! Downloads show about 55Mbit/s and uploads look steady at just under 10Mbits/s. All my uploads cleared immediately except for just two WUs. The WU cache built up quite quickly to the usual 0.5 day cache. ... OK, so a bit of 'playing' and I've now got 25+ or so WUs. They all downloaded in pairs, consistently, all sweet and smooth, no resends. The two pending uploads are from before the maintenance shutdown last night and appear to get their connections refused. DNS change?... Or are Berkeley now limiting the maximum number of simultaneous connections rather than limiting WU generation rate? Whatever, all a vast improvement over the chaos of a saturated link. I'll see what happens to the two pending WU uploads... (And hey, it's always worth at least a giggle to give Linux a try ;-) ) Happy crunchin', Martin [edit] Might be a coincidence but you might actually notice the little blip in the Cricket chart just now. Was that really me? [/edit] See new freedom: Mageia Linux Take a look for yourself: Linux Format The Future is what We all make IT (GPLv3) |
HAL Send message Joined: 28 Mar 03 Posts: 704 Credit: 870,617 RAC: 0 |
I used to have a 2 processor pentium D according to the old version of boinc installed on it. Taking advantage of the fact it was out of work I installed the new version which I was told was available when I started it up. NOW boinc tells me it is a single processor - and my preferences are correct. In fact the CPU benchmark tells me it is a single processor but everybody else tells me it has 2. I guess I just take it off boinc completely until the smoke from the current situation clears away. Indeed here thing are getting worse. |
OzzFan Send message Joined: 9 Apr 02 Posts: 15691 Credit: 84,761,841 RAC: 28 |
I used to have a 2 processor pentium D according to the old version of boinc installed on it. Taking advantage of the fact it was out of work I installed the new version which I was told was available when I started it up. Your issue seems to be different than the server issues everyone has been going on about in this thread. The servers have no control over how many CPUs BOINC "sees", but your preferences can limit how many CPUs BOINC can use. Indeed, a Pentium D processor is Intel's first dual-core attempt. I would double-check your local preferences to see if you didn't accidentally set them. Otherwise, you may want to ask for assistance over in the Q&A Forum. I'm sure we can get your situation solved for you. |
ivan Send message Joined: 5 Mar 01 Posts: 783 Credit: 348,560,338 RAC: 223 |
Another frustrating Mon. Have been trying to upload/download work units for three weeks. Very sporadic at best. Managing only one connection per week for two in a row. I wish someone would let us know what's up. I started running Boinc for Seti@home when the classic S@H was shut down and am not really interested in running other "filler" projects. Thanks, and any information would very welcome. I have a theory, and my theory is this. When things get reset at the Lab, their DHCP server doesn't necessarily reassign the same IP number to a given machine. So BOINC keeps trying to send results, etc. to a "stale" address, because it doesn't know the assignment has changed. When this happens I find that stopping BOINC, flushing the DNS cache[1], and restarting BOINC often helps. [1] Windows: ipconfig /flushdns Linux: (maybe) sudo /etc.init.d/nscd restart |
OzzFan Send message Joined: 9 Apr 02 Posts: 15691 Credit: 84,761,841 RAC: 28 |
Another frustrating Mon. Have been trying to upload/download work units for three weeks. Very sporadic at best. Managing only one connection per week for two in a row. I wish someone would let us know what's up. I started running Boinc for Seti@home when the classic S@H was shut down and am not really interested in running other "filler" projects. Thanks, and any information would very welcome. I'm certain that any internet-facing machines are using static IP addresses. |
Anthony Liggins Send message Joined: 23 Aug 99 Posts: 14 Credit: 609,816 RAC: 0 |
Hi I am fairly new to the forum, but reading this thread has compelled me to add to it. An easy way to look at this is 32 bit = slow 64 bit = fast GPU = fast all you have to do then is find a happy medium and throttle between them. Anthony. |
OzzFan Send message Joined: 9 Apr 02 Posts: 15691 Credit: 84,761,841 RAC: 28 |
Hi What about modern computers operating in 32bit mode? I also wouldn't consider my AMD Athlon XP 3200+, which is 32bit only, a "slow" computer. Nor would I call my Pentium 4 Extreme Edition 3.2GHz w/HT - also 32bit only - a "slow" computer, even if by today's standards technology has surpassed them. |
Anthony Liggins Send message Joined: 23 Aug 99 Posts: 14 Credit: 609,816 RAC: 0 |
Well that simple, the database will know if a processor is a true 32 or true 64 bit and or 64 bit running in 32 bit mode, this would still be marked as fast, as it displays the processor information and the operating system that a participant is using. How long does it take your machine to crunch an average wu? I have 2 retired supermicro servers each one has (2) 3.2Ghz/533 DP xeons, on average it takes about 8hrs to crunch a normal wu, 11hrs for the larger ones, and about 3hrs for the short ones. Anthony. |
OzzFan Send message Joined: 9 Apr 02 Posts: 15691 Credit: 84,761,841 RAC: 28 |
Well that simple, the database will know if a processor is a true 32 or true 64 bit and or 64 bit running in 32 bit mode, this would still be marked as fast, as it displays the processor information and the operating system that a participant is using. 64bit still hasn't even caught on yet in the general market, so why should SETI consider 64bit CPUs running on 64bit OSes to be the only "fast" ones is what I was trying to get across. How long does it take your machine to crunch an average wu? The speed isn't entirely the point. SETI shouldn't only be about speed, except those who are only interested in RAC. I have 2 retired supermicro servers each one has (2) 3.2Ghz/533 DP xeons, on average it takes about 8hrs to crunch a normal wu, 11hrs for the larger ones, and about 3hrs for the short ones. Sounds about as fast as my current file server which is a dual Xeon 3.4GHz/800 DP with 4GB of DDR2 RAM. Still not necessarily "slow" by any means. |
Anthony Liggins Send message Joined: 23 Aug 99 Posts: 14 Credit: 609,816 RAC: 0 |
CUDA is the big culprit in all of this, limiting CUDA would be the best option, untill they can get a Gbit network upgrade, but that could be a long way off. I do get your point, I am in it for the science not the RAC, and I do agree with you, they are not slow by any means, but sadly most 64 bit processors are running on a 32 bit opperating system; which is a bit of a waste. A 64 bit processor running in 32 bit mode is still a 64 bit processor, and todays CPU's are uber fast. My old Athlon 64 3700 crunched an average wu in about 3hrs; the OS was 64 bit optomised Linux. Go forward 5 years to today, a DP or QP does the same size wu in arround 30 to 45 mins, include the GPU's and it doen't take long to realise that demand will continue to out strip supply of wu's, and continue to add to the network woe's of S&H. The servers will continue to struggle to keep up, as demand is high, S@H are going to have to do something pretty radical soon, because the whole system is creaking and is constanly falling over, I have been cruching for 10 years, and I have never ever seen it this bad before. My servers have 4Gb DDR 266, I am a bit surprised that your file server is not faster than that, considering fsb 800's were the next step up from mine. |
OzzFan Send message Joined: 9 Apr 02 Posts: 15691 Credit: 84,761,841 RAC: 28 |
CUDA is the big culprit in all of this, limiting CUDA would be the best option, untill they can get a Gbit network upgrade, but that could be a long way off. Agreed. I do get your point, I am in it for the science not the RAC, and I do agree with you, they are not slow by any means, but sadly most 64 bit processors are running on a 32 bit opperating system; which is a bit of a waste. Perhaps. I think any system needing 64bit OSes have them. 32bit OSes are still put on consumer machines for compatibility reasons, but I'm sure that 64bit will become the norm eventually. A 64 bit processor running in 32 bit mode is still a 64 bit processor, and todays CPU's are uber fast. True, but when running in 32bit mode, you lose half the registers in the CPU. The servers will continue to struggle to keep up, as demand is high, S@H are going to have to do something pretty radical soon, because the whole system is creaking and is constanly falling over, I have been cruching for 10 years, and I have never ever seen it this bad before. This is the worst I've seen it in my seven years, but I'm told that there were worse outages back with SETI Classic, its only that many didn't notice because WUs back then took so long to crunch on the average machine that the server could be down for nearly a week before people would notice. My servers have 4Gb DDR 266, I am a bit surprised that your file server is not faster than that, considering fsb 800's were the next step up from mine. Now that Eric has increased the sensitivity in the applications, its hard to make a direct comparison, but you're right, my times were wrong. Smaller WUs took only 45 min to crunch, while larger ones can take as long as 4-6 hours. It also helps that my Xeons have the 2MB L2 cache too. |
©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.