My laptop has been crunching short ones only from August until three weeks ago when I had to give it away for repairing (indeed the very last WU it had before was the first long one the thing has ever had ^^ talk about timing... delayed packing it up quite a bit) and although it's my "slow" comp it's way too fast to be classified as a "slow host" and only be given short ones on purpose. So there must be some of them out there for normal boxes as well.
My desktop, on the other hand, has never ever received one single short WU (I'm running it since the beginning of September) only ever long ones, which by the way take it around 6 hours.
So there certainly is both, but I don't think an ordinary cruncher has any means to figure out how the percentages are. Maybe we could get a statement from Bruce or Bernd here? Thanks in advance!
We know that the short WUs have names starting 400 or less. The highest-number WU on my machine at the moment is 1458 (I don't remember many higher than that, but I don't take much notice and I'm not going to start looking now!)
So, if all the numbers in the sequence are used (??), and short datasets are broken down into same number of WUs as long datasets (????), there are roughly three times as many long WUs as short WUs (??????).
We know that the short WUs have names starting 400 or less. The highest-number WU on my machine at the moment is 1458 (I don't remember many higher than that, but I don't take much notice and I'm not going to start looking now!)
So, if all the numbers in the sequence are used (??), and short datasets are broken down into same number of WUs as long datasets (????), there are roughly three times as many long WUs as short WUs (??????).
But there is a second number in the WU name. The highest for a short WU could be a lot higher than for a long WU. For example, I've got h1_0257.5_S5R1__6976_S5R1a, but also above 7000. I couldn't find info on the second number (what does that one mean??).
I don't believe there are more long ones than short ones. My box is not slow, so I would have more long ones if the number of long ones is larger (I recall a statement that slow boxes would get short ones. The rest would get "random" sizes). But I've gotten short ones for a long time. OTOH, the reason could be that I'm running a LiveCD Linux at the moment (harddrive failure).
We know that the short WUs have names starting 400 or less. The highest-number WU on my machine at the moment is 1458 (I don't remember many higher than that, but I don't take much notice and I'm not going to start looking now!)
So, if all the numbers in the sequence are used (??), and short datasets are broken down into same number of WUs as long datasets (????), there are roughly three times as many long WUs as short WUs (??????).
But there is a second number in the WU name. The highest for a short WU could be a lot higher than for a long WU. For example, I've got h1_0257.5_S5R1__6976_S5R1a, but also above 7000. I couldn't find info on the second number (what does that one mean??).
I don't believe there are more long ones than short ones. My box is not slow, so I would have more long ones if the number of long ones is larger (I recall a statement that slow boxes would get short ones. The rest would get "random" sizes). But I've gotten short ones for a long time. OTOH, the reason could be that I'm running a LiveCD Linux at the moment (harddrive failure).
We know that the short WUs have names starting 400 or less. The highest-number WU on my machine at the moment is 1458 (I don't remember many higher than that, but I don't take much notice and I'm not going to start looking now!)
So, if all the numbers in the sequence are used (??), and short datasets are broken down into same number of WUs as long datasets (????), there are roughly three times as many long WUs as short WUs (??????).
But there is a second number in the WU name. The highest for a short WU could be a lot higher than for a long WU. For example, I've got h1_0257.5_S5R1__6976_S5R1a, but also above 7000. I couldn't find info on the second number (what does that one mean??).
I don't believe there are more long ones than short ones. My box is not slow, so I would have more long ones if the number of long ones is larger (I recall a statement that slow boxes would get short ones. The rest would get "random" sizes). But I've gotten short ones for a long time. OTOH, the reason could be that I'm running a LiveCD Linux at the moment (harddrive failure).
on two machines - those are the highest 'second numbers' I can see.
I think Annika is maybe right:
Quote:
I don't think an ordinary cruncher has any means to figure out how the percentages are.
Perhaps anyone with a lot of spare time. I think you can pick a random number of users a see how the distribution of long/short WUs is. I doubt anyone would like to do that.
Perhaps the scientists can fill that gap. I'll post in another thread.
Oh well, I'll just do my job and crunch whatever unit ;)
Over the last 5 days we've averaged about 78400 WUs/day (as of 11:12 PM UTC on Monday, 23 October 2006). As you can see from the graph below, we've increased our WU completion rate over the last two weeks or so.
Assuming a steady completion rate of 78400 WUs/day, we should finish in about 119 days: around 19 February 2007.
Quote:
I believe credit for the following graph belongs to Stef from this post. If credit belongs elsewhere, somebody please correct me.
Here'a a bit of raw info (Nov 5 2006). This is useful for seeing how much work available is short versus long workunits.
[root@einstein locality_scheduling]# ls work_available/*_ S5R1 | wc
2138 2138 64140
[root@einstein locality_scheduling]# ls working_set_removal/*_S5R1 | wc
3664 3664 128240
The sum 2138+3664 = 5802 is the number of data files [hl]_0050.0_S5R1 -> [hl]_1500.0_S5R1
[root@einstein locality_scheduling]# ls work_available/*0[0-3]*_S5R1 | wc
701 701 21030
[root@einstein locality_scheduling]# ls working_set_removal/*0[0-3]*_S5R1 | wc
1021 1021 35735.
So the number of data files with work remaining is 701 for short WU and 2138-701 = 1437 for long WU.
The original ratio of short/long was 350/1100 = 0.318. Current ratio is 701/1437 = 0.48
Conclusion is that we have proportionally more 'short' WU remaining than long one, compared with the beginning of the run. We are not running out of short WU.
My laptop has been crunching
)
My laptop has been crunching short ones only from August until three weeks ago when I had to give it away for repairing (indeed the very last WU it had before was the first long one the thing has ever had ^^ talk about timing... delayed packing it up quite a bit) and although it's my "slow" comp it's way too fast to be classified as a "slow host" and only be given short ones on purpose. So there must be some of them out there for normal boxes as well.
My desktop, on the other hand, has never ever received one single short WU (I'm running it since the beginning of September) only ever long ones, which by the way take it around 6 hours.
So there certainly is both, but I don't think an ordinary cruncher has any means to figure out how the percentages are. Maybe we could get a statement from Bruce or Bernd here? Thanks in advance!
Some guesswork: We know
)
Some guesswork:
We know that the short WUs have names starting 400 or less. The highest-number WU on my machine at the moment is 1458 (I don't remember many higher than that, but I don't take much notice and I'm not going to start looking now!)
So, if all the numbers in the sequence are used (??), and short datasets are broken down into same number of WUs as long datasets (????), there are roughly three times as many long WUs as short WUs (??????).
RE: Some guesswork: We
)
But there is a second number in the WU name. The highest for a short WU could be a lot higher than for a long WU. For example, I've got h1_0257.5_S5R1__6976_S5R1a, but also above 7000. I couldn't find info on the second number (what does that one mean??).
I don't believe there are more long ones than short ones. My box is not slow, so I would have more long ones if the number of long ones is larger (I recall a statement that slow boxes would get short ones. The rest would get "random" sizes). But I've gotten short ones for a long time. OTOH, the reason could be that I'm running a LiveCD Linux at the moment (harddrive failure).
Regards,
Bert
Somnio ergo sum
RE: RE: Some
)
Hmmm, you're right. I have:
h1_0362.0_S5R1__29113_S5R1a
h1_1351.0_S5R1__1647_S5R1a
on two machines - those are the highest 'second numbers' I can see.
I think Annika is maybe right:
RE: RE: RE: Some
)
Perhaps anyone with a lot of spare time. I think you can pick a random number of users a see how the distribution of long/short WUs is. I doubt anyone would like to do that.
Perhaps the scientists can fill that gap. I'll post in another thread.
Oh well, I'll just do my job and crunch whatever unit ;)
Happy crunching!
Somnio ergo sum
Over the last 5 days we've
)
Over the last 5 days we've averaged about 78400 WUs/day (as of 11:12 PM UTC on Monday, 23 October 2006). As you can see from the graph below, we've increased our WU completion rate over the last two weeks or so.
Assuming a steady completion rate of 78400 WUs/day, we should finish in about 119 days: around 19 February 2007.
Seti Classic Final Total: 11446 WU.
Here'a a bit of raw info (Nov
)
Here'a a bit of raw info (Nov 5 2006). This is useful for seeing how much work available is short versus long workunits.
[root@einstein locality_scheduling]# ls work_available/*_ S5R1 | wc
2138 2138 64140
[root@einstein locality_scheduling]# ls working_set_removal/*_S5R1 | wc
3664 3664 128240
The sum 2138+3664 = 5802 is the number of data files [hl]_0050.0_S5R1 -> [hl]_1500.0_S5R1
[root@einstein locality_scheduling]# ls work_available/*0[0-3]*_S5R1 | wc
701 701 21030
[root@einstein locality_scheduling]# ls working_set_removal/*0[0-3]*_S5R1 | wc
1021 1021 35735.
So the number of data files with work remaining is 701 for short WU and 2138-701 = 1437 for long WU.
The original ratio of short/long was 350/1100 = 0.318. Current ratio is 701/1437 = 0.48
Conclusion is that we have proportionally more 'short' WU remaining than long one, compared with the beginning of the run. We are not running out of short WU.
Cheers,
Bruce
Director, Einstein@Home
RE: The sum 2138+3664 =
)
How can we have 5802 datafiles, when there are only 1450 numbers (from 50 to 1500 for h1 and l1) that is 2900 numbers?
Udo
Because each data file only
)
Because each data file only represents about 24hrs of collected data.
Woooo Hoooo! We've past
)
Woooo Hoooo!
We've past the half way point!!!!
As of 11:58 PM UTC on Sunday, 5 November 2006
Total needed: 16,446,454 units
Work still remaining: 8,185,421 units
49.770% left to go!!!
[edit spelling]
Seti Classic Final Total: 11446 WU.