Tanks to the one who discovered/share that with us.

cdemers figured it out.

Tanks to the one who discovered/share that with us.

cdemers figured it out.

Not so shure about that, but he have his big contribution in testing and sharing the results with us.

---

So, what are the theories as to why the cricket graph incoming (blue line) has started to creep upward? Something to do with the current lack of AP workunits to send?

---

So, what are the theories as to why the cricket graph incoming (blue line) has started to creep upward? Something to do with the current lack of AP workunits to send?

With AP work not clogging up the pipes, more MB work is probably going out and being returned.
There have also been a significant number of 'shorty' MB WUs, which get crunched and returned much faster.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Mark, there is a shortie shower going on at the moment...

---

Mark, there is a shortie shower going on at the moment...

And, with both shorties and limits, big hosts contact the servers much more often.

Their sched_request files count towards the bits on the blue line. At least, with limits in place, the request files aren't as big as the ones we've discussed in the past.

So, what are the theories as to why the cricket graph incoming (blue line) has started to creep upward? Something to do with the current lack of AP workunits to send?

That always happens as the downloads stop to saturate the pipeline allowing the uploads to have more bandwidth (it just hasn't been seen in a long time).

Cheers.

---

Mark, there is a shortie shower going on at the moment...

But there are no more shorties going through than there wre a couple of days ago and there was no effect on inbound traffic then, although i notice this time the turnaround time has dropped drastically.

---

Grant
Darwin NT

Mark, there is a shortie shower going on at the moment...

But there are no more shorties going through than there wre a couple of days ago and there was no effect on inbound traffic then, although i notice this time the turnaround time has dropped drastically.

And how!

My primary rig is turning over 100 GPU shorties every ~30 minutes. @ 200/hour for close to 12 hours, plus the CPU work, that's 2500 WU's, and the rig is only #14 rankings-wise. Good news is, efficient downloading has kept up very nicely.

---

Everything was going smooth for downloads until yesterday.Now the only way I can get these shorties to come through is to suspend net activity and resume about three times / task. This is downright frustrating. Anyone else seeing a huge problem with downloading today

Michael Miles

Everything was going smooth for downloads until yesterday.Now the only way I can get these shorties to come through is to suspend net activity and resume about three times / task. This is downright frustrating. Anyone else seeing a huge problem with downloading today

Michael Miles

No problems here on either of my machines, did you by chance install the TCP fix?

---

I don't buy computers, I build them!!

Everything was going smooth for downloads until yesterday.Now the only way I can get these shorties to come through is to suspend net activity and resume about three times / task. This is downright frustrating. Anyone else seeing a huge problem with downloading today

Michael Miles

Nope all machines downloading same as last 4 days. (with TCP fix)

---

With all the short MB WUs being delivered, I did have one host that struggled to download an AP WU (all Windows hosts have had the RFC1323 option applied). Main issue for me now is that the short MB WUs are being processed in only a little more time than it takes to download them (on the fastest hosts) - download rates have dropped to about half of what they were when AP WUs and longer MB WUs were still being sent.

...but that's probably my geographical location that's contributing, as well as the increased download demand.

---

Soli Deo Gloria

The TCP fix is still working in my hosts but it's not as effective as it was the first day Ive applied the changes...
Still effective enough to not need the retry script, even when Im getting some delayed transfers and some project wide backoffs sometimes...
May be is a combined effect between the shorties the lack of APs and the fact that with the optimizations a lot of computers are actively transfering files instead of beeing delayed due to the backoffs (and my highly unreliable internet conections, of course)

---

Well I have just watched several downloads on my 3 active machines.

Absolutely no difference, no back offs, speed between 2-10kps about 50sec per wu, so still working here.

---

The TCP fix is still working in my hosts but it's not as effective as it was the first day Ive applied the changes...
Still effective enough to not need the retry script, even when Im getting some delayed transfers and some project wide backoffs sometimes...
May be is a combined effect between the shorties the lack of APs and the fact that with the optimizations a lot of computers are actively transfering files instead of beeing delayed due to the backoffs (and my highly unreliable internet conections, of course)

I suppose in the old days, before TCP, we used to download a little bit, and then leave a gap - while BOINC decided whether to go for a full-scale timeout and backoff to the next one. And in our gap, somebody else could get a little downloading done.

Apply TCP, and - no more gaps!

I am sure I missed this tcp fix. Is it a tcp optimizer?
Can you point this out

Michael

I am sure I missed this tcp fix. Is it a tcp optimizer?
Can you point this out

Michael

It is a long and winding discussion in this thread, but all you have to do is set or add the following DWORD to the registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]
"Tcp1323Opts"=dword:00000003

---

I am sure I missed this tcp fix. Is it a tcp optimizer?
Can you point this out

Michael

I don't know you could've missed this thread and all you require is in the 1st post, Windows TCP Settings - Follow up - Help with server communication.

Cheers.

---

It is a long and winding discussion in this thread, but all you have to do is set or add the following DWORD to the registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]
"Tcp1323Opts"=dword:00000003


Thank you
smoothed right out

Michael Miles