As something about the situation seems to be suppressing most download requests (my queues have shrunk a lot), I wondered whether the lack of retries might just reflect a lack of request. So I triggered a download by doing an update on a host which actually had a ready to report or two. The four files to download all failed on first try, but within about five minutes all four had succeeded, so averaging perhaps two or three retries each. That seems much, much better than I'm getting on uploads currently.
MY PC had the same problem; and I just found out why. It had maxxed out the 2GB it thought it had available to use, and was ignoring the higher limit I set via computing preferences on the E@H and MW sites. I was able to make a higher value stick by editing the preferences in the boinc manager GUI.
and I just found out why. It had maxxed out the 2GB it thought it had available to use, and was ignoring the higher limit I set via computing preferences on the E@H and MW sites. I was able to make a higher value stick by editing the preferences in the boinc manager GUI.
Probably you previously had changed another preference in the local preferences. That creates a global_prefs_override.xml file and, as the name suggests, subsequently all values stored therein override the corresponding ones changed online.
To revert to the online preferences, click the Clear button in the local preferences.
Gruß,
Gundolf
[edit]Perhaps the thread Excessive Disk Usage might be of interest for you.[/edit]
Computer sind nicht alles im Leben. (Kleiner Scherz)
I've been watching this tread with many saying they have problems uploading results/reporting and downloading new work, and thought my problems would go away.
Unfortunately, my uploading results continue plaguing me, like it does others.
It seems a manual Updating request in BM seems to be the most effective way of getting things going.
Could this be the results of Too many server requests hitting Einstein at the same time and things timing out?
Shih-Tzu are clever, cuddly, playful and rule!! Jack Russell are feisty!
I see one task stuck in retry mode each day recently. I was wondering if it was just me. I'm glad these boards exist so I can see that it is not just my computer having problems like this. I was going to blame my flakey DSL when it rains, but I can rule that out now.
The server is probably overloaded, or has some probs - 'ping einstein-dl.aei.uni-hannover.de' is ok.
I have these probs with uploads and downloads since a couple of days too. Server atlas1.atlas.aei.uni-hannover.de is reacting on pings, but ABP-stats page does not load atm. It worked out some hours ago.
So just sit down and wait for better weather. ;)
[Edit] There are only S5GCE workunits left to send for about 3 days, so let's hope the situation does not become worse.
05/05/2010 11:34:04|Einstein@Home|[sched_op_debug] Starting scheduler request
05/05/2010 11:34:04|Einstein@Home|Sending scheduler request: To fetch work. Requesting 165 seconds of work, reporting 0 completed tasks
05/05/2010 11:34:10|Einstein@Home|Scheduler request succeeded: got 1 new tasks
05/05/2010 11:34:10|Einstein@Home|[sched_ops_debug] Server version 611
05/05/2010 11:34:10|Einstein@Home|Project requested delay of 60.000000 seconds
05/05/2010 11:34:10|Einstein@Home|[sched_op_debug] Deferring communication for 1 min 0 sec
05/05/2010 11:34:10|Einstein@Home|[sched_op_debug] Reason: requested by project
05/05/2010 11:34:12|Einstein@Home|Started download of p2030_53701_70269_0165_G37.35-01.66.N_3_236.binary
05/05/2010 11:34:12||[file_xfer_debug] URL: http://einstein-dl.aei.uni-hannover.de/EinsteinAtHome/download/37b/p2030_53701_70269_0165_G37.35-01.66.N_3_236.binary
05/05/2010 11:34:34||[file_xfer_debug] FILE_XFER_SET::poll(): http op done; retval -107
05/05/2010 11:34:34||[file_xfer_debug] file transfer status -107
05/05/2010 11:34:34|Einstein@Home|Temporarily failed download of p2030_53701_70269_0165_G37.35-01.66.N_3_236.binary: system connect
05/05/2010 11:34:34|Einstein@Home|Backing off 1 min 0 sec on download of p2030_53701_70269_0165_G37.35-01.66.N_3_236.binary
05/05/2010 11:37:34|Einstein@Home|Started download of p2030_53701_70269_0165_G37.35-01.66.N_3_236.binary
05/05/2010 11:37:34||[file_xfer_debug] URL: http://einstein-dl.aei.uni-hannover.de/EinsteinAtHome/download/37b/p2030_53701_70269_0165_G37.35-01.66.N_3_236.binary
05/05/2010 11:39:08||[file_xfer_debug] FILE_XFER_SET::poll(): http op done; retval -184
05/05/2010 11:39:08||[file_xfer_debug] file transfer status -184
05/05/2010 11:39:08|Einstein@Home|Temporarily failed download of p2030_53701_70269_0165_G37.35-01.66.N_3_236.binary: http error
05/05/2010 11:39:08|Einstein@Home|Backing off 1 min 0 sec on download of p2030_53701_70269_0165_G37.35-01.66.N_3_236.binary
05/05/2010 11:41:32|Einstein@Home|Started download of p2030_53701_70269_0165_G37.35-01.66.N_3_236.binary
05/05/2010 11:41:32||[file_xfer_debug] URL: http://einstein-dl.aei.uni-hannover.de/EinsteinAtHome/download/37b/p2030_53701_70269_0165_G37.35-01.66.N_3_236.binary
05/05/2010 11:42:03||[file_xfer_debug] FILE_XFER_SET::poll(): http op done; retval 0
05/05/2010 11:42:03||[file_xfer_debug] file transfer status 0
05/05/2010 11:42:03|Einstein@Home|Finished download of p2030_53701_70269_0165_G37.35-01.66.N_3_236.binary
05/05/2010 11:42:03|Einstein@Home|[file_xfer_debug] Throughput 68848 bytes/sec
Gruß,
Gundolf
This is weird, I only see a single(!) try in access.log and nothing at all in error.log - thus I suppose it's never really hit the apache here in Hannover.
The server is probably overloaded, or has some probs - 'ping einstein-dl.aei.uni-hannover.de' is ok.
I have these probs with uploads and downloads since a couple of days too. Server atlas1.atlas.aei.uni-hannover.de is reacting on pings, but ABP-stats page does not load atm. It worked out some hours ago.
Actually, the number of errors and the load are much lower over the past days, than in the long weeks before. The system is very busy, but not that bad.
When we had the same problems at SETI, there was just one small cryptic comment from the Admins that 'Campus' had done something which cured it. 'Campus', in this case, being the Berkeley IT service who manage/maintain the routers, switches and cabling.
I dismissed it mentally as an excuse at the time (I couldn't see how that would spoof an [RST] packet from the destination server's IP address), but maybe there was something to it. I gather there have been some security adviories recently on the big Cisco routers these networks tend to use - could that be an area worthy of attention?
RE: As something about the
)
MY PC had the same problem; and I just found out why. It had maxxed out the 2GB it thought it had available to use, and was ignoring the higher limit I set via computing preferences on the E@H and MW sites. I was able to make a higher value stick by editing the preferences in the boinc manager GUI.
Win7-64, boinc 6.10.18
RE: MY PC had the same
)
I don't think it's the same problem ;-)
Probably you previously had changed another preference in the local preferences. That creates a global_prefs_override.xml file and, as the name suggests, subsequently all values stored therein override the corresponding ones changed online.
To revert to the online preferences, click the Clear button in the local preferences.
Gruß,
Gundolf
[edit]Perhaps the thread Excessive Disk Usage might be of interest for you.[/edit]
Computer sind nicht alles im Leben. (Kleiner Scherz)
ok a bit longer than a few
)
ok a bit longer than a few hours and i see others have posted as well, figure ill post some of mine as well.
oddly enough, i dont see any more 0 byte error's after enabling the debug, so either the restart fixed that or im just missing it in the log.
edit: changed pre tag to code tag.
seeing without seeing is something the blind learn to do, and seeing beyond vision can be a gift.
RE: edit: changed pre tag
)
Yeah, [pre] is no fun here at Einstein ;-)
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
I've been watching this tread
)
I've been watching this tread with many saying they have problems uploading results/reporting and downloading new work, and thought my problems would go away.
Unfortunately, my uploading results continue plaguing me, like it does others.
It seems a manual Updating request in BM seems to be the most effective way of getting things going.
Could this be the results of Too many server requests hitting Einstein at the same time and things timing out?
Shih-Tzu are clever, cuddly, playful and rule!! Jack Russell are feisty!
I see one task stuck in retry
)
I see one task stuck in retry mode each day recently. I was wondering if it was just me. I'm glad these boards exist so I can see that it is not just my computer having problems like this. I was going to blame my flakey DSL when it rains, but I can rule that out now.
The server is probably
)
The server is probably overloaded, or has some probs - 'ping einstein-dl.aei.uni-hannover.de' is ok.
I have these probs with uploads and downloads since a couple of days too. Server atlas1.atlas.aei.uni-hannover.de is reacting on pings, but ABP-stats page does not load atm. It worked out some hours ago.
So just sit down and wait for better weather. ;)
[Edit] There are only S5GCE workunits left to send for about 3 days, so let's hope the situation does not become worse.
RE: Here an excerpt for
)
This is weird, I only see a single(!) try in access.log and nothing at all in error.log - thus I suppose it's never really hit the apache here in Hannover.
80.xxx.yyy.23 - - [05/May/2010:11:41:59 +0200] "GET /EinsteinAtHome/download/37b/p2030_53701_70269_0165_G37.35-01.66.N_3_236.binary HTTP/1.0" 200 2098320 "-" "BOINC client (windows_intelx86 5.10.45)"
RE: The server is probably
)
Actually, the number of errors and the load are much lower over the past days, than in the long weeks before. The system is very busy, but not that bad.
When we had the same problems
)
When we had the same problems at SETI, there was just one small cryptic comment from the Admins that 'Campus' had done something which cured it. 'Campus', in this case, being the Berkeley IT service who manage/maintain the routers, switches and cabling.
I dismissed it mentally as an excuse at the time (I couldn't see how that would spoof an [RST] packet from the destination server's IP address), but maybe there was something to it. I gather there have been some security adviories recently on the big Cisco routers these networks tend to use - could that be an area worthy of attention?