The tcp fix did it purrrfectly.

Thanks you for eliminating an insanity plea

The tcp fix did it purrrfectly.

Thanks you for eliminating an insanity plea

Yes, that tiny fix turned out to be a very powerful medicine!

---

So that was cool, I guess, during today's maintenance. Cricket actually dipped when things went down. I guess the majority of the bandwidth usage are people here on the forums and our downloads are running so smoothly that once the scheduler stops handing WUs out, the download queues on the client-side empty out quickly.

I haven't seen the green dip during a maintenance in several weeks. Must be a sign of improvement.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

I think it's more to do with the fact that there aren't any AP WUs being sent at the moment (aside from re-sends for inconclusive results, etc), plus the flood of short MB WUs combined with the WU limit.

---

Soli Deo Gloria

Oh yeah, I forgot about that. I guess I did notice there haven't been much APs going out in the past two days. That's probably it then--well mostly it. I'm sure the rest of us doing the TCP fix does contribute at least a little bit to it though.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

It's been a couple of days longer than the last 2 days since new AP's have been split. ;)

Cheers.

---

In regards to the TCP fax I personally haven't had anything but slow speeds some MB downloads sitting at 1.5kb/s s however I have had some download reasonably quickly 10+ kb/s.

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

I have also tried this registry fix but removed as I feel it may be download worst not better.

Just letting everybody know my two cents.

---

I'm pretty sure a restart is necessary for the RFC1323 switch to take effect. But it's certainly your choice to leave it in there or not.

---

Soli Deo Gloria

In regards to the TCP fax I personally haven't had anything but slow speeds some MB downloads sitting at 1.5kb/s s however I have had some download reasonably quickly 10+ kb/s.

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

I have also tried this registry fix but removed as I feel it may be download worst not better.

Just letting everybody know my two cents.

It's not supposed to fix slow downloads, just stalled downloads.

So that was cool, I guess, during today's maintenance. Cricket actually dipped when things went down. I guess the majority of the bandwidth usage are people here on the forums and our downloads are running so smoothly that once the scheduler stops handing WUs out, the download queues on the client-side empty out quickly.

I haven't seen the green dip during a maintenance in several weeks. Must be a sign of improvement.

IIRC, only Uploads/Downloads/Scheduler requests go through the 100MB HE link that the Cricket graph shows. All the webpage traffic, including the Forums, goes through a different cable on the campus net.

---

Donald
Infernal Optimist / Submariner, retired

So that was cool, I guess, during today's maintenance. Cricket actually dipped when things went down. I guess the majority of the bandwidth usage are people here on the forums and our downloads are running so smoothly that once the scheduler stops handing WUs out, the download queues on the client-side empty out quickly.

I haven't seen the green dip during a maintenance in several weeks. Must be a sign of improvement.

IIRC, only Uploads/Downloads/Scheduler requests go through the 100MB HE link that the Cricket graph shows. All the webpage traffic, including the Forums, goes through a different cable on the campus net.

Yes I know, but I was implying that those of us who are active on the forums have applied the fix and therefore made a substantial difference in the backlog of pending downloads.

It's been a couple of days longer than the last 2 days since new AP's have been split. ;)

I don't really pay attention all that much. My machine over-estimated its cache two weeks ago and only started asking for work 2-3 days ago, and I've been getting a lot of "no tasks available for..." messages.

Still have plenty of cache though. ~8 more days if I did my math right.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

I don't really pay attention all that much. My machine over-estimated its cache two weeks ago and only started asking for work 2-3 days ago, and I've been getting a lot of "no tasks available for..." messages.

Do those responses include the "over the limits" message? I'm getting a lot of those when I'm not over the limits - my last 6 gpu work requests got that response when I was clearly under the gpu limit. Looking back overnight, I see a lot of limit messages, then 16 tasks. More limit messages, then 46 tasks, etc.

I saw incorrect limits messages last week, but they were usually followed by a successful work request so I didn't get more than 6 below limit. Anyone else seeing this?

---

