Anyone having trouble getting WU's. can't get any at all at present keeps coming up with the following:-

25/05/2007 14:50:29|SETI@home|Sending scheduler request: To fetch work
25/05/2007 14:50:29|SETI@home|Requesting 1728 seconds of new work
25/05/2007 14:50:34|SETI@home|Scheduler RPC succeeded [server version 509]
25/05/2007 14:50:34|SETI@home|Deferring communication for 11 sec
25/05/2007 14:50:34|SETI@home|Reason: requested by project
25/05/2007 14:50:34|SETI@home|Deferring communication for 1 min 0 sec
25/05/2007 14:50:34|SETI@home|Reason: no work from project
25/05/2007 14:51:34|SETI@home|Sending scheduler request: To fetch work
25/05/2007 14:51:34|SETI@home|Requesting 1728 seconds of new work
25/05/2007 14:51:39|SETI@home|Scheduler RPC succeeded [server version 509]
25/05/2007 14:51:39|SETI@home|Deferring communication for 11 sec
25/05/2007 14:51:39|SETI@home|Reason: requested by project
25/05/2007 14:51:39|SETI@home|Deferring communication for 1 min 0 sec
25/05/2007 14:51:39|SETI@home|Reason: no work from project
25/05/2007 14:52:39|SETI@home|Sending scheduler request: To fetch work
25/05/2007 14:52:39|SETI@home|Requesting 1728 seconds of new work
25/05/2007 14:52:44|SETI@home|Scheduler RPC succeeded [server version 509]
25/05/2007 14:52:44|SETI@home|Deferring communication for 11 sec
25/05/2007 14:52:44|SETI@home|Reason: requested by project
25/05/2007 14:52:44|SETI@home|Deferring communication for 1 min 59 sec
25/05/2007 14:52:44|SETI@home|Reason: no work from project
25/05/2007 14:54:44|SETI@home|Sending scheduler request: To fetch work
25/05/2007 14:54:44|SETI@home|Requesting 1728 seconds of new work


I have tried re-starting boin and also detaching and re-attching seti, still don't work

I posted the question back in NC, but I'll post it here also. What do I do with my router's MTU at this point?? Go back to 1500? Go to 1476? What's gonna optimize (some of us are just fixated on that 'O' word, aren't we) communications with Seti?

If you have your machine set to 1500, and your DSL line is at 1476, every full-sized packet sent by your machine has to be sent as two packets.

So, lowering MTU to match the MTU on your DSL line should increase performance a tiny bit.

In cases where the "DF" flag is set, and some intermediate router is filtering ICMP, MTU discovery will not work -- and your 1500 byte packets will never ever go through.

---

Anyone having trouble getting WU's. can't get any at all at present keeps coming up with the following:-

25/05/2007 14:50:29|SETI@home|Sending scheduler request: To fetch work
25/05/2007 14:50:29|SETI@home|Requesting 1728 seconds of new work
25/05/2007 14:50:34|SETI@home|Scheduler RPC succeeded [server version 509]
25/05/2007 14:50:34|SETI@home|Deferring communication for 11 sec
25/05/2007 14:50:34|SETI@home|Reason: requested by project
25/05/2007 14:50:34|SETI@home|Deferring communication for 1 min 0 sec
25/05/2007 14:50:34|SETI@home|Reason: no work from project
25/05/2007 14:51:34|SETI@home|Sending scheduler request: To fetch work
25/05/2007 14:51:34|SETI@home|Requesting 1728 seconds of new work
25/05/2007 14:51:39|SETI@home|Scheduler RPC succeeded [server version 509]
25/05/2007 14:51:39|SETI@home|Deferring communication for 11 sec
25/05/2007 14:51:39|SETI@home|Reason: requested by project
25/05/2007 14:51:39|SETI@home|Deferring communication for 1 min 0 sec
25/05/2007 14:51:39|SETI@home|Reason: no work from project
25/05/2007 14:52:39|SETI@home|Sending scheduler request: To fetch work
25/05/2007 14:52:39|SETI@home|Requesting 1728 seconds of new work
25/05/2007 14:52:44|SETI@home|Scheduler RPC succeeded [server version 509]
25/05/2007 14:52:44|SETI@home|Deferring communication for 11 sec
25/05/2007 14:52:44|SETI@home|Reason: requested by project
25/05/2007 14:52:44|SETI@home|Deferring communication for 1 min 59 sec
25/05/2007 14:52:44|SETI@home|Reason: no work from project
25/05/2007 14:54:44|SETI@home|Sending scheduler request: To fetch work
25/05/2007 14:54:44|SETI@home|Requesting 1728 seconds of new work


I have tried re-starting boin and also detaching and re-attching seti, still don't work

