24/02/2013 06:32:40 | | Using proxy info from GUI
24/02/2013 06:32:40 | | Not using a proxy
snip...
24/02/2013 06:32:41 | Einstein@Home | Sending scheduler request: To fetch work.
24/02/2013 06:32:41 | Einstein@Home | Requesting new tasks for NVIDIA
24/02/2013 06:32:44 | Einstein@Home | Scheduler request completed: got 2 new tasks
24/02/2013 06:32:46 | Einstein@Home | Started download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1016.bin4
24/02/2013 06:32:46 | Einstein@Home | Started download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1017.bin4
24/02/2013 06:32:46 | Einstein@Home | Started download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1018.bin4
24/02/2013 06:32:46 | Einstein@Home | Started download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1019.bin4
24/02/2013 06:32:46 | Einstein@Home | Started download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1020.bin4
24/02/2013 06:32:46 | Einstein@Home | Started download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1021.bin4
24/02/2013 06:32:46 | Einstein@Home | Started download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1022.bin4
24/02/2013 06:32:46 | Einstein@Home | Started download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1023.bin4
24/02/2013 06:32:46 | Einstein@Home | Started download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000.zap
24/02/2013 06:32:46 | Einstein@Home | Started download of p2030.20121013.G195.28-00.62.N.b4s0g0.00000_1408.bin4
24/02/2013 06:32:48 | Einstein@Home | Finished download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000.zap
24/02/2013 06:32:48 | Einstein@Home | Started download of p2030.20121013.G195.28-00.62.N.b4s0g0.00000_1409.bin4
snip...
24/02/2013 06:33:08 | Einstein@Home | Finished download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1017.bin4
24/02/2013 06:33:08 | Einstein@Home | Finished download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1020.bin4
24/02/2013 06:33:08 | Einstein@Home | Temporarily failed download of p2030.20121013.G195.28-00.62.N.b4s0g0.00000_1408.bin4: connect() failed
24/02/2013 06:33:08 | Einstein@Home | Backing off 3 min 55 sec on download of p2030.20121013.G195.28-00.62.N.b4s0g0.00000_1408.bin4
24/02/2013 06:33:08 | Einstein@Home | Started download of p2030.20121013.G195.28-00.62.N.b4s0g0.00000_1410.bin4
24/02/2013 06:33:08 | Einstein@Home | Started download of p2030.20121013.G195.28-00.62.N.b4s0g0.00000_1411.bin4
24/02/2013 06:33:08 | Einstein@Home | Started download of p2030.20121013.G195.28-00.62.N.b4s0g0.00000_1412.bin4
24/02/2013 06:33:09 | Einstein@Home | Finished download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1016.bin4
24/02/2013 06:33:09 | Einstein@Home | Finished download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1018.bin4
24/02/2013 06:33:09 | Einstein@Home | Finished download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1019.bin4
24/02/2013 06:33:09 | Einstein@Home | Finished download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1021.bin4
24/02/2013 06:33:09 | Einstein@Home | Finished download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1022.bin4
24/02/2013 06:33:09 | Einstein@Home | Finished download of p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1023.bin4
24/02/2013 06:33:09 | Einstein@Home | Temporarily failed download of p2030.20121013.G195.28-00.62.N.b4s0g0.00000_1409.bin4: connect() failed
24/02/2013 06:33:09 | Einstein@Home | Backing off 2 min 7 sec on download of p2030.20121013.G195.28-00.62.N.b4s0g0.00000_1409.bin4
24/02/2013 06:33:09 | Einstein@Home | Started download of p2030.20121013.G195.28-00.62.N.b4s0g0.00000_1413.bin4
24/02/2013 06:33:09 | Einstein@Home | Started download of p2030.20121013.G195.28-00.62.N.b4s0g0.00000_1414.bin4
24/02/2013 06:33:09 | Einstein@Home | Started download of p2030.20121013.G195.28-00.62.N.b4s0g0.00000_1415.bin4
24/02/2013 06:33:09 | Einstein@Home | Started download of p2030.20121013.G195.28-00.62.N.b4s0g0.00000.zap
24/02/2013 06:33:09 | Einstein@Home | Starting task p2030.20121013.G194.89-00.86.S.b5s0g0.00000_1016_0 using einsteinbinary_BRP4 version 133 (BRP4cuda32nv301) in slot 0
24/02/2013 06:33:11 | | Project communication failed: attempting access to reference site
24/02/2013 06:33:12 | | Internet access OK - project servers may be temporarily down.
Do you use a proxy server when connecting? The log says no but I'll ask anyway, because every time I have tried to use one to connect to Seti then communication with Einstein fails.
Further more try to reset the number of simultaneous downloads/uploads to the default 2 at a time, maybe the server don't like it when you have 10 at a time.
Further more try to reset the number of simultaneous downloads/uploads to the default 2 at a time, maybe the server don't like it when you have 10 at a time.
That was my thought too, i also see no mention of Juan of even retrying the timed out download once the other downloads have finished.
Further more try to reset the number of simultaneous downloads/uploads to the default 2 at a time, maybe the server don't like it when you have 10 at a time.
That was my thought too, i also see no mention of Juan of even retrying the timed out download once the other downloads have finished.
Claggy
I have the same setting in all my hosts (10 DL at a time) so why that function well and not on anothers? BTW increse the number is the only way that allow SETI works here, but that is for another time.
If i have 3 WU to DL for example, A, B or C. A DL ok, then B stall, after the timeout C DL ok, leave only B to DL. Or that could be happening when DL only one WU, i can´t find a patern of the problem.
Anyway i increse the resource share to 10 and DL a lot of WU, then i abort the ones that not DL, so at least i have plenity of WU to crunch for a while.
I realy belive is a bug in the scheduler of the 7.0.52 i use beceuse the lot of SETI WU stalled, if no, why all return to work when you switch off the BOINC and restart it? but can´t test because the Boinc DL is out of order to tryto run in with an earlier version
I will try to chance to 2 WU at a time to test, but now is complicated because my caches are allready filled, so will take a time to clear them.
One last thing, i start Collantz on this hosts to make a test, no DL problem with Collantz only with E@H
Anyway i increse the resource share to 10 and DL a lot of WU, then i abort the ones that not DL, so at least i have plenity of WU to crunch for a while.
Rather than aborting the transfers, try retrying them, or if they are stalled (as opposed to timed out) then try Suspending Network Activity for a moment, then reset it back to where it was, do those stalled downloads resume?
Anyway i increse the resource share to 10 and DL a lot of WU, then i abort the ones that not DL, so at least i have plenity of WU to crunch for a while.
Rather than aborting the transfers, try retrying them, or if they are stalled (as opposed to timed out) then try Suspending Network Activity for a moment, then reset it back to where it was, do those stalled downloads resume?
Claggy
I do that before and try again, the problem remains. The DL is timed out but in the log when you ask for new work apears the msg "stalled".
Another "interesting" thing, the problem only shows on CUDA WU, the CPU works DL normaly.
To check if is a hidden bug in the 7.0 code, i need to wait until i could DL the 6.10 again and try to see if the problem dissapears.
For now i will leave the CPU work running and allow some Collantz for keep the GPU working, but i realy prefear to do some more E@H work.
Anyway i increse the resource share to 10 and DL a lot of WU, then i abort the ones that not DL, so at least i have plenity of WU to crunch for a while.
Rather than aborting the transfers, try retrying them, or if they are stalled (as opposed to timed out) then try Suspending Network Activity for a moment, then reset it back to where it was, do those stalled downloads resume?
Claggy
I do that before and try again, the problem remains. The DL is timed out but in the log when you ask for new work apears the msg "stalled".
Another "interesting" thing, the problem only shows on CUDA WU, the CPU works DL normaly.
To check if is a hidden bug in the 7.0 code, i need to wait until i could DL the 6.10 again and try to see if the problem dissapears.
The 'Cuda' Wu's are in fact BRP4 Wu's, (there are CPU apps for it too), their downloads come from only one server:
The CPU Wu's are eithier Gravitational Wave S6 LineVeto search (extended), their downloads are mirrored, they can come from one (or more) of the following servers:
If there is a Bug (and not a ISP/Routing/Server problem), it is unlikely to be in the Boinc 7 code,
but in the libcurl code, Boinc 7.0.52 uses libcurl 7.25.0, while Boinc 6.10.60 (for windows) used libcurl 7.19.7,
libcurl 7.25.0 is almost a year old, with 5 versions after it, 7.29.0 being the latest:
Thanks Claggy for the info, that´s exactly what i think, all the 3 host are in the same ISP and the other 4 uses a diferent ISP, so is possible a problem with the ISP of the first 3 with the single BRP4 WU server and not with the CPU work server.
Now with SETI on line again i could see if the problem is related to the large number of SETI WU ready to UL, let´s see what i get.
That´s is what i get, so the problem is located when the host ask the BRP4 server only (ask for SETI works ok too) - i limit a max update of 64 WU at a time.
24/02/2013 17:16:52 | Einstein@Home | Sending scheduler request: To report completed tasks.
24/02/2013 17:16:52 | Einstein@Home | Reporting 1 completed tasks
24/02/2013 17:16:52 | Einstein@Home | Not requesting tasks: some download is stalled
24/02/2013 17:16:55 | Einstein@Home | Scheduler request completed
24/02/2013 17:37:01 | SETI@home | update requested by user
24/02/2013 17:37:05 | SETI@home | Fetching scheduler list
24/02/2013 17:37:07 | SETI@home | Master file download succeeded
24/02/2013 17:37:12 | SETI@home | Sending scheduler request: Requested by user.
24/02/2013 17:37:12 | SETI@home | Reporting 64 completed tasks
24/02/2013 17:37:12 | SETI@home | Requesting new tasks for CPU and NVIDIA
hi i was wondering why you are running win xp on that machine with only 2.48gig of physical ram ??? Just wondering if that is why you got prob's i would be running win7 and at least 8 gig of ram possibley not enough ram for the amount of units your trying to do at 1 time .Looks to me the poor machine mite be haveing wobbly's (troubble) powerful chip i7 but not enough ram to realy let it do what it whants and xp is so old now. Even if it not the prob bro' get more ram and put at least win7 even if it only the 32 bit version and you have to crack it, which is not hard to do trust me on this.
hi just so ya know i have a mutiboot system with xp and vista and win 7 i run win 7 99% of time and i have had troubble with xp and the m/board drivers yes i was able get the to load and i am useing a hacked version of xp which causes it's own prob's but xp still has caused problems and mite be with you as i asume your m/board is quiet new . I'm thinking a mismach of hard ware and rong op plus to few ram causeing gremlins in you system , by gremlins i mean prob's that don't seem to add up not normal weird like what your haveing are the other hosts the same ??
Resource share of 0 (zero)
)
Resource share of 0 (zero) works fine in all other hosts, but i will try that either.
And thanks for your help.
RE: 24/02/2013 06:32:40 |
)
Do you use a proxy server when connecting? The log says no but I'll ask anyway, because every time I have tried to use one to connect to Seti then communication with Einstein fails.
Further more try to reset the number of simultaneous downloads/uploads to the default 2 at a time, maybe the server don't like it when you have 10 at a time.
RE: Further more try to
)
That was my thought too, i also see no mention of Juan of even retrying the timed out download once the other downloads have finished.
Claggy
RE: RE: Further more try
)
I have the same setting in all my hosts (10 DL at a time) so why that function well and not on anothers? BTW increse the number is the only way that allow SETI works here, but that is for another time.
If i have 3 WU to DL for example, A, B or C. A DL ok, then B stall, after the timeout C DL ok, leave only B to DL. Or that could be happening when DL only one WU, i can´t find a patern of the problem.
Anyway i increse the resource share to 10 and DL a lot of WU, then i abort the ones that not DL, so at least i have plenity of WU to crunch for a while.
I realy belive is a bug in the scheduler of the 7.0.52 i use beceuse the lot of SETI WU stalled, if no, why all return to work when you switch off the BOINC and restart it? but can´t test because the Boinc DL is out of order to tryto run in with an earlier version
I will try to chance to 2 WU at a time to test, but now is complicated because my caches are allready filled, so will take a time to clear them.
One last thing, i start Collantz on this hosts to make a test, no DL problem with Collantz only with E@H
Changed to 2 Dl at a time, the problem remains
RE: Anyway i increse the
)
Rather than aborting the transfers, try retrying them, or if they are stalled (as opposed to timed out) then try Suspending Network Activity for a moment, then reset it back to where it was, do those stalled downloads resume?
Claggy
RE: RE: Anyway i increse
)
I do that before and try again, the problem remains. The DL is timed out but in the log when you ask for new work apears the msg "stalled".
Another "interesting" thing, the problem only shows on CUDA WU, the CPU works DL normaly.
To check if is a hidden bug in the 7.0 code, i need to wait until i could DL the 6.10 again and try to see if the problem dissapears.
For now i will leave the CPU work running and allow some Collantz for keep the GPU working, but i realy prefear to do some more E@H work.
Thanks all for the help.
RE: RE: RE: Anyway i
)
The 'Cuda' Wu's are in fact BRP4 Wu's, (there are CPU apps for it too), their downloads come from only one server:
http://einstein6.aei.uni-hannover.de
The CPU Wu's are eithier Gravitational Wave S6 LineVeto search (extended), their downloads are mirrored, they can come from one (or more) of the following servers:
http://einstein2.aei.uni-hannover.de
http://einstein-dl4.phys.uwm.edu
http://einstein-dl2.phys.uwm.edu
http://einstein.ligo.caltech.edu
(these 4 servers are also where all the apps are mirrored too)
Or Gamma-ray pulsar search #2, their downloads come from only the following server:
http://einstein6.aei.uni-hannover.de
If there is a Bug (and not a ISP/Routing/Server problem), it is unlikely to be in the Boinc 7 code,
but in the libcurl code, Boinc 7.0.52 uses libcurl 7.25.0, while Boinc 6.10.60 (for windows) used libcurl 7.19.7,
libcurl 7.25.0 is almost a year old, with 5 versions after it, 7.29.0 being the latest:
http://curl.haxx.se/changes.html#7_29_0
Claggy
RE: The 'Cuda' Wu's are in
)
Thanks Claggy for the info, that´s exactly what i think, all the 3 host are in the same ISP and the other 4 uses a diferent ISP, so is possible a problem with the ISP of the first 3 with the single BRP4 WU server and not with the CPU work server.
Now with SETI on line again i could see if the problem is related to the large number of SETI WU ready to UL, let´s see what i get.
That´s is what i get, so the problem is located when the host ask the BRP4 server only (ask for SETI works ok too) - i limit a max update of 64 WU at a time.
24/02/2013 17:16:52 | Einstein@Home | Sending scheduler request: To report completed tasks.
24/02/2013 17:16:52 | Einstein@Home | Reporting 1 completed tasks
24/02/2013 17:16:52 | Einstein@Home | Not requesting tasks: some download is stalled
24/02/2013 17:16:55 | Einstein@Home | Scheduler request completed
24/02/2013 17:37:01 | SETI@home | update requested by user
24/02/2013 17:37:05 | SETI@home | Fetching scheduler list
24/02/2013 17:37:07 | SETI@home | Master file download succeeded
24/02/2013 17:37:12 | SETI@home | Sending scheduler request: Requested by user.
24/02/2013 17:37:12 | SETI@home | Reporting 64 completed tasks
24/02/2013 17:37:12 | SETI@home | Requesting new tasks for CPU and NVIDIA
hi i was wondering why you
)
hi i was wondering why you are running win xp on that machine with only 2.48gig of physical ram ??? Just wondering if that is why you got prob's i would be running win7 and at least 8 gig of ram possibley not enough ram for the amount of units your trying to do at 1 time .Looks to me the poor machine mite be haveing wobbly's (troubble) powerful chip i7 but not enough ram to realy let it do what it whants and xp is so old now. Even if it not the prob bro' get more ram and put at least win7 even if it only the 32 bit version and you have to crack it, which is not hard to do trust me on this.
hi just so ya know i have a
)
hi just so ya know i have a mutiboot system with xp and vista and win 7 i run win 7 99% of time and i have had troubble with xp and the m/board drivers yes i was able get the to load and i am useing a hacked version of xp which causes it's own prob's but xp still has caused problems and mite be with you as i asume your m/board is quiet new . I'm thinking a mismach of hard ware and rong op plus to few ram causeing gremlins in you system , by gremlins i mean prob's that don't seem to add up not normal weird like what your haveing are the other hosts the same ??