Well, well. well.
The kitties appear to have been busy whilst I was away at work today.
Got home and saw some progress, so I rebooted the whole farm. Uploads took off and completed. Way cool. Reinstated the app info xml files. Restarted Boinc. Still working. Way cooler.
Downloads were a bit flaky, so I reset the router MTU from 1500 down to 1400. Shouldn't make a difference on my DSL connection, 1500 is reccomended by most TCP advisory programs, but what the heck.
Lordy, lordy, finally was able to download even the Beta results on some of my rigs! Ultimate coolness.
My quaddy (remember my quaddy?) has almost finished playing with 30 to 50 hour Astropulse WUs and finally thought it was time to request some Seti Main work........and got some! Quaddy should be back crunching Seti Main soon.
And the kitties smile!
Wonder where the next wicked witch in this little fairy tale will come from? According to Matt's last post, splitter capacity is about maxed out, and we are almost out of classic WUs to process pending Multibeam data. Hope that transition goes more smoothly than a few of the other recent ones have. Oh well, no pain, no gain.
High fives all around for the Seti staff!!

And the kitties say...'Stay tuned for the next episode of.....As the Seti Turns'.

---

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

And the Cricket Graph seems to be showing a slow deline in traffic.
Could this mean we are really making a tidbit of progress in filling caches and having fewer hosts requesting work? I think maybe!!

---

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

And the Cricket Graph seems to be showing a slow deline in traffic.
Could this mean we are really making a tidbit of progress in filling caches and having fewer hosts requesting work? I think maybe!!

And the work ready to send is going up,

Thanks to Scarecrow for graph.

All but one of my six machines are now working again. My newest and most powerful just does not seem to be able to communicate in any way with SETI. I am running the chicken optimized, but I am running it on all but one other machine. I have perhaps two dozen small work units that have been waiting to report for more than a week. IT is doing no work because it cannot get any. I check the logs and see repeated failures to communicate. Funny, when SETI first came up for a few hours this machine connected and received all those small work units crunched them and has not been able to communicate since then.

All but one of my six machines are now working again. My newest and most powerful just does not seem to be able to communicate in any way with SETI. I am running the chicken optimized, but I am running it on all but one other machine. I have perhaps two dozen small work units that have been waiting to report for more than a week. IT is doing no work because it cannot get any. I check the logs and see repeated failures to communicate. Funny, when SETI first came up for a few hours this machine connected and received all those small work units crunched them and has not been able to communicate since then.

Have you rebooted the machine? I found that this kick started all of my rigs last night which had uploads stalled.

---

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

Dennis, check to make sure:

The project isn't suspended

The comms are set to "network always available" and not suspended,

The project is set to "allow new work"

any other setting which might be stopping it.

so I reset the router MTU from 1500 down to 1400. Shouldn't make a difference on my DSL connection, 1500 is reccomended by most TCP advisory programs, but what the heck.

Well, my take is that the MTU should be 1500.
It seems that the machine on 208.68.240.16 has an MTU of 1476

i:\\program files\\boinc>ping 208.68.240.16 -f -l 1450
Pinging 208.68.240.16 with 1450 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

i:\\program files\\boinc>ping 208.68.240.16 -f -l 1448
Pinging 208.68.240.16 with 1448 bytes of data:
Reply from 208.68.240.16: bytes=1448 time=192ms TTL=53
Reply from 208.68.240.16: bytes=1448 time=192ms TTL=53

MTU = size + 28, so MTU is 1448+28 = 1476

This seems suspicious. Why is bruno using 1476 when the rest of the world uses 1500? This will almost double the amount of packets to deal with and could explain the serious difficulty I still have in transferring anything from a couple of crunching linux web servers. They are using state based firewalls (default fedora core 6), a side effect is the filtering of incoming state related RST packets, which I thought could be a reason for the extremely poor performance. So, I explicitly allowed 208.68.240.16 through. Even after this, it's still only successful in communicating 1% of the time, and no, I'm not going to change the MTU of 1500 on a production web server!

Andy.

Looks like a good observation, Andy.

Please re-post it in the Staff Blog area, it'll have a better chance of being read by the right people.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

OK... doing it now... :-)

This seems suspicious. Why is bruno using 1476 when the rest of the world uses 1500?

Traffic to our router is tunneled to a router in Palo Alto. The overhead of the tunnel is 24 bytes more than the normal TCP/IP over ethernet overhead. Fragmentation shouldn't be too much of an issue because nearly every modern TCP/IP stack uses MTU discovery to size outgoing packets properly.

