Linux client halted

I had a little problem with the linux client :

When I woke up this morning, I was surprised to see that my cpu was absolutely idle... yet the pending test (k=5359, n=2435886) was all but finished...

Last line of log was :
[Thu Jan 23 00:23:36 2003] iteration: 210000/2435899 (8.62%) k = 5359 n = 2435886

and it just sit there

I had to ctrl-c it and start it again... (of course : there had been no freeze of anything of that sort...)

It is the first time that it occurs though... hope it won't be too often...

I have 8 windows clients and 1 linux, but so far have only checked 4 of the windows clients. Looking at my graph I believe at least one other to be hung.

2 of the 4 halted yesterday at 16:06 and 16:24 Mountain Time yesterday. These times are appoximate times based on the log and the fact I beleive they hung submitting a finished block. Interestingly, I had a client (on the same network as the 16:06) successfully post at 16:13.

It seems that the server is the problem. As the two clients were across town from each other their Internet connection is hard to blame (although they both have the same DNS server). Also looking at a few graphs at SoB several Teams have had sharp drop-offs at that same time.

One client showed 100% block completion and the other 99.9% block completion. Neither had an entry in the log for that block. When I exited and restarted, one restarted the block at 93% and the other at 56%. I find it strange that the cache was not updated as I exited.

Same with one of my machines. Hung (the client, not the whole machine) yesterday approx. 19:10 GMT+1 while trying to submit a block.

Quote:

---

Originally posted by Mierin
client showed 100% block completion and the other 99.9% block completion. Neither had an entry in the log for that block. When I exited and restarted, one restarted the block at 93% and the other at 56%. I find it strange that the cache was not updated as I exited.

---

Did you exit, or stop and exit? I think that stopping and exiting will work without work loss.

AFAIR I stopped first. But I'm not completely sure...

My box stopped also. I am restarting it now. It's been down for the best part of a day sitting on 100% done.

My concern wasn't for the work loss in restarting that block. My concern was for the hours upon hours that the program was hung. Not to mention that I would rather not have to nurse the program. I was hoping it would be a start and forget type deal.

Since I posted last I have checked all the other windows machines and they were fine or down for other reasons. But the linux machine was similarly hung.

BTW, it seems that there is something wrong with the statistics graphs. While my clients were hung the graphs showed a drop in productivity, but after restarting the evidence of this had dissappeared. Now I see a solid line as if nothing had happened. I would expect this when blocks are queued, but not when the machine is actually hung.

Yeah, some of my hung too.. I think I know why also.

Past few days the ISP the connection the server is on has had a few bandwidth issues and I think the client connects when they are trying to fix it, causing it to indefinitly time out cause i know there has been this issue in the past..

-Alien88

I know that people like really up to date stats, but I think it'd still be ok if the block length was doubled (or even tripled or quadrupled), I'm submitting a block every hour from my Duron and every 25 mins from my XP.

After all, there's little point in being able to see up to date stats showing that your client hung a couple of days ago and you didn't notice!

Quote:

---

Originally posted by Mierin

BTW, it seems that there is something wrong with the statistics graphs. While my clients were hung the graphs showed a drop in productivity, but after restarting the evidence of this had dissappeared. Now I see a solid line as if nothing had happened. I would expect this when blocks are queued, but not when the machine is actually hung.

---

The reason the stats do this has been discussed numerous times here in this forum. Basically they work out how long it takes to finish a block, and if it takes 2 hours instead of one, because your pc was down for the first hour, then it displays a consant line at half your usual power!

That would be expected since the server would have no way of knowing if I was down or just working slowly. What I meant is that it showed a constant line at full power, not half power

I have seen serveral cases where the log says "temporarily unable to connect -- block added to submit queue"

And even one "couldn't report to server [can't log in], retry in 1200 secs [error: 0]"

So, it seems that SB works great when it can't connect. I am wondering what happens if the client connects, but the server keeps the socket open and never responds. If it happens again, I will check netstat.

Does the client use select() or does it just call recv() without checing first or setting a timeout. If using timeout, be aware that setsockopt(SO_RCVTIMEO) doesn't work unless using WinSock 2.0.