LHC@home

@Kunal, @ric, @RKidson,

Yes, that's the correct parameter to adjust. I recommend an initial value of 2 or 3 days for the "Connect every" parameter, which will give you 4 to 6 days of work. It has been recommended the value not be set greater than 5 days on a 14-day result deadline project (LHC and SETI), which will give you a maximum of 10 days of work. Adjust the value as necessary for your particular situation.

>
> I was able to get more than 1 or 2 WUs at a time by adjusting the "Connect to
> the Network" setting in General Preferences. The default was 0.10 Days and I
> increased it to 2.00 Days and started to get about 10 WUs at a time.
>

@Markku,

I suspect Poorboy, isn't the only user facing this limit. I've hit it a few times myself. BTW, I usually hit the "100 WU limit" after I had actually received 101 WU's, so there may be a very minor bug in the routine, nothing to get excited about. I've counted the WU's I've downloaded a couple of times. Yeah, I know get a life.

I think the limit is "100 WU's per computer per 24 hours," not "100 WU's per user per 24 hours," am I correct in this?

I know you folks have other things in the queue that are more important to the project(s) than this suggestion. Please consider it if you have some "free time" (yeah, sure!). The project has values for "Measured floating point speed," "Measured integer speed," "Measured memory bandwidth," and other parameters from which a throughput value for individual computers might be calculated. Might it be possible, without excessive programming effort, to have a dynamic download limit based on these throughput values? It would save space in the table(s) if the throughput value was an integer value, it seems you tend to use floating point values for everthing numeric. I'm not sure how you would calculate these throughput values, but could you calculate a dynamic download limit for a computer based on its throughput value, possibly a base value as we have now, with a variable value modifying the limit (plus or minus)? Just a thought.

Cheers,

Stephen
<a> [/url]

>
> @Markku,
>
> I suspect Poorboy, isn't the only user facing this limit. I've hit it a few
> times myself. BTW, I usually hit the "100 WU limit" after I had actually
> received 101 WU's, so there may be a very minor bug in the routine, nothing to
> get excited about. I've counted the WU's I've downloaded a couple of times.
> Yeah, I know get a life.
>
> I think the limit is "100 WU's per computer per 24 hours," not "100 WU's per
> user per 24 hours," am I correct in this?
>

From further down this very thread...

============================================================================

Daily result quota per host is 100, and it is reset at midnight server time.


Markku Degerholm
LHC@home Admin
============================================================================


Giskard - the first telepathic robot.

and it is reset at midnight server time.
==========

That may be how it is set up and supposed to work but apparently it don't work that way for some or a lot of people. I still say it makes me wait 24 hours from the time I download the last of the 100 Wu's no matter when the Server Resets the Daily Result quota per host ...

But I may have an explanation for this in my case anyway. If I remember correctly the last few times I Downloaded the 100 WU's it was about 7:15PM - 7:30PM here in Michigan.

Well there is a 5 hour time difference if I am correct between Michigan and UTC Time which would make the downloads at 12:15AM - 12:30AM the next day per UTC Time when the downloads where made. So that is why the Server makes me wait until 7:15PM - 7:30PM Michigan Time the next day before I quit getting the Daily Quota Exceeded Message ... At least thats what I'm assuming is happening in my case ...

You're assuming the server clock is correct :)

@MikeW,

PoorBoy said it for me, too. There seems to be some question about how it actually works. And, yes, I have read Markku's statements.

> and it is reset at midnight server time.
> ==========
>
> That may be how it is set up and supposed to work but apparently it don't work
> that way for some or a lot of people. I still say it makes me wait 24 hours
> from the time I download the last of the 100 Wu's no matter when the Server
> Resets the Daily Result quota per host ...
>

@PoorBoy,

I'm US Central Time, UTC -6 hours (I'm in Oklahoma, with Daylight Savings Time(DST), it's UTC -5 hours). You are US Eastern Time, UTC -5 hours, but with DST that puts you at UTC -4 hours. Michigan does do DST, don't they? I believe CERN is at UTC +2 hours, at least Switzerland is (although Markku seems to be just across the border in France). Your time difference relative to CERN should be -6 hours. It should be 6:00pm (1800hours) for you when it's midnight (0000hours) at CERN.

7:15-7:30pm (1915-1930 hours) EDT would be 1:15-1:30am the next day at CERN. So you missed midnight by over an hour. You need to complete your first download before 6:00pm EDT (before midnight at CERN), so you can get an additional 100 WU's in a second download just after 6:00pm EDT.

>
> But I may have an explanation for this in my case anyway. If I remember
> correctly the last few times I Downloaded the 100 WU's it was about 7:15PM -
> 7:30PM here in Michigan.
>
> Well there is a 5 hour time difference if I am correct between Michigan and
> UTC Time which would make the downloads at 12:15AM - 12:30AM the next day per
> UTC Time when the downloads where made. So that is why the Server makes me
> wait until 7:15PM - 7:30PM Michigan Time the next day before I quit getting
> the Daily Quota Exceeded Message ... At least thats what I'm assuming is
> happening in my case ...
>

Cheers,

Stephen
<a> [/url]

> I'm US Central Time, UTC -6 hours (I'm in Oklahoma, with Daylight Savings
> Time(DST), it's UTC -5 hours). You are US Eastern Time, UTC -5 hours, but
> with DST that puts you at UTC -4 hours. Michigan does do DST, don't they? I
> believe CERN is at UTC +2 hours, at least Switzerland is (although Markku
> seems to be just across the border in France). Your time difference relative
> to CERN should be -6 hours. It should be 6:00pm (1800hours) for you when it's
> midnight (0000hours) at CERN.

UTC FTC TCP Pacific ?? It's to complicated.

Poststamp this message
Posted: 15 Oct 2004 15:07:52 UTC
In Switzerland it's 17:07:xx now.

--> 2 hours later than message stamp.

In france or any other boarding country to Switzerland, they use all the same time as we have here in Switzerland.

It looks like, the server (one of them we see) is running with GMT Time set
(In summer we have here the "summertime", +1 Hours)
___________________________________________________________

at 24:00 (Switzerland time), they are having, at least the 2 nights before, a maintenance project down for several hours (upload ok, rRep waiting, no dl).

when the "server" is coming up to public it IS the next day and the 100 WU is set to "0".

We know, wu is not wu. Some are jumping in less then let's say 10 Minutes, others, v64tunescanb33s12_14660_1_sixvf_xyz takes longer (about 5 Hours amd2400, 10-14 hours on HT Pentiums)

A limit in Number is, in my eyes, a less good solution as a "counter" counting the total of estimated cpu time.

In this case, the limit could better take care about the effectively espected work. When we "ask" for 24 Hours of work we will get, in theory, 24 Hours of work.

friendly

ric

You need to complete your first download before 6:00pm EDT (before midnight at CERN), so you can get an additional 100 WU's in a second download just after 6:00pm EDT.
===========

Thats hard for me to do because I'm usually at work at that time except on some weekends unless the Computer Contacts the Server on it's own...Also that seems to be the predominate time when the LHC Server gives out the WU's...But I'll keep that in mind over the weekend if they release more work...