Ditto. I got 1 just after midnight which finished around 7:00am and nothing since.

---

Can't get new work - Been getting "no work from project" since just after midnight. Hope it clears up soon. Oh well Einstein@home will enjoy it.

---

Can't get new work - Been getting "no work from project" since just after midnight. Hope it clears up soon. Oh well Einstein@home will enjoy it.

try now but they can mayby now be swamped

---

Why are the claimed credit scores much lower per machine now compared to before the big crash?

---

Delta-V

Why are the claimed credit scores much lower per machine now compared to before the big crash?

They're sending out many shorter (smaller) workunits, that's why you're getting less credits than usually. Although, I wouldn't say they're much lower (45-55 credits), and for example in my case, it's about a 1:1 ratio of "normal length" (67.xx credits) and shorter WUs.

---

Hi!

I have never seen this error message befor:

2007-05-25 21:01:00|SETI@home|Sending scheduler request: To fetch work
2007-05-25 21:01:00|SETI@home|Requesting 6887 seconds of new work
2007-05-25 21:01:05|SETI@home|Scheduler RPC succeeded [server version 509]
2007-05-25 21:01:05|SETI@home|Message from server: Can't find host record Invalid or missing account key. Visit this project's web site to get an account key.
2007-05-25 21:01:05|SETI@home|Deferring communication for 1 hr 0 min 0 sec
2007-05-25 21:01:05|SETI@home|Reason: requested by project

/Peter

---

now saids :

25/05/2007 21:00:45|SETI@home|Requesting 8472 seconds of new work
25/05/2007 21:01:55|SETI@home|Scheduler request failed: HTTP service unavailable
25/05/2007 21:01:55|SETI@home|Deferring communication for 1 min 0 sec
25/05/2007 21:01:55|SETI@home|Reason: scheduler request failed

Hi!

I have never seen this error message befor:

[b]2007-05-25 21:01:05|SETI@home|Message from server: Can't find host record Invalid or missing account key. Visit this project's web site to get an account

/Peter

Got the same.

--Saku

---

Getting msg
:can't find host record invalid or missing account key. visit this sites web site to get accout key.
When I try, it can't find my email address. I have been with Seti since 2001.
What gives????

---

Why are the claimed credit scores much lower per machine now compared to before the big crash?

They're sending out many shorter (smaller) workunits, that's why you're getting less credits than usually. Although, I wouldn't say they're much lower (45-55 credits), and for example in my case, it's about a 1:1 ratio of "normal length" (67.xx credits) and shorter WUs.

The recent average credit on all my machines are running much lower than before. Some as much as 50 points. I hope it will get back to normal

---

Delta-V

Getting msg
:can't find host record invalid or missing account key. visit this sites web site to get account key.
When I try, it can't find my email address. I have been with Seti since 2001.
What gives????

5/25/2007 10:56:21 PM|SETI@home|Message from server: Can't find host record Invalid or missing account key. Visit this project's web site to get an account key.

I was just able to login [Not exactly the same as an info-search] to the website without any trouble.

---

I have a dim recollecton that the "rest of the world" need not use an MTU of 1500. Unfortunately, Microsoft have a very broken implimentation that doesn't support fragmentation properly and so the rest of the world is forced to use that magic Microsoft number. Anyone know further?

There is no such thing as an "optimal" MTU, it depends on the protocol(s) used during an internet transmission.
Ethernet frames normally are limited to 1518 bytes. Of those 1518 bytes the ethernet packet header uses 14 bytes, 4 bytes are used for FCS (frame check sequence) at the end of the packet. So there remain 1500 bytes for IP address and the payload of the packet. This is the so called MTU (maximum transmission unit). In normal LANs all 1500 bytes are available, i.e. your MTU on the LAN is 1500 bytes.

If you connect to the internet over a DSL, some additional bytes are used for the protocol your provider requires (PPPoE, L2TP, PPTP etc.). PPPoE e.g. uses 8 bytes, your MTU is then reduced to 1492. The correct MTU normally is adjusted automatically when you connect to your ISP using the LCP protocol.
The "Path MTU" of an internet transmission defines the smallest MTU on any of the hops on the path of the transmission. If your original MTU is larger than the smallest MTU on the path, additional fragmentation will occur.
So even if you your ISP gives you the "correct" MTU, it still may be "wrong" for the actual transmission path.

HTH and sorry for being a wise guy... ;-)

Thanks, good answer.

There's further details on:

What is a maximum transfer unit?

See also:
What size should a new typical MTU be?
Raising the Internet MTU
Gigabit Ethernet Jumbo Frames

In short, a larger MTU is a good idea but it isn't supported.

