Rattledagger
Elite Member
From http://setiathome.ssl.berkeley.edu/tech_news.html
<< January 25, 2002
Users may find their connections to the server slow during peak hours. Some may even see a connection refusal. This is due to a bandwidth limit between UC Berkeley and the Internet. The aggregate Internet usage over the entire campus has recently hit this limit. UC Berkeley's Communication and Network Services has been extremely helpful in working with us on this issue. The goal is for SETI@home users to get as good a data rate as possible while at the same time not adversely affecting the rest of campus. The current (new) policy is for SETI@home to get all excess capacity in outbound bandwidth (inbound is not an issue). This is being done by placing our traffic at a lower priority than that of other users, but applying no rate limit other than the campus wide cap. Placing us at a lower priority is necessary so that interactive Internet users do not experience painfully high latency. This policy translates into enormous capacity at (local) night, but a tight squeeze during peak hours. Thus far this policy is working better than expected even though there may be periods of poor service. Please bear with us as we work towards a sustainable long term solution >>
This will say, if possible, fill your caches between 08:00 and 16:00 GMT. (0 to 8 berkeley-time)
<< January 25, 2002
Users may find their connections to the server slow during peak hours. Some may even see a connection refusal. This is due to a bandwidth limit between UC Berkeley and the Internet. The aggregate Internet usage over the entire campus has recently hit this limit. UC Berkeley's Communication and Network Services has been extremely helpful in working with us on this issue. The goal is for SETI@home users to get as good a data rate as possible while at the same time not adversely affecting the rest of campus. The current (new) policy is for SETI@home to get all excess capacity in outbound bandwidth (inbound is not an issue). This is being done by placing our traffic at a lower priority than that of other users, but applying no rate limit other than the campus wide cap. Placing us at a lower priority is necessary so that interactive Internet users do not experience painfully high latency. This policy translates into enormous capacity at (local) night, but a tight squeeze during peak hours. Thus far this policy is working better than expected even though there may be periods of poor service. Please bear with us as we work towards a sustainable long term solution >>
This will say, if possible, fill your caches between 08:00 and 16:00 GMT. (0 to 8 berkeley-time)