Another Fred
Support SETI@home when you search the Web with GoodSearch or shop online with GoodShop.

Do those responses include the "over the limits" message? I'm getting a lot of those when I'm not over the limits - my last 6 gpu work requests got that response when I was clearly under the gpu limit. Looking back overnight, I see a lot of limit messages, then 16 tasks. More limit messages, then 46 tasks, etc.

I saw incorrect limits messages last week, but they were usually followed by a successful work request so I didn't get more than 6 below limit. Anyone else seeing this?

Yes being told you are on the limit when you report 8 tasks or so is not good but when you report another 6 and still being told that you are on the limit is very wrong especially when you know that you are well short of those limits.

Cheers.

---

I just got 2 "Couldn't connect to servr" errors in a row when trying to contact the Scheduler.
Hoping it's just a glitch....


Ah, 3rd attempt got through.

---

Grant
Darwin NT

That´s something new... There is a new limit in place? All happening after the yesterday outage.

Some of my hosts starts to show this msg (look the last line):

13/03/2013 06:16:20 | SETI@home | Requesting new tasks for CPU and NVIDIA
13/03/2013 06:16:24 | SETI@home | Scheduler request completed: got 0 new tasks
13/03/2013 06:16:24 | SETI@home | No tasks sent
13/03/2013 06:16:24 | SETI@home | No tasks are available for SETI@home v7
13/03/2013 06:16:24 | SETI@home | Tasks for AMD/ATI GPU are available, but your preferences are set to not accept them
13/03/2013 06:16:24 | SETI@home | This computer has reached a limit on tasks in progress

But it not have a single GPU WU allready DL! So how it reaches the limit?
I´m running E@H in this hosts with 0 (zero) resource share, so no E@H GPU WU are in the cache. The CPU WU cache are full, just can´t get any GPU WU due this problem.

Application details for host 6269362 (last error WU - Feb 19)

SETI@home Enhanced (anonymous platform, nvidia GPU)
Number of tasks completed 164731
Max tasks per day 7162
Number of tasks today 17
Consecutive valid tasks 1050
Average processing rate 405.49155859957
Média do tempo de resposta 0.08 days

---

Cricket graph seems to be free falling.

Finally time to panic again.

---

Even though the server status page has been updating the Splitter Status part is still the same as it was since before the outage so yes, everyone can PANIC.

[edit]Everyone get your back up projects ready. [/edit]

Cheers.

---

I`m still downloading.

---

With each crime and every kindness we birth our future.

Cricket graph seems to be free falling.

Finally time to panic again.

Shortie storm appears to be over, and there are a few VLARs coming out every now & then.
Traffic will probably be up & down a bit as people work through the work they have till it's mostly longer running WUs again.

---

Grant
Darwin NT

That´s something new... There is a new limit in place? All happening after the yesterday outage.

Some of my hosts starts to show this msg (look the last line):

13/03/2013 06:16:20 | SETI@home | Requesting new tasks for CPU and NVIDIA
13/03/2013 06:16:24 | SETI@home | Scheduler request completed: got 0 new tasks
13/03/2013 06:16:24 | SETI@home | No tasks sent
13/03/2013 06:16:24 | SETI@home | No tasks are available for SETI@home v7
13/03/2013 06:16:24 | SETI@home | Tasks for AMD/ATI GPU are available, but your preferences are set to not accept them
13/03/2013 06:16:24 | SETI@home | This computer has reached a limit on tasks in progress

But it not have a single GPU WU allready DL! So how it reaches the limit?
I´m running E@H in this hosts with 0 (zero) resource share, so no E@H GPU WU are in the cache. The CPU WU cache are full, just can´t get any GPU WU due this problem.

Application details for host 6269362 (last error WU - Feb 19)

SETI@home Enhanced (anonymous platform, nvidia GPU)
Number of tasks completed 164731
Max tasks per day 7162
Number of tasks today 17
Consecutive valid tasks 1050
Average processing rate 405.49155859957
Média do tempo de resposta 0.08 days

I've been having similar problems getting GPU work since the maintenance window was completed.

---