My prior Microsoft comment may be from an old memory of their use of the DF bit causing problems for others...


Happy crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

Rudi, Martin... thanks for some great info...

I look forward to at least 64k MTUs... but my provider won't allow more than 1500, so it is still academic! However the big backbones could do packet aggregation with high mtus...

What an amazing soup of protocols, layers and tunnels the internet is!

Rudi, Martin... thanks for some great info...

I look forward to at least 64k MTUs... but my provider won't allow more than 1500, so it is still academic! However the big backbones could do packet aggregation with high mtus...

What an amazing soup of protocols, layers and tunnels the internet is!

The "correct" MTU is basically a function of the error rate on a given connection. If you have a 64k MTU, and the error rate on that link is something like 1 bit in 30,000, then you practically guarantee that every packet is going to have an error, and every packet must be retried.

... and of course, the retry will have errors as well, almost all of the time.

I'm guessing from the research that Gig-Ethernet, at least in the lab, has a very low error rate. Not sure about ATM in the real-world -- ATM seems to be the dominant low-level WAN protocol.

IMO, the problem is not so much MTU, but simply the size of the window -- the number of packets en-route at any given time.

TCP does this in bytes -- a sender will send up to RWIN bytes before it stops waiting for an ACK from the other end. In Windows 2000, the default allows about 12 packets to be "en-route" at any given time. You can raise this value, and if the error rate is low enough, data will go faster. Since the other end has to "reassemble" things if packets arrive out of order (or one gets lost), there will likely be more overhead if you raise RWIN too high.

Google for RWIN and you'll find many many pages of info.

Why is DSL often 1492? Because they're still using ethernet frames, and ethernet frames are 1500 bytes (DSL isn't ethernet, but it is often configured as an ethernet bridge for convenience). There are 8 bytes of overhead for the DSL protocol, so 1492 is the biggest packet you can get on most DSL lines without fragmentation. Trying to push 1500 through guarantees that your 1500 byte packets will be broken into a 1500 byte packet (including IP and TCP headers) and an 8 byte packet with another set of IP and TCP headers.

I'm going to disagree with Martin slightly. There is an "optimal" MTU, but it will always be specific to one path. Different path, different "optimium."

---

I downloaded the Speedguide Tcp Optimizer from the page linked to earlier in this thread. I ran the 'Largest MTU' test and it did indeed reccomend setting my MTU to 1492.
Thanx to all of you for all of the help and advice.

---

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

[quote][quote]Things are running smoothly here. Thanks for all your efforts at SSL!



Just for your information, things are not running smoothly here. I have four processors been waiting on work for over 12 hours and I fear this weekend will be a bust again. Project reports no work?? Any News on this? Or am I the only one that has this problem?

Update: I started getting work units last night and things seem to be back to normal. Good work Guys.

Thanks

Different path, different "optimium."

Isn't that word reserved for a future Intel/AMD processor collaboration? :-)

No seriously.. MTU is important and just another one of these things that just works unnoticed and hidden in protocol internals... until it doesn't! ICMP filtering can really get in the way of MTU discovery, so another thing to be aware of.
I'm on cable, and can actually achieve real 1500B packets but only at 2Mb/1Mb...

The links were interesting, at 10Gbps a 1500B packet takes 1.2µS so the sheer volume of packets and their processing overhead can get unmanageable. There is a really good case for increasing packet size especially at such high data rates, and for these and ATM they were discussing using MTUs of 150,000!

Error rates now are much much better than 1 in 30,000, maybe this was the case using a modem, but who still uses modems now? :-)
Anyway, this can be dealt with using adaptive MTU, and/or using recoverable ECC which can recover a packet from one or maybe two bit errors like audio CDs do.
I'm sure there's room in TCP to be able to handle these...

MTU is only a maximum, but is the size of the smallest supported MTU in a connection path. When typing on a terminal window over ssh, the packets are usually just a few bytes per keypress, but big downloads would benefit.
The net should be almost infinitely configurable, so should be reasonable to allow large MTUs and for it to fall back based on session/environmental conditions.
RWIN is useful as it reduces average handshake latency, and this is significant over intercontinental connections, it kind of UDP-izes TCP!

Makes me laugh that people were complaining that they couldn't do real-time MIDI jam sessions across the Atlantic because the pipes were too slow, when no amount of bandwidth can solve the latency problem of the speed of light! I'm not sure that we ever will unless we can really conquer quantum teleportation.

Hi, I was a seti classic user many moons ago and stopped for a period then i was asked to come back to this bionic. Ever since i have been confused with the software and the server never downloads.
Bubbles constantly come up on my screen )(whilst im doing something else) telling me the software needs new work but there is never any there. Any chance of sorting it out or going back to basics?

---