work stoppage during block submition

[Keroberts1]

I thought that the client would continue working while submittign a block but mines not been able to contact theserve for the last few blocks and it is apparently pausing work because i see the progress meter not moving and it doesn't jump after the submitting is done. Perhaps its just a reporting flaw but I would like ot know whats going on.

[vjs]

This was covered before, as far as I know the client doesn't process during transmission, if the client transmission ??hangs?? I suppose the client could stop processing as well. If your having problems connecting etc turn off intermediate block submission.

Hopefully someone who knows more about this will chime in, I'm 90% certain it's not processing while transmitting.

[Joh14vers6]

Try SBQueue and see if you can connect to that. I use that for a long time to be not affected by connection problems with the projectserver.

[Nuri]

In fact, we're losing significant CPU time due to this friction.

I dunno how many users are using the standard server + transmit intermediate blocks configuration, but I guess more than half of the work is processed that way.

IIRC, a block is processed in about 5 to 7 minutes and lost CPU time during connection is roughly 10 seconds, which suggests ~3% loss for those users.

This might not look that important, but I guess it accumulates to some significant figures over time.

May be, we should consider larger block sizes (or stuff like transmit every 10, 50, etc. blocks type options, whichever easier) for the next version of the client. Just a practical idea for a simple problem.

[Keroberts1]

ten seconds sounds incredibly large. I only seemed to loose at most a second when connecting but that could have something to do with my connection. I have a constant cable connection. If someone is on a dial up modem and it has to dial up and connct before submitting and the client is waiting all the while then this could take a signifigant amount of time.

[Nuri]

I was referring to my memory (I'm not close to any of my PCs that run PRP right now ) about the total time it takes from the point a block is finished until the next block processing starts. May be it's only me, or maybe I recall it incorrectly... I'll check it when I get home and correct the 10 seconds figure if the real figure is significantly different.

[Vato]

The clean way to do this is to have a network thread separate from the PRP thread (which can be generalised to multiple PRP threads for multiprocessor systems). However this usually isn't easy to retrofit to a program that wasn't written with it mind. Maybe for v3.0?

I suspect that changing the reporting interval to N blocks would be a good
idea though, both in terms of reducing lost processing time, but also in terms of reducing load on the server - we'd a lot more users before that was a major issue though. My preference would be for a user configurable time-limit, rather than by number of blocks.

[maddog1]

Originally posted by Keroberts1
ten seconds sounds incredibly large. I only seemed to loose at most a second when connecting but that could have something to do with my connection. I have a constant cable connection. If someone is on a dial up modem and it has to dial up and connct before submitting and the client is waiting all the while then this could take a signifigant amount of time.

No, for a 56K it's quite "normal" to have a delay of 5-10 seconds while communicating with the server. I can verify it as a @!@$@!modem user. It doesn't have much to do with the delay in dialing/connecting. (I don't dial in for every block submission!) Even when submitting while connected, there's such a delay before all the log in/ get server reply/ submit/ get another server reply/continue test procedure is complete -probably due to high ping times associated with modem use- and it gets quite worse if the client tries to submit while you are downloading something, as they both compete for the *huge* 5 KBps bandwidth of the modem! :|
During all this hassle you can see the cEMs number reducing on the client window, so I agree that it isn't processing any more data before submitting the completed block.
An option of setting number of blocks submitted per login in the client sounds good. After all, now we can only choose between submitting each and every block by itself and submitting the whole test. I'd like to have some intermediate choices too, say 5-10-50 blocks together.
Just my 2 cents

[Nuri]

Here're some lost time data from my machines...

Two machines share an ADSL connection of 512 kb.

Athlon:
8 to 10 seconds.

PIV:
6 to 8 seconds when PRP is the only DC client running.
12 to 16 seconds when PRP is sharing 50% of cycles with another DC client.
15 to 25 (sometimes more) seconds when PRP is sharing cycles with another DC client + e-mule.

Those also affect the time to finish a block, so it would be wiser to speak in terms of time lost in percentages, which is around 2.4% of total processing time allocated to PRP.

[allio]

<- On dialup.

When the connection isn't being used, it's fine, but when there's a download going (or ESPECIALLY a torrent), it can take the client 10-20 seconds to either login and submit the block or conversely to time out and resume crunching. I use SBQueue to separate the network threads from the crunching, because if it takes SBQueue 20 seconds to flush, that's no problem - the client pauses for a tenth of a second if at all between blocks.

I agree that quite a lot of processing potential is probably being wasted, especially by users with fast P4s on dialup.

[kugano]

Known issue and toward the top of the list of things to fix in v3.