What might have been an issue is that the interface on bruno was set to have an MTU of 1500. I've adjusted that to 1476, which did cause us to jump up to 50 Mbps for a few minutes, but we're back down in the 20s again.

Eric

---

@SETIEric@qoto.org (Mastodon)

This seems suspicious. Why is bruno using 1476 when the rest of the world uses 1500?

Traffic to our router is tunneled to a router in Palo Alto. The overhead of the tunnel is 24 bytes more than the normal TCP/IP over ethernet overhead. Fragmentation shouldn't be too much of an issue because nearly every modern TCP/IP stack uses MTU discovery to size outgoing packets properly.

What might have been an issue is that the interface on bruno was set to have an MTU of 1500. I've adjusted that to 1476, which did cause us to jump up to 50 Mbps for a few minutes, but we're back down in the 20s again.

Eric

Eric, thanks for the clear explanation - I think you solved it! All my machines are now connecting and reporting without timeouts. :-)

Either the tunnel had to fragment, or the tunnel traffic had to...
Fragmentation does make a significant transfer overhead - I wonder, is the tunnel absolutely necessary, given the load that it's under? There might be another way.

If not, then perhaps a net-facing MTU of 1500 could be maintained if the machines responsible for the tunnel used an MTU of 1524. If maintaining the tunnel is their primary purpose, then it might be worth taking a 'fragmentation hit' internally when talking to peers on other business with MTU 1500...
Just some thoughts...

Andy.

. . . I've adjusted that to 1476, which did cause us to jump up to 50 Mbps for a few minutes, but we're back down in the 20s again.

Eric

Eric -
I can't explain the graphs flattening out again, but three of my machines have had major problems until right after you made the above change. They are now connecting without a single retry. You may indeed have fixed it.
- Regards

Traffic to our router is tunneled to a router in Palo Alto. The overhead of the tunnel is 24 bytes more than the normal TCP/IP over ethernet overhead. Fragmentation shouldn't be too much of an issue because nearly every modern TCP/IP stack uses MTU discovery to size outgoing packets properly.

What might have been an issue is that the interface on bruno was set to have an MTU of 1500. I've adjusted that to 1476, which did cause us to jump up to 50 Mbps for a few minutes, but we're back down in the 20s again.

Eric

I concur with the previous posters, uploads and reporting are downright zippy now compared to before, when they would go past 100% and stall (sometimes forever).

Should decrease average bandwidth usage for the same amount of net transfer, too, so it's a win/win.

Thanks for looking into it,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

I've adjusted that to 1476, which did cause us to jump up to 50 Mbps for a few minutes, but we're back down in the 20s again.

Eric

Eric..........

I have seen a dramatic improvement since right after you made this change.
Thanks to you and all the crew for the work you have done recently.

---

Boinc....Boinc....Boinc....Boinc....

Yay, all my machines are working again Smoothly! Thanks Eric!

---

Official Abuser of Boinc Buttons...
And no good credit hound!

OK....so should I change my router back to the MTU setting of 1500 which I would consider to be the correct setting?? Or to 1476?

---

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

OK....so should I change my router back to the MTU setting of 1500 which I would consider to be the correct setting?? Or to 1476?

Should be 1500, but that also depends on your provider... as Eric says, the servers should negotiate MTU, so it should drop to 1476 by itself to avoid fragmentation. I guess if all the machine does is crunch, then set the MTU for the *machine* to 1476 to save a couple of packets of negotiation.

If you adjust it on the router and it doesn't know about MTU negotiation, then all your packets everywhere may be fragmented - to and from the router, on your side and net side, as everywhere else you visit wants to use 1500 MTU...

There's a lot of shoulds and maybes here! I don't know the configuration of every network on the net, but 1500 is the standard size.

A quick google on mtu optimisation might help!

Andy.

Well, after consulting with the kitties, I set the router back to a MTU of 1500. It's what I had it set at from day 1, and with my DSL connection, what the TCP optimizers say to use. Mebbe with the changes made to Seti's settings it will work properly again.

---

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

Follow up......
What's up with the Cricket Graph
Lots of funny looking spikes the last few hours.
Looks like something is struggling along here.

---

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

Well, after consulting with the kitties, I set the router back to a MTU of 1500. It's what I had it set at from day 1, and with my DSL connection, what the TCP optimizers say to use. Mebbe with the changes made to Seti's settings it will work properly again.

Kitties saved the day... you prompted me to check it out and pose a question that Eric saw, checked out and fixed the problem! sic vita est!

File transfers with SETI now running like a dream! :-